Syncplay sessions close after playing video for 30 seconds #5485
Comments
This comment was marked as outdated.
This comment was marked as outdated.
|
Hello. Same thing here with Jellyfin Server 10.9.0.0 in Debian 12, in a VM with the latest package from the jellyfin repo 10.9.0+deb12. it works a bit better before the update. |
|
Same here too with Jellyfin Server 10.9.0 latest stable, on a Synology (DSM 7.2.1-69057 Update 4), didn't have this strange behavior with 10.8.13. Tried with and without hardware transcoding, same result, syncplay closes after 30 secondes on both computers and return to previous page. |
|
I am able to reproduce this behavior on current master (latest commit 25c23af8659700909995ca9c91c5dafccc6d348b) and latest web master (latest commit b40cbb2).
|
|
The error message in web is that the api request reporting the playback start times out and I don't see anything in the provided server logs indicating why... server logs of the failed request would likely give some details as to cause of the issue. |
|
I am not seeing anything weird with a quick glance on the terminal output of visual studio of the server when this problem occurs. [18:03:44] [INF] [39] Emby.Server.Implementations.SyncPlay.Group: Session 2ab1b5d58aa78b0eff5aaf44cfb9179f requested IgnoreWait in group 1a871bf4-f845-4e16-a316-92000eef541e that is Waiting.
[18:03:44] [INF] [23] MediaBrowser.Controller.MediaEncoding.TranscodingJob: Stopping ffmpeg process with q command for C:\Users\Tim\AppData\Local\jellyfin\cache\transcodes\cc3c2e1bf77f00eeb3d2f487fa629cb8.m3u8
[18:03:44] [INF] [39] MediaBrowser.Controller.MediaEncoding.TranscodingJob: Stopping ffmpeg process with q command for C:\Users\Tim\AppData\Local\jellyfin\cache\transcodes\ad5c48a15455f427854b21d31c9c7513.m3u8
[18:03:44] [INF] [40] Emby.Server.Implementations.SyncPlay.Group: Session a0338c7db866e181c8763d7f052d56d1 requested IgnoreWait in group 1a871bf4-f845-4e16-a316-92000eef541e that is Waiting.
[18:03:44] [INF] [40] Emby.Server.Implementations.SyncPlay.Group: Group 1a871bf4-f845-4e16-a316-92000eef541e switching from Waiting to Playing.
[18:03:44] [INF] [23] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: FFmpeg exited with code 0
[18:03:44] [INF] [23] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: Deleting partial stream file(s) C:\Users\Tim\AppData\Local\jellyfin\cache\transcodes\cc3c2e1bf77f00eeb3d2f487fa629cb8.m3u8
[18:03:44] [INF] [39] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: FFmpeg exited with code 0
[18:03:44] [INF] [39] MediaBrowser.MediaEncoding.Transcoding.TranscodeManager: Deleting partial stream file(s) C:\Users\Tim\AppData\Local\jellyfin\cache\transcodes\ad5c48a15455f427854b21d31c9c7513.m3u8
[18:03:45] [INF] [22] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app Jellyfin Web 10.10.0 playing The Red-Nosed Reindeer. Stopped at 29694 ms
[18:03:46] [INF] [39] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app Jellyfin Web 10.10.0 playing The Red-Nosed Reindeer. Stopped at 29689 msWill continue looking into it what might be going wrong. |
|
Any failed requests in the browser's network tab? |
None failed in the browser network log: |
|
I am still unsure what endpoint it calls where it times out on. Does it even call one? |
|
Oh good call... I thought this was related to a progress reporting request, but it could just be events within web. 🤔 |
|
It looks like it times out on line 170 (QueueCore.js). It times out on the default configured 30s |
|
I think this is just a race condition, from what I can tell the |
|
https://github.com/jellyfin/jellyfin-web/blob/master/src/plugins/syncPlay/core/QueueCore.js#L237 So moving |
|
Amazing find. Perhaps someone from web knows if that is a good way to fix it. |
|
Nice find... this seems like one of those things that should have never worked. Clearly you should register the event listener before starting playback. 🤔🤷♂️ |
|
Looks like this commit broke it: 1b2c99a |
|
So Ive been looking at this for a while, and I have no idea why that commit broke anything, from what I can see it should be executing the exact same code, but for some reason it changes the timing order of things. But Ive decided its just magic, so ive raised a pr to revert the refactor, if anyone wants to investigate into why the refactor broke stuff feel free to close my pr and open your own |
|
@PeachesMLG I cloned the jellyfin-web repo and built the web interface with your changes to the playbackmanager.js file. Restarted the server after install. |
|
Oh, weird. so I ran it locally again, and it worked fine, so I did a few more tests and again everything was working fine. However on the 5th attempt it broke. At a guess we are running two async tasks in parralel when they need to be waiting on one another... (which is probabbly why my fix "worked" since it changed the timings a few fractions of a milliseconds?) Let me investigate this further... |
|
Maybe it is a good idea to mention something in the pull request on why it's closed. Can even be just a link to your comment. |
|
So from what I can see by spamming a bunch of logs everywhere, the promise somehow gets released here: https://github.com/jellyfin/jellyfin-web/blob/master/src/components/playback/playbackmanager.js#L478 So the I think my original suggestion of moving the Javascript isnt really my forte and I dont know this codebase that well, so ill leave this for somone smarter to do, but id be interested in seeing what the fix ends up being |
|
The "magic" is that my PR has bound
This is actually the correct way to handle events. As Bill said, subscribe before performing an action that might trigger an event. The only question is how to stop waiting for
From the same object?
|
|
No idea about what object they originate from, but if you look in dev console it triggers two events |
These are the handlers. Look to the right where these lines are coming from.
The latter is difficult to reproduce. SyncPlay just probably triggers an additional event after sync. If so, I think that's fine. |
|
Yeah, your right, I didnt realise they were handlers listening to an event, I thought they were indicating an event was called/triggered. |
|
Good to know. For now I will revert the change back to the original and await a new update |
|
Went crazy trying to troubleshoot this over the last 2 days. Glad someone already make an issue. |
thornbill
changed the title
|
I opened a PR to try to get the fix in the next release. |
|
I have built the webui with the new change. This appears to be working. I will continue to test. Thank you for your work @PeachesMLG and @thornbill |
|
Is there a rough time window, when this will be released with version 10.9.2? |
As soon as it is ready. Don't expect it to take months. |
Sorry, I didnt want to raise one since I dont know the codebase well enough to know if there was any side effects to moving it |
Please describe your bug
Moving from #5446
When playing video from a syncplay session. The Sessions will close and stop playing
Reproduction Steps
1: Start a syncplay session
2: Play any video file
3: Wait 30 seconds
4: Stream crashes and backs to previous page
Jellyfin Version
Unstable (master branch)
if other:
No response
Environment
Jellyfin logs
...
...
Please attach any browser or client logs here
log_20240509.log
FFmpeg.Remux-2024-05-09_03-29-11_394aef7aa8fdf3830840f9d598a199d3_11a3f9c7.log
FFmpeg.Remux-2024-05-09_03-29-52_394aef7aa8fdf3830840f9d598a199d3_612a87ea.log
Please attach any screenshots here
Code of Conduct
The text was updated successfully, but these errors were encountered: