Subtitles get out of sync when resuming a movie, or the audio/video is out of sync with the subtitles. #3492
Comments
|
Any chance the media is being transcoded? |
|
Iirc it was a direct stream. But I'll be double checking later today and report back.
…________________________________
From: VampiricAlien ***@***.***>
Sent: Tuesday, April 9, 2024 2:51:12 PM
To: jellyfin/jellyfin-androidtv ***@***.***>
Cc: Joost R. ***@***.***>; Author ***@***.***>
Subject: Re: [jellyfin/jellyfin-androidtv] Subtitles get out of sync when resuming a movie, or the audio/video is out of sync with the subtitles. (Issue #3492)
Any chance the media is being transcoded?
—
Reply to this email directly, view it on GitHub<#3492 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFAMG55BKC2YSBVHNXHAFE3Y4PP4BAVCNFSM6AAAAABF4PM5KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANBVGEYTANBZG4>.
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Sorry, something came up yesterday. However, I tried to force transcoding by putting the quality to 1Mbit/s, and this "fixes" the sync issues. Is there any other way to force encoding, so I can temp-fix this until a proper fix is out? |
|
In playback settings, Hardware encoding options might be a temp fix. Your CPU supports HEVC encoding. |
|
Hi VampiricAlien, Thanks for the suggestion, however it did not temp-fix my issue. In case it is important, my setup is like this: And this are my JF settings for hardware decoding |
|
In the app, menu, playback, under video there should be max streaming bitrate, set that to highest but don't select auto. Can you post the video details such as: |
|
I've set it manually to 120mbps, but it's still direct stream and out of sync I didn't know how to get that video detail in the format how you have it, I hope this screenshot is enough: edit: Just noticed the last property is cut off in the last screenshot. It was "Ref frames" with value "1" |
|
Silly question but are you sure the subtitle are correct? Have you tested on Jellyfin web, VLC, android client? |
|
Yes, on my phone and on my pc using the JellyFin windows client the subtitles are correct. |
|
Have you looked at the option Allow subtitle extraction on the fly under playback? |
|
I haven't seen that option anywhere yet, but I'll see if I can find it tomorrow, and report back. Thanks for the suggestion. |
|
You'll find the option in Jellyfin web. |
|
windows: Notice that both frames are at 35:30, have a different scene, but the exact same subtitles. This confirms for me that the subtitles are actually correct, but the video itself is somewhere else than JF expects, resulting in a sync issue between video and subtitles. |
|
My last suggest would be to create a new audio track. |
|
I'll be waiting on a fix for now. And in the mean time I'll use a nuc to watch movies from the TV. Thanks for helping and let me know if I can help in any way (e.g. Test a beta version) |
|
I've been having this issue aswell, only happens on androidTv client. Subtitles that burn in are still correct even after resuming the movie/serie. This started happening for me a few months ago, and playing the movie back from start does not seem to fix it. Hopefully it can be resolved in a future update of the androidTv client app. |
|
In the Android App (or Web client), in the Subtiltes setting menu, you have an option to force burning all the subtitles in the video. |
|
Thanks @hcharbonnier . Could you clarify which option exactly I need to select? |
|
It is not "Subtitle mode"but the parameter right after. I don't know it's name in english but it should be something like "Burn the subtitles" PS: I have a different value in the Android app and the Jellyfin web interface. I believe (but i'm not sure) you should modify this value from the website and not the android app if you want it to work in the androidTV app. |
|
However I checked via my web browser, instead of the Jellyfin Windows App, and there the setting is. I'll be testing it out after work and update this message, and if it works, I'll also update the original post so people who are facing this issue know how to fix it without going through all the dialogue. |
|
Just tested it with the "Burn subtitles" option set to "All". I tried to test it by lowering the quality to the lowest setting possible and see if it affected the quality. In the browser it works, and ffmpeg is being shown in intel_gpu_top utility, in the Windows app and in the AndroidTv app it did not work and it is a direct play. Is there any other way I can force subtitle burn in and/or transcoding without sacraficing bitrate/quality? |
|
I don't really know, each time I modify this setting it take times before it became effective, and I don't konw why. |
I waited 2 days, and it did not become effective. |
|
hum.. Maybe try to set this setting from the Android app instead of Jellyfin Web interface. |
|
https://discord.com/channels/772232779534172171/772247115681890314/1232034632296562839 |
|
I've been digging into this a little bit and it would seem that the problem is due to exoplayer returning an incorrect value for the position when jellyfin calls |
|
@pierfied that looks exactly like the issue I'm facing. Thanks for figuring out that it's actually unrelated to JF. Would it be possible to get an option in the androidTV app menu to burn in subtitles? Maybe it's not the "technically correct" fix, but that would fix the sync issue. |
|
@joost00719 this is actually my first time ever looking at the JF codebase as I just wanted to try to dig into this exact issue. So, unfortunately, I don't think I'm the right person to tackle adding an option for burning in subtitles, but I'm sure another developer here may be able to. However, I have been playing a bit with figuring out how to get around this particular issue. As far as I can tell, using the HLS protocol (as JF + exoplayer natively tries to do) results in exoplayer incorrectly adjusting the timestamps due to to how the JF server is returning TS segments. The JF client is requesting 6 second segments, but the returned segments contain closer to 10 seconds worth of frames for reasons that are beyond my level of knowledge (I think it has something to do with wanting to start each segment with a keyframe). As far as I can tell, exoplayer assumes that the first frame in the segment should correspond to the beginning of the 6 second segment even though that may not actually be the case. The problem then occurs when exoplayer adjusts all timestamps to force that first frame to fall on the beginning of the 6 second segment, resulting in incorrect timestamps for each frame. Now, I've been trying some stuff to get around this issue and one workaround I've been playing with is simply disabling HLS playback with exoplayer and using a similar transcoding profile as the libVLC-based player: While I don't think this is optimal by any mean, it seems to be working for some limited testing I've done. I'm sure there are some consequences of disabling the HLS protocol that I am unaware of. As I am by no means an expert here and my knowledge of the various protocols, containers, and codecs is very limited, I would greatly appreciate any insights here from more experienced developers on this one. |
This comment has been minimized.
This comment has been minimized.
|
I also have the same issue. And using libvlc causes micro-stuttering making jellyfin almost unusable on Android TV. Maybe add some "Disable HLS", "Force Burn subtitles" options on the Android TV client app as a quick workaround? |
|
I have this very same problem not only when I stop and restart a video, but also when I jump back and forward during playback. The subtitles timing restart from zero. |
|
It seems like this particular issue also shows up across other JF clients and I think this is a server-side issue with how HLS is handled. Disabling HLS in the android tv client has worked well for me for a while now. I think adding an option in the settings to disable HLS playback might be a good solution until the HLS timestamp problem is properly diagnosed/fixed. |
@pierfied Hey, just wanted to ask if there are any issues that could arise from disabling HLS. I.e, would transcoding or direct streaming still work? |
|
It looks like this issue may be solved by #3825. |
Unfortunately I cannot test it because I have sold my Chrome Cast. |
|
This is most likely fixed by #3825 yes. Closing as fixed. |
|
Not fixed. |
|
Did you try with 0.18? |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
Describe the bug
Reproduce steps:
I also noticed something else odd, which could explain why this bug happens.
If I go to timestamp 1:00:00 on the androidtv client (chromecast), and I go to 1:00:00 on the Windows 10 client, it seems like the androidtv client is like 5-10 seconds behind the Windows 10 client. The subtitles are 100% exactly on the same timestamp, so those appear at the identical time if you sync the two clients up, but the video and audio on the androidtv client seems to be 5-10 seconds behind, which could explain the subtitle sync issue.
Long story short, it looks like the audio/video get's out of sync with the time, but the subtitles are actually correct.
For me this is a big issue since I have trouble hearing voices with background noise, especially if it's not my native tongue.
If any more info is needed, I am able to (privately) provide a test-account to my JF server to a developer, with sftp access to my library.
Logs
Application version
jellfyin-androidtv 0.16.7 release
Where did you install the app from?
Google Play
Device information
Chromecast HD
Android version
Android TV 12 (STTL.240206.002)
Jellyfin server version
10.8.13 (docker)
The text was updated successfully, but these errors were encountered: