[bug] LG webos + Dolby Vision =⛔ movie stutters then hangs when resuming or skipping ahead #248
Comments
megosugit
changed the title
|
i just tried to play a movie and seem to have the same issue.. |
what is you TV model ? |
|
same issue on my LG C2 |
LG G2 |
|
Exactly the same issue I am facing now with my LG G3. At first, I thought it was the transcoding problem but on the server side, I can access all the temporary small parts of transcoded videos and I can play those on the server itself just fine using a normal media player, including the parts that hung on my LG G3. It's definitely something else that's the problem. |
|
I suspect every WebOS users have this issue with Dolby Vision content. I wonder if it is posted in the right place ? |
|
Hmmm, well, let's do this: https://jellyfin.org/docs/general/contributing/issues Under "Searching and Voting" section, it said the following:
I just did that on your opening post. Everyone, please do that as well. |
Hmmm, I think you need to do a couple more things. Like:
Check the above link and see what else you need to do right, otherwise it might affect their response. |
megosugit
changed the title
I did too :p |
|
@gnattu or @GeorgeH005, is it something you would know about ? |
|
I'm currently in the process of switching from Plex to Jellyfin and am reading up on any issues i might encounter and stumbled in here. I have 3 LG OLEDs, 77C1, 65C8 and a 48A1. I was however unable to replicate this on any of them. Resuming and skipping 20-30min causes no issues. |
This was an issue that had come up during testing, but only when using the fmp4 container. When using ts, I wasn't able to replicate it. The only slightly enlightening error that had occurred was the app crashing (when using fmp4) reportedly due to running out of memory. Csn't tell you much more than that. Maybe the Jellyfin webUI (that this app is wrapping) is just too heavy? Haven't conducted any research so I can't answer that. Edit: I am using a C3 and the tests were conducted on WebOS 23 |
|
My files are in MKV container and as far as I know, all 3 files are using Profile 8.1 and all 3 had the same issue. |
|
I struggled with this for a while and eventually gave up. Even videos by the same person have different symptoms. Fortunately, recent videos seem to be less prone to the problem. My guess is that the root of the problem lies with LG. Dolby Vision only works with MP4 and the This is a serious problem. |
you can still put a thumb up on the first post, to gain more visibility, maybe it will be fixed eventually :) |
|
Have you tried to see if you can reproduce the same issue in other ways: plex, dlna, usb... |
USB is fine even with mp4 if I remember correctly, plex and dlna I haven't tested. I could test Plex, but I would have to reconvert a file to mp4. |
|
Hi folks, I've narrowed my problem down to this issue as well. LG OLED C2 (WebOS v8.3.0-29 (number1-nameri) Playing .mkv files with Dolby Vision Profile 8.1 fails. Either first few frames then stops or green screen tearing and static. Seems to be exactly this combo .mkv with DV (only have profile 8.1 to test with). DV with .mp4 works fine and HDR10 on both containers works fine. Playing .mkv + DV via USB doesn't trigger the DV or HDR toaster pop up so unsure if it's playing with either but it does play regardless. |
If so, it sounds like it might be a remux issue. We might want to try raising an issue on the server side |
|
I had thought the same back then as well, but it was in a good enough point in my case, that it wasn't worth debugging the web client or server side. My suspicions lie on the client side. I will try to see if I find something worth exploring. |
|
How can I help on my side? I can reproduce it easily, please let me know what kind of log could be interesting |
|
I am very certain it is a client specific issue and it is even webOS/TV model specific issue. The problem is some webOS TV model has a very buggy native HLS player that is unable to handle Dolby Vision correctly and that is what Jellyfin is using to do the on-the-fly remuxing to enable dolby vision. The problem is that:
Currently your best choice is to manually remux the file into mp4 if you want to keep dolby vision and make your TV happly. We can do little for this other than some very unfortunate option like "disable dolby vision for this TV" so that the server will send the mkv as-is and just play the HDR10 fallback. The way to remux to mp4 is to jellyfin-ffmpeg (the upstream one may work worse), for example: |
|
The problem seems to be that the hls player doesn't like not having the segments ready when seeking or resuming. If you look at the Jellyfin-web code, there was a hack for safari that made sure that there were segments available on playback start. By hacking that a bit to work on seek and on web0s (essentially forcing it to use live.m3u8 rather than master.m3u8) web0s can seek freely anywhere that has already been transcoded. This prevents the stall that we were seeing. Maybe we can introduce some kind of loading until there are segments ready instead of feeding it the url immediately and leaving it to handle it? |
|
This issue seems better suited to Jellyfin-web as this repo contains a wrapper that does not interfere with playback. |
Hmmm, ok, so I went and remux the .MKV file into MP4 using the above command you provided, using the ffmpeg in JellyFin's Server folder and absolutely no issues. I can see the dolby vision and dolby atmos popup on the top right hand corner of the TV when I play it with the JellyFin client on my LG G3 TV. So definitely it's an MKV + Dolby Vision problem in combination with LG TVs. |
LG TVs are UNable to playback Dolby Vision in MKV, neither with Jellyfin, nor with DLNA, not even with USB. That much we knew. The problem is that LG's hls player does not like not having fmp4 fragments ready as soon as it needs them it seems, which is a problem when we are transcoding/remuxing. The issue described here is reproducible even without dolby vision. I believe, apart from maybe implementing some extra loading in order to wait for the server to have some fragments ready, there is not much we can do. |
Maybe somebody should ask LG for why? We don't know either. Because, for some models, it does work and it does not need any workarounds. |
|
Is there a way to have more info about what's going on when the problem occurs? On jellyfin or on LG? |
|
@megosugit as far as I know the best you can do is hook up the web inspector (https://webostv.developer.lge.com/develop/getting-started/app-debugging), you'll be able to see log messages written by Jellyfin-Web. Unfortunately the issue lies within the native player in WebOS, you won't get any logs or data from that in the console (unless you're root, then maybe you can dig in the system journal). I'm currently messing around with the web inspector to see if I can find anything to work around this issue. Some people reported switching to HLS.js worked for them but for me that just completely bugs everything out. Can't figure out why. The best thing I've come up with so far: Changing master.m3u8 to live.m3u8 in the URL feeded to the player, makes the player only play parts that have already been processed by the Jellyfin server. I do the URL replace thing here, only when the current browser is web0s. There's already some code there that basically does the same for safari browsers, though we don't need to prefetch for webos. This is a very very hacky workaround, it might cause other unwanted side effects. I'm a complete newbie to the jellyfin codebase. |
|
Have the same issue on LG G4 (23.20.42). |
|
I have been reading this since I have the same problem here on a LG C3. I think I have found kind of a workaround. I have been trying to change the segment length by modifying the hls_time parameter on ffmpeg command that jellyfin is using when remuxing. Changing the segment length from 6 to 1 second actually seems to work. I have been able to resume and watch until the end, no stuttering, on a few mkv files with dolby vision, those files would consistently fail before. This needs to be changed on the server side in the code, and then recompiled. Don't really know why this is working, feels more like a workaround than a fix. But would be interesting if this worked for somebody else also. |
|
@fhelland that probably works because ffmpeg can spit out a 1 second clip much faster than a 6 second clip, so the LG player doesn't need to wait as long. I wonder if this approach has any downsides? Maybe more IO overhead for ffmpeg? If there is a way to configure this to only generate 1 second clips when the requesting source is an LG TV I'll probably deploy this workaround too. Currently, I've deployed a custom jellyfin-web build that fully restarts the playback whenever I seek from an LG tv. Basically the player fully quits, then resumes playback from the point you skipped to. The LG player doesn't like when you seek to parts that aren't immediately available, but when you start playback it's happy to wait. A true fix for this issue would be to investigate why LG's player flips out when .ts files aren't available straight away. Or if maybe there's something we can add to the player properties or even the m3u8 files to mitigate this. |
You could insert the following code in the StreamState.cs file. It could be inserted on line 96 under the appletv stuff(line 87 to 94). It will only affect the LG players then. Actually ffmpeg will most likely not be able to produce exactly 1 second files even if we specify hls_time=1. This is more like something of a requested average. When FFmpeg is remuxing it can only split the original file on a keyframe, so the actual length of the ts files will depend on where the keyframes are located. So even though we are requesting 1 second, the actual length will often vary all the time throughout the video, like between 0.5 and 10 seconds. |
|
I'm so happy some of you have gone this far and found what seems to be great workarounds ! 💪🙏 What is the next step to make it public ? |
|
Same issue on LG C4 on a HEVC DV8.2 mkv file. It can play for anywhere between 2 to 10 minutes sometimes, if I’m lucky. Then it’ll freeze permanently. It can rewind and start over no problem, but then it’ll just freeze again. It says it is remuxing. I’m on a intel n100 system with default jellyfin settings, so it’s a bit disappointing to suddenly get this on my new tv. Jellyfin 10.10.3 Edit: I think this is the same problem? Edit 2: I don't get this issue on DV 7.6, even though file format is the same. So it's just 8.2 and/or remux for me. Any Directplay/stream is perfect. |
Thank you so much for this workaround! It fixes the problem. Maybe you should talk about this to someone on the Jellyfin team because it definitely fixes the problem. Are there any drawbacks to using this method? I had to make a fork, but how can I make a fork of Jellyfin automatically every time a new version is released? Or maybe there is another, easier solution? |
|
Big thanks for the contribution @fhelland !
Are you aware of any way to deploy this change using existing post-installation config files? I am running Jellyfin from a pre-built docker image and it would be a non-trivial endeavor to make the source code changes. |
I'm assuming no because the change to the file would require particular .dll(s) to be rebuilt and deployed, which also contains code for other files. Unless the authors make a configuration setting that lets you control this particular variable post deploy, I don't see this being possible. Especially since you're running containerised, you'd have to make a new build anyway. Happy to be wrong though. I installed from the .exe so I'd have to do a full migration to a custom fork, personally... Perhaps I could also just make this tiny change, build and publish the project corresponding to particular .DLL file on my local installation, overwriting what's there, that could work for both of our scenarios. If your image is pre built then you'd have to make your own though. |
There are no drawbacks, except that you end up with a greater number of shorter .ts files since FFmpeg attempts to use a shorter segment duration. I suspect this issue occurs because the .m3u8 playlist file that the Jellyfin server sends ahead of playback to Jellyfin Web does not always match the segments generated by FFmpeg. This mismatch happens only when resuming playback and if the source file has a non-fixed keyframe interval. If the source file has a fixed keyframe interval—such as a keyframe every 2 seconds (which can be verified with ffprobe)—resuming and seeking work without issues. Using a shorter hls_time value of 1 second ensures that the playlist generated by FFmpeg matches the one created ahead of playback. I tested this by running the FFmpeg command from the Jellyfin log file and comparing the resulting .m3u8 playlist with one generated from the same video file when remuxed from the start. The segment durations did not always match for corresponding segment numbers. When playback on Jellyfin WebOS reached a mismatched segment, playback would stop. LG seems to be very picky about the m3u8 file compared to other devices or browsers. |
Sorry to bother you @gnattu but apparently @fhelland found a good workaround! We will all be really happy to have this fix on our LG tvs 🥰 Many thanks |
Maybe more people should try this solution. After 1 day where everything works, this fix didn’t work for me,m anymore, i have again the same issues, i don’t know why. Anyway, i don’t know for how many people it works but for me it was temporary apparently. |
|
I'm not sure if this is the right way to patch my files but I followed @fhelland 's work around and rebuilt the server files. Then I copied the files in the Publish folder and override existing files in my Server folder. It didnt work and Jellyfin doesnt open anymore. Sorry im newb |
Did you rebuild the same version as what you have installed? They must match - exactly. You can just reinstall what version you had before. Next time back up the existing folder to save you time when it goes wrong. |
|
Turns out it was some of the existing files in the Server folder causing the issue. I ended up removing all the files in the Server folder and copying in the new build, adding the web files and ffmpeg files and it works now. And... This did fix the issue for me on the LG G4!! I'll keep you guys updated if it stops working... If no major issues would love to see this fix included in prod. thx @fhelland !!! |
|
I'm willing to try, I'm using docker, how hard is it to test this hack? @fhelland would you be able to propose this change for the next version? |
|
any news guys ? It seems @fhelland found a good enough solution, at least it can't be worse than what we have now :) |
|
I can confirm that "1 second segment length" workaround fixed the problem for me. I don't know if the fix is 100% reliable but we finally was able to watch remaining 2 hours of the film. Without the fix video after resume hangs in 30 seconds max.
It is (relatively) easy to rebuild patched docker image if you have ubuntu machine. See here. |
Great news! Would you be able to push the change for approval? |
Nope. I’m not involved in this project, but I’ve re-posted this issue in the main repository. Hopefully, it will get more visibility there. |
|
@ikarsokolov to contribute, you will need to
|
I've raised a PR on the thread's behalf, with credit to @fhelland's investigation and reasoning. I'm not sure on the leniency of the main project's PRs, but I'd be very surprised if it were accepted. Mainly on the grounds that it is very much a workaround rather than a fix. But I also agree it is better than what we have now, at least. I also don't believe there's a better known alternative right now. I wouldn't expect an answer any time soon, OS contributions can go months without even being opened... Best advice is to learn how build your own client, with the change, rather than wait on the main team. That's what I intend to do when I get a moment! A better long term solution might be to give users a setting they can change, at user profile level rather than server, for this segment length variable. However, that would require changes across multiple repos (as far as I understand), and is probably overkill for this issue. The root cause getting a fix would be great. It's a bit beyond my skill set though, and might not even be related to Jellyfin itself from what I've inferred. |
if this workaround is limited to Dolby Vision + remux mode + webos client it should have minimal impact on other users. And for the webos users the alternative is broken rewind/resume. I think dedicated setting is overkill in this case. From my point of view the main problems right now are:
|
True but official web os support hasn't been around for very long IIRC. So there might not be that many versions to consider? Unfortunately (and tbh rightly so) a contributor has disagreed and would indeed prefer the client side approach. It needs a bit more effort but there are suggested implementation details on the PR. Perhaps I'll have a crack at it early next week, ofc anyone else can do the same whenever. I'd rather go down the approach of making it configurable rather than hardcoding though. |
and others
(bug is still present with 10.9.11)
Hello all,
this specific issue doesn't seem to be addressed in other topics, some are similar but not really, and most of them are more or less inactives.
I have been hoping for a fix since I started with Jellyfin in march, but it hasn't come yet, so I'm trying my luck by opening this issue.
The issue:
When I try to resume a Dolby Vision movie, or if I start over and then skip ahead (more than a few minutes), then the movie will start normally in direct play, but after 10 seconds (sometimes a bit more, I have managed to watch more than 10min once!), it starts to freeze for a few seconds, then can eventually continue for a few more seconds but will start to hang very quickly.
If I don't touch anything for 1 or 2 minutes, I can see the movie "poster" flashing as if the movie stopped and started again, then it resumes the movie but this time it tries to transcode it, which gives bad colors and bad performance.
If I play the movie from the beginning, then it plays perfectly (in direct play).
If I start from the beginning and skip ahead without exceeding ~3min each steps, I can eventually reach the part I need to, but it takes a long time to reach the correct position, and very often, the subtitles become out of sync.
If I skip ahead more than ~3min in one go, then the "freezing/hanging/switching to transcoding" issue happens again when I stop skipping.
After reading the forum, I have disabled the "prefer mp4" option without more success.
The TV (LG G3) is new and my Jellyfin installation too, so I can't tell when the issue started, but it has been doing it since I started to use Jellyfin in march.
Currently, I have given up with Dolby Vision movies, they are unwatchable, unless I know for sure I can watch it in one go without the need to stop and resume next time, which I can very seldom do :(
I can't even disable Dolby Vision (on the TV or in Jellyfin) to avoid this issue and force HDR layer, so I'm pretty stuck whenever there is a DoVi movie.
Please find below a few examples of Video profiles that presents this issue (DV Profile 5 and 8.1 from what I can see):
I'm ready to help as much as I can, please let me know whatever you need and I'll try to get it asap :)
The text was updated successfully, but these errors were encountered: