-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Chat download task never finishes #354
Comments
Looks like it's failing to kill the chat download for some reason. Do you see the "found pid for chat_downloader" in any logs (debug only)? ganymede/internal/activities/video.go Line 809 in 80d8b4c
|
Yep
There are corresponding success logs for some of them
|
I was able to reproduce locally, only when the stream ended. Does this seem to occur only when the stream ends for you? |
That seems to be the case, but I haven't been watching the logs while a stream ends so can't say for sure. |
I believe I have found the issue. The chat download task was getting cancelled but the post-tasks were never running. I have some changes in #357 if anyone is able to test these changes. I did some testing and the context and chat download processing is fixed but would like to get some others to test as well. |
I would like to test it, how can I pull it in docker? I tried |
Pull requests don't publish the images to save on storage. You'll need to clone the repository and checkout the branch and build the image locally. |
Alright, got it running locally. I've added a bunch of random live archives, will report back after a couple of them end. |
Almost certainly a different issue, but while testing this, my internet went out :/. Anyway, that caused the live video downloads to end, which is expected. But even though the video download task in the queue is marked complete, it's not moving on to video convert/move. And chat download is stuck in progress still. Looks like the video download workflow failed due to the fetch VOD ID failing. Perhaps we can just ignore that failure?
|
Ok, a stream ended naturally now. Failed at ending the chat downloader, multiple PIDs again. Could likely be due to the previous failures mentioned above. I didn't restart any of the containers after my internet came back. Now the video convert/move steps are still not running. Before, when the chat download failed to finish, the other steps would still continue.
I will start testing again with a fresh temporal db and restarted containers. |
After fresh temporal and restarting, seems the queue is progressing as expected now. I went live with a test stream, while also recording another stream. The correct chat downloader was killed, and the queue item for my test stream finished as expected. The other livestream was unaffected, also as expected. Ending the other livestream on the queue page (the X button): ended the capture, killed the chat download, and completed the queue, as expected. Seems like the fixes work for me! I'll make another issue for the issue that came up when my internet dropped, i.e. queue fails due to VOD ID not being retrievable after stream ends. |
I believe the multiple PID issue is that the chat downloader never got killed before (before the changes in the PR) so the processes just stuck around. Restarting the container clears those up for proper testing with the PR. |
If anyone else wants to test the fixes, they are now available using the |
These fixes have been released in v2.1.0. |
On most (not every) live archive that runs for me, the Chat Download task does not mark itself as finished. However, Chat Convert/Render/Move all occur and succeed afterwards. Due to this, the queue entry is never finished, and I've had to go and set the queue entry and the vod to not processing.
These lines are the most relevant:
From inside temporal:
Here is a full log for all mentions of a certain vod, and the chat download workflow that is "cancelled" as well.
Furthermore, the below is being logged every second, 1 line per each stuck chat downloading task.
The text was updated successfully, but these errors were encountered: