[bug] LG webos + Dolby Vision =⛔ movie stutters then hangs when resuming or skipping ahead
megosugit opened this issue · 111 comments
(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):
Video
Title: 4K HEVC HDR
Codec: HEVC
AVC: No
Profile: Main 10
Level: 150
Resolution: 3840x1608
Aspect ratio: 2.40:1
Anamorphic: No
Interlaced: No
Framerate: 23.976025
Bitrate: 24443 kbps
Bit depth: 10 bit
Video range: HDR
Video range type: DOVIWithHDR10
DV title: DV Profile 8.1 (HDR10)
DV version major: 1
DV version minor: 0
DV profile: 8
DV level: 6
DV rpu preset flag: 1
DV el preset flag: 0
DV bl preset flag: 1
DV bl signal compatibility id: 1
Color space: bt2020nc
Color transfer: smpte2084
Color primaries: bt2020
Pixel format: yuv420p10le
Ref frames: 1
Video
Title: 4K HEVC HDR
Codec: HEVC
AVC: No
Profile: Main 10
Level: 150
Resolution: 3840x1606
Aspect ratio: 2.40:1
Anamorphic: No
Interlaced: No
Framerate: 24
Bitrate: 24795 kbps
Bit depth: 10 bit
Video range: HDR
Video range type: DOVIWithHDR10
DV title: DV Profile 8.1 (HDR10)
DV version major: 1
DV version minor: 0
DV profile: 8
DV level: 6
DV rpu preset flag: 1
DV el preset flag: 0
DV bl preset flag: 1
DV bl signal compatibility id: 1
Color space: bt2020nc
Color transfer: smpte2084
Color primaries: bt2020
Pixel format: yuv420p10le
Ref frames: 1
Video
Title: 4K HEVC HDR
Codec: HEVC
AVC: No
Profile: Main 10
Level: 150
Resolution: 3840x2160
Aspect ratio: 16:9
Anamorphic: No
Interlaced: No
Framerate: 24
Bitrate: 11494 kbps
Bit depth: 10 bit
Video range: HDR
Video range type: DOVIWithHDR10
DV title: DV Profile 8.1 (HDR10)
DV version major: 1
DV version minor: 0
DV profile: 8
DV level: 6
DV rpu preset flag: 1
DV el preset flag: 0
DV bl preset flag: 1
DV bl signal compatibility id: 1
Color space: bt2020nc
Color transfer: smpte2084
Color primaries: bt2020
Pixel format: yuv420p10le
Ref frames: 1
Video
Title: 4K - HEVC - HDR
Codec: HEVC
AVC: No
Profile: Main 10
Level: 150
Resolution: 3836x1600
Aspect ratio: 2.40:1
Anamorphic: No
Interlaced: No
Framerate: 23.976025
Bitrate: 16145 kbps
Bit depth: 10 bit
Video range: HDR
Video range type: DOVI
DV title: DV Profile 5
DV version major: 1
DV version minor: 0
DV profile: 5
DV level: 6
DV rpu preset flag: 1
DV el preset flag: 0
DV bl preset flag: 1
DV bl signal compatibility id: 0
Pixel format: yuv420p10le
Ref frames: 1
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 :)
i just tried to play a movie and seem to have the same issue..
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
i just tried to play a movie and seem to have the same issue..
what is you TV model ?
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.
This should get more attention, how can we get this thread more visibility ?
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:
If you do find an issue that matches, or closely matches, your issue, please make use of the 👍 reaction to confirm the issue also affects you or that you support the feature request. If you wish, add a comment as well describing your version of the issue or feature use case.
I just did that on your opening post. Everyone, please do that as well.
I suspect every WebOS users have this issue with Dolby Vision content. This should get more attention, how can we get this thread more visibility ?
I wonder if it is posted in the right place ?
Hmmm, I think you need to do a couple more things. Like:
Bugs should be tagged with [bug] at the beginning of their title.
Check the above link and see what else you need to do right, otherwise it might affect their response.
Hmmm, well, let's do this: https://jellyfin.org/docs/general/contributing/issues
Under "Searching and Voting" section, it said the following:
If you do find an issue that matches, or closely matches, your issue, please make use of the 👍 reaction to confirm the issue also affects you or that you support the feature request. If you wish, add a comment as well describing your version of the issue or feature use case.
I just did that on your opening post. Everyone, please do that as well.
I did too :p
and I changed the title,
thanks
@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.
Only point of this post is to indicate that the problem might be more elusive, only certain models, firmware versions, files etc.
In case it matters, none of my TVs are on WiFi.
Tested file:
Titel4K HEVC HDR
KodekHEVC
AVCNo
ProfilMain 10
Nivå150
Upplösning3840x1606
Bildförhållande2.40:1
AnamorfiskNo
SammanflätadNo
Bildfrekvens24
Bithastighet25313 kbps
Bitdjup10 bit
Video-omfångHDR
VideointervallstypDOVIWithHDR10
DV titelDV Profile 8.1 (HDR10)
DV huvudversion1
DV mindre version0
DV profil8
DV nivå6
Förinställd flagga för DV rpu1
Förinställd flagga för DV el0
Förinställd flagga för DV bl1
DV bl signalkompatibilitets-id1
Färgrymdbt2020nc
Färgöverföringsmpte2084
Färgprimärerbt2020
Pixelformatyuv420p10le
Referensbildrutor1
@gnattu or @GeorgeH005, is it something you would know about ?
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
FLAC codec only supports audio, not video.
TVs are meant for video only, and yet they have worse video compatibility than PCs and phones.
This is a serious problem.
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 FLAC codec only supports audio, not video. TVs are meant for video only, and yet they have worse video compatibility than PCs and phones.
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...
If it's in mp4 format, I guess I can test it. Is this issue only happening with mkv?
Have you tried to see if you can reproduce the same issue in other ways: plex, dlna, usb... If it's in mp4 format, I guess I can test it. Is this issue only happening with mkv?
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)
Jellyfin v10.9.11
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.
Have you tried to see if you can reproduce the same issue in other ways: plex, dlna, usb... If it's in mp4 format, I guess I can test it. Is this issue only happening with mkv?
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.
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:
- LG TVs won't play Dolby Vision in mkv, it will always use the HDR10 fallback
- Some LG TV models do not handle Dolby Vision in HLS either, makes the server side remuxing also not working
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:
ffmpeg -i input.mkv -c:v copy -c:a copy -strict -2 out.mp4
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.
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:
- LG TVs won't play Dolby Vision in mkv, it will always use the HDR10 fallback
- Some LG TV models do not handle Dolby Vision in HLS either, makes the server side remuxing also not working
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:
ffmpeg -i input.mkv -c:v copy -c:a copy -strict -2 out.mp4
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.
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:
- LG TVs won't play Dolby Vision in mkv, it will always use the HDR10 fallback
- Some LG TV models do not handle Dolby Vision in HLS either, makes the server side remuxing also not working
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:ffmpeg -i input.mkv -c:v copy -c:a copy -strict -2 out.mp4Hmmm, 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.
I'm not sure to understand. My LG TV can play DV in mkv very well with jellyfin, unless I skip ahead more than ~3min or if I resume a movie I already started.
Would it help if I try from a usb stick or with dlna to confirm if the issue is still present?
I'm not sure to understand. My LG TV can play DV in mkv very well with jellyfin, unless I skip ahead more than ~3min or if I resume a movie I already started.
Would it help if I try from a usb stick or with dlna to confirm if the issue is still present?
Because we are remuxing on the fly to mp4 or ts respectively. If we weren't dolby vision would not be triggered. You can try it for yourself if you want with an mkv and a USB but there was a relevant pull request that had all the details regarding this.
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:
- LG TVs won't play Dolby Vision in mkv, it will always use the HDR10 fallback
- Some LG TV models do not handle Dolby Vision in HLS either, makes the server side remuxing also not working
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:ffmpeg -i input.mkv -c:v copy -c:a copy -strict -2 out.mp4Hmmm, 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.
This inspired me to test it out and I found a workaround.
When remuxing, I wait until the orange gauge on the dashboard is full before I change the playback location. This worked for me.
If anyone else is like me, it would be a huge help right now if this orange bar could be displayed in the client as well.
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:
- LG TVs won't play Dolby Vision in mkv, it will always use the HDR10 fallback
- Some LG TV models do not handle Dolby Vision in HLS either, makes the server side remuxing also not working
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:
ffmpeg -i input.mkv -c:v copy -c:a copy -strict -2 out.mp4
@gnattu
As you said, I will try to use the mp4 format in the future.
Do you think this will work with other clients?
I'd like to know if the LG TV is the most picky device.
If you know of other types of clients that are picky about media files, please let me know
As you said, I will try to use the mp4 format in the future.
Do you think this will work with other clients?
mp4 has much better compatibility in general as mkv is a very complex container.
I'd like to know if the LG TV is the most picky device.
If you know of other types of clients that are picky about media files, please let me know
There are a lot of picky devices for direct play, but for most of them Jellyfin could do on-the-fly remuxing to make it work without a transcoding, and the HLS player quirks is what makes it work badly on LG TVs.
As you said, I will try to use the mp4 format in the future.
Do you think this will work with other clients?mp4 has much better compatibility in general as mkv is a very complex container.
I'd like to know if the LG TV is the most picky device.
If you know of other types of clients that are picky about media files, please let me knowThere are a lot of picky devices for direct play, but for most of them Jellyfin could do on-the-fly remuxing to make it work without a transcoding, and the HLS player quirks is what makes it work badly on LG TVs.
thnak you
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:
- LG TVs won't play Dolby Vision in mkv, it will always use the HDR10 fallback
- Some LG TV models do not handle Dolby Vision in HLS either, makes the server side remuxing also not working
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:ffmpeg -i input.mkv -c:v copy -c:a copy -strict -2 out.mp4Hmmm, 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.
I am not quite sure I understand you. Why is LG's HLS player being brought up? I am using Jellyfin's app on my TV to connect to my Jellyfin server to play the mkv files. Is the Jellyfin app actually using the HLS player to play the on-the-fly remux files?
@gnattu Changing one line in the web client to make webOS use hls.js seems to work well! Under direct play conditions dolby vision is triggered as usual, and when forcing a transcode or a remux, seeking works well even with fmp4. If you have any thoughts on what should be changed/tested I would be happy to help! It seems like a good solution for now.
Changing one line in the web client to make webOS use hls.js seems to work well
We were not using HLS.js for a reason as some models works exceptionally bad with that.
I am not quite sure I understand you. Why is LG's HLS player being brought up? I am using Jellyfin's app on my TV to connect to my Jellyfin server to play the mkv files. Is the Jellyfin app actually using the HLS player to play the on-the-fly remux files?
Because LG TVs cannot play Dolby Vision as Dolby Vision in mkv, so the server has to remux it, and the remux is delivered with HLS, which uses native HLS player of the LG TV.
Changing one line in the web client to make webOS use hls.js seems to work well
We were not using HLS.js for a reason as some models works exceptionally bad with that.
That's a shame, could still be a solution for newer models.
AI-generated script.
It has been tested for basic behavior, but has not yet been tested in many environments. Use with caution.
#!/bin/bash
mkv2mp4() {
if [ -z "$1" ]; then
echo "Usage: mkv2mp4 <directory_path> [default audio track number (starts from 0)]"
echo "Use only for HEVC videos that support Dolby Vision."
return 1
fi
# Modify and use the path correctly.
FFMPEG="/usr/lib/jellyfin-ffmpeg/ffmpeg"
if [ ! -f "$FFMPEG" ]; then
echo "Error: Cannot find ffmpeg: $FFMPEG"
return 1
fi
directory="$1"
audio_track="$2"
log_dir="${directory}/conversion_logs"
mkdir -p "$log_dir"
log_file="${log_dir}/conversion_$(date +%Y%m%d_%H%M%S).log"
echo "Conversion start time: $(date)" | tee -a "$log_file"
echo "----------------------------------------" | tee -a "$log_file"
find "$directory" -type f -name "*.mkv" -print0 | while IFS= read -r -d $'\0' input_file; do
filename="${input_file%.*}"
mp4_file="${filename}.mp4"
if [ -f "$mp4_file" ] && [ -s "$mp4_file" ]; then
echo "Skip: $mp4_file (already exists)" | tee -a "$log_file"
continue
fi
echo "Processing: $input_file" | tee -a "$log_file"
# Improved subtitle extraction
echo "Extracting subtitles..." | tee -a "$log_file"
# Extract subtitle stream information
$FFMPEG -i "$input_file" 2>&1 | while IFS= read -r line; do
if [[ $line =~ Stream.*Subtitle ]]; then
stream_index=$(echo "$line" | grep -o "#0:[0-9]*" | cut -d':' -f2)
language=$(echo "$line" | grep -oP "^.*?\((\w{2,3})\)" | grep -oP "\((\w{2,3})\)" | tr -d '()')
# Check subtitle codec type
codec_type=$(echo "$line" | grep -oP "Subtitle: \K[^,]*")
# Check subtitle type
subtitle_type=""
if [[ $line =~ \(forced\) ]]; then
subtitle_type="forced"
elif [[ $line =~ \(hearing[[:space:]]impaired\) ]] || [[ $line =~ \(SDH\) ]]; then
subtitle_type="sdh"
elif [[ $line =~ \(dub\) ]]; then
subtitle_type="dub"
fi
# Set output file extension
case $codec_type in
"subrip") ext="srt" ;;
"ass" | "ssa") ext="ass" ;;
"hdmv_pgs_subtitle") ext="sup" ;;
"dvd_subtitle") ext="sub" ;;
*) ext="srt" ;; # Default is srt
esac
# Generate output filename
if [ ! -z "$subtitle_type" ]; then
output_subtitle="${filename}.${language}.${subtitle_type}.${ext}"
else
output_subtitle="${filename}.${language}.${ext}"
fi
if [ -f "$output_subtitle" ] && [ -s "$output_subtitle" ]; then
echo "Skip: $output_subtitle (already exists)" | tee -a "$log_file"
continue
fi
echo "Extracting subtitle: $output_subtitle (codec: $codec_type)" | tee -a "$log_file"
# Use copy codec for ASS/SSA, PGS(SUP) subtitles
if [ "$codec_type" = "hdmv_pgs_subtitle" ] || [ "$codec_type" = "ass" ] || [ "$codec_type" = "ssa" ]; then
$FFMPEG -nostdin -i "$input_file" -map 0:${stream_index} -c:s copy \
-y "$output_subtitle" 2>> "$log_file" || {
echo "Error: Failed to extract subtitle - $output_subtitle" | tee -a "$log_file"
rm -f "$output_subtitle"
}
# Convert to srt for other cases
else
$FFMPEG -nostdin -i "$input_file" -map 0:${stream_index} -c:s srt \
-y "$output_subtitle" 2>> "$log_file" || {
echo "Error: Failed to extract subtitle - $output_subtitle" | tee -a "$log_file"
rm -f "$output_subtitle"
}
fi
fi
done
# MP4 Conversion
echo "Converting to MP4..." | tee -a "$log_file"
# Audio track settings
audio_options=""
if [ ! -z "$audio_track" ]; then
audio_count=$($FFMPEG -i "$input_file" 2>&1 | grep -c "Stream.*Audio")
if [ "$audio_track" -lt "$audio_count" ]; then
for ((i=0; i<audio_count; i++)); do
if [ "$i" -ne "$audio_track" ]; then
audio_options="$audio_options -disposition:a:$i 0"
fi
done
audio_options="$audio_options -disposition:a:$audio_track default"
else
echo "Error: Invalid audio track number. (Available tracks: 0-$((audio_count-1)))" | tee -a "$log_file"
return 1
fi
fi
# Execute MP4 conversion
$FFMPEG -nostdin -i "$input_file" -map 0:v -map 0:a -c copy \
-tag:v hvc1 \
-movflags +faststart+use_metadata_tags+write_colr \
-write_tmcd 0 \
-strict -2 \
$audio_options \
-y "$mp4_file" 2>> "$log_file" || {
echo "Error: MP4 conversion failed - $mp4_file" | tee -a "$log_file"
rm -f "$mp4_file"
}
echo "----------------------------------------" | tee -a "$log_file"
done
echo "Conversion end time: $(date)" | tee -a "$log_file"
}
mkv2mp4 "$1" "$2"AI-generated script. It has been tested for basic behavior, but has not yet been tested in many environments. Use with caution.
#!/bin/bash
mkv2mp4() {
if [ -z "$1" ]; then
echo "Usage: mkv2mp4 <directory_path> [default audio track number (starts from 0)]"
echo "Use only for HEVC videos that support Dolby Vision."
return 1
fi......
mkv2mp4 "$1" "$2"
I am currently using this script and accoring to few testing on my LG C2 (which is having the issue) after conversion to mp4 it works.
I was wondering if there would be any way to automate this conversion using tdarr tool ? (as a kind of automated workaround)
Changing one line in the web client to make webOS use hls.js seems to work well
We were not using HLS.js for a reason as some models works exceptionally bad with that.
That's a shame, could still be a solution for newer models.
What did you change? I’d like to try in my LG as this issue is quite annoying.
Changing one line in the web client to make webOS use hls.js seems to work well
We were not using HLS.js for a reason as some models works exceptionally bad with that.
That's a shame, could still be a solution for newer models.
What did you change? I’d like to try in my LG as this issue is quite annoying.
This line:
https://github.com/jellyfin/jellyfin-web/blob/2b0f028b6f1c471db16996a36d0d6ee6f23bde57/src/components/htmlMediaHelper.js#L53
to true. Bear in mind, this is very untested and just a quick personal experiment. I am sure the jellyfin team has their reasons for not using this. Nevertheless, in my very brief testing, it seemed promising.
Changing one line in the web client to make webOS use hls.js seems to work well
We were not using HLS.js for a reason as some models works exceptionally bad with that.
That's a shame, could still be a solution for newer models.
What did you change? I’d like to try in my LG as this issue is quite annoying.
This line: https://github.com/jellyfin/jellyfin-web/blob/2b0f028b6f1c471db16996a36d0d6ee6f23bde57/src/components/htmlMediaHelper.js#L53 to true. Bear in mind, this is very untested and just a quick personal experiment. I am sure the jellyfin team has their reasons for not using this. Nevertheless, in my very brief testing, it seemed promising.
How can I test it? I'm using docker.
Also, I tested a DV movie through DLNA and it fallback to HDR. To be honest, between this issue with DV and regular HDR, I would be happy to use only HDR if possible. Is there a settings to disable DV until it's fixed?
Hello,
I have the same issue. I’d like to add that what you’re discussing was already possible in version 10.8.13. This movie is in DV profile 8.1, but it starts with HDR, displaying decent image quality and, most importantly, without unnecessarily consuming resources. However, in more recent versions, something seems to have changed because this no longer works for me, and I can’t use Jellyfin with these movies in its updated version.
If you look at the image, when HDR works, it shows "Jellyfin for WebOS," and when it doesn’t, it uses the browser.
Could you consider allowing multiple servers without needing to log in to switch between them, or re-enable the functionality the old server had with DV 8.1?
Thank you for your work and assistance.
I’d like to add that what you’re discussing was already possible in version 10.8.13
10.8 does not play your files in dolby and it simply discards all dolby metadata and plays the HDR10 fallback.
Me gustaría agregar que lo que estás discutiendo ya fue posible en la versión 10.8.13
10.8 no reproduce sus archivos en dolby y simplemente descarta todos los metadatos de dolby y reproduce el respaldo HDR10.
I see, so why doesn’t it load HDR10 instead of remuxing the MKV directly? Thank you for your great work.
I see, so why doesn’t it load HDR10 instead of remuxing the MKV directly?
Because 10.8 did not implement such function to allow dolby vision playback.
I see, so why doesn’t it load HDR10 instead of remuxing the MKV directly?
Because 10.8 did not implement such function to allow dolby vision playback.
What about @GeorgeH005 fix? Wouldn't it be a quick fix to implement and help us all? 😍
Ya veo, entonces ¿por qué no carga HDR10 en lugar de remuxar el MKV directamente?
Porque 10.8 no implementó dicha función para permitir la reproducción de dolby vision.
Right, but then what do you recommend to use this? I’m using two Jellyfin servers to access the content. What solutions do you think we have?
I have three LG screens, and the issue happens on all of them. Maybe a new version for LG? Version 1.2.2 hasn’t been updated in a while, while the server releases new versions frequently.
Thank you for your prompt response.
@gnattu According to LG, webOS 5.0 and up support the same spec of MSE, EME (which shouldn't concern us), and HLS. That does sound promising considering LG themselves in their example app use Shaka-player, which does also utilise MSE for HLS, not their native player as far as I can tell. The problems reported on their repo were for versions < 5 so maybe this is worth at least some consideration.
Should note that the issue discussed here is more relevant to jellyfin/jellyfin-web, rather than the wrapper developed here.
Should note that the issue discussed here is more relevant to jellyfin/jellyfin-web, rather than the wrapper developed here.
It is beyond my knowledge, but from what you said, it seems a solution is possible and could be done by just editing one line ?
Would you still recommend to close this thread and open the same on jellyfin-web (I didn't find how to move it) ? Or do you reckon your fix is the solution ?
Debe tener en cuenta que el tema discutido aquí es más relevante para jellyfin/jellyfin-web, en lugar del contenedor desarrollado aquí.
It’s possible that the change coming from Jellyfin-web is the "problem," but perhaps it can be resolved from here at LG.
I believe a small update could address these issues:
- The ability to add multiple servers, not just one.
- Disable DV if it’s going to fail, or implement the solution mentioned regarding that line.
Thank you very much!
Changing one line in the web client to make webOS use hls.js seems to work well
We were not using HLS.js for a reason as some models works exceptionally bad with that.
That's a shame, could still be a solution for newer models.
What did you change? I’d like to try in my LG as this issue is quite annoying.
This line: https://github.com/jellyfin/jellyfin-web/blob/2b0f028b6f1c471db16996a36d0d6ee6f23bde57/src/components/htmlMediaHelper.js#L53 to true. Bear in mind, this is very untested and just a quick personal experiment. I am sure the jellyfin team has their reasons for not using this. Nevertheless, in my very brief testing, it seemed promising.
This doesn't seem to work on my LG C3 unfortunately. When I switch it to true, Jellyfin always transcodes DV media due to "the content's range not being supported". Ignoring this, even the transcoded media seems to have playback issues so I guess the C3 is one of the models on which HLS.js works "exceptionally bad" (even though it's fairly new).
After reverting back to the stock jellyfin-web build, I did some further testing. I would expect regular transcoded content (eg. lowering the bitrate), to behave the same way as my remux'ed DV content. Skipping further than the current transcoding progress should freeze the stream, though that isn't always happening.
When I play SDR content and force transcoding by lowering the bitrate, I can skip forward as much as I want without any freezing occurring.
When I play DV content and force transcoding by lowering the bitrate, the stream freezes when skipping ahead too far.
Waiting for the remux to finish also allows me to seek without freezes.
Shouldn't this issue be raised over at the jellyfin-web repo though?
This doesn't seem to work on my LG C3 unfortunately. When I switch it to true, Jellyfin always transcodes DV media due to "the content's range not being supported". Ignoring this, even the transcoded media seems to have playback issues so I guess the C3 is one of the models on which HLS.js works "exceptionally bad" (even though it's fairly new).
It did work on mine, although as mentioned beforehand, not much testing was conducted.
After reverting back to the stock jellyfin-web build, I did some further testing. I would expect regular transcoded content (eg. lowering the bitrate), to behave the same way as my remux'ed DV content. Skipping further than the current transcoding progress should freeze the stream, though that isn't always happening. When I play SDR content and force transcoding by lowering the bitrate, I can skip forward as much as I want without any freezing occurring. When I play DV content and force transcoding by lowering the bitrate, the stream freezes when skipping ahead too far.
Waiting for the remux to finish also allows me to seek without freezes.
That's about in line with what me and others have observed.
Shouldn't this issue be raised over at the jellyfin-web repo though?
It should, as I had also mentioned before, although at this point I am unsure of what can be done. The HLS.js idea should imo be tested a bit more extensively before being scrapped. When it comes to the current build, maybe something goes wrong when switching the playlist file being used in the player code? That was the only other thing I remember coming up with. Someone with more expertise than me should comment on this.
This doesn't seem to work on my LG C3 unfortunately. When I switch it to true, Jellyfin always transcodes DV media due to "the content's range not being supported". Ignoring this, even the transcoded media seems to have playback issues so I guess the C3 is one of the models on which HLS.js works "exceptionally bad" (even though it's fairly new).
It did work on mine, although as mentioned beforehand, not much testing was conducted.
After reverting back to the stock jellyfin-web build, I did some further testing. I would expect regular transcoded content (eg. lowering the bitrate), to behave the same way as my remux'ed DV content. Skipping further than the current transcoding progress should freeze the stream, though that isn't always happening. When I play SDR content and force transcoding by lowering the bitrate, I can skip forward as much as I want without any freezing occurring. When I play DV content and force transcoding by lowering the bitrate, the stream freezes when skipping ahead too far.
Waiting for the remux to finish also allows me to seek without freezes.That's about in line with what me and others have observed.
Shouldn't this issue be raised over at the jellyfin-web repo though?
It should, as I had also mentioned before, although at this point I am unsure of what can be done. The HLS.js idea should imo be tested a bit more extensively before being scrapped. When it comes to the current build, maybe something goes wrong when switching the playlist file being used in the player code? That was the only other thing I remember coming up with. Someone with more expertise than me should comment on this.
That's odd, didn't see you also have a C3. I am running WebOS24 rather than 23, though I doubt that has much of an impact. When you switched to HLS.js, were you using .ts (like me) or .mp4 containers? Do you still happen to have that build you made?
That's odd, didn't see you also have a C3. I am running WebOS24 rather than 23, though I doubt that has much of an impact. When you switched to HLS.js, were you using .ts (like me) or .mp4 containers? Do you still happen to have that build you made?
I think I was running WebOS24 at the time of the test. I was using fmp4 as ts worked even when using the "stock" build for me. It was applied on top of the commit with hash "2072cca0913d2654bb07652965434316dc4b2113" from master if I am not mistaken.
Made a new build of that specific commit, only thing I changed is the boolean to enable HLS.js for webos.
I just cant't get it to play any media for both ts and fmp4 containers, really don't know if I'm doing something wrong or somehow my TV FW is slightly different from yours.
I do agree we should investigate the HLS.js idea more but for me it seems my TV can't handle it for an unknown reason.
Made a new build of that specific commit, only thing I changed is the boolean to enable HLS.js for webos. I just cant't get it to play any media for both ts and fmp4 containers, really don't know if I'm doing something wrong or somehow my TV FW is slightly different from yours.
I do agree we should investigate the HLS.js idea more but for me it seems my TV can't handle it for an unknown reason.
Appreciate you trying. Indeed we need to test more, but I do not have the time right now.
I read your discussion with great interest. I keep hopes for a fix 🤞
Would you know why, when resuming a DV movie, it works perfectly for some seconds/minutes before freezing? The TV seems to properly do its job at first then something happens and it goes to sh*t 😅
I also tried enabling the HLS.js by changing that one line of boolean. I have a LG G4 and it did not resolve the issue for me for the mkv dv movie i am trying to play. Hopefully there is a solution soon since its way too annoying remuxing every mkv dv file manually to play them.
We can do little if the LG TVs cannot handle HLS properly and does not play DV with full DV at all in mkv files. The compromise we can made is to add a switch to "give up DV contents and direct play mkv files". So that the mkv files are played in HDR fallback to workaround the compatibility issues.
We can do little if the LG TVs cannot handle HLS properly and does not play DV with full DV at all in mkv files. The compromise we can made is to add a switch to "give up DV contents and direct play mkv files". So that the mkv files are played in HDR fallback to workaround the compatibility issues.
That would be a nice workaround!
But why is it able to play it properly for several minutes before starting to freeze?? It seems capable
But why is it able to play it properly for several minutes before starting to freeze?? It seems capable
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.
Say you immediately skip to the end of a movie, the player will overrule that and skip as far forward as Jellyfin has already transcoded/remuxed.
Still not ideal as you'll have to do a few skips until you finally reach the part you were looking for, but at least it doesn't freeze.
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).
Example of problem files (mediainfo):
Secret.Level.S01.txt
Squid.Game.S02.txt
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.
The segment length is specified here:
https://github.com/jellyfin/jellyfin/blob/release-10.10.z/MediaBrowser.Controller/Streaming/StreamState.cs#L101
change line 101 from 6 to 1. So I had to clone the repository, do the change and then build the server with dotnet sdk and run the server with then new binary.
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.
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.
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.
if (userAgent.Contains("Web0S", StringComparison.OrdinalIgnoreCase))
{
return 1;
}
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
LG 23.20.39
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.
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. The segment length is specified here: https://github.com/jellyfin/jellyfin/blob/release-10.10.z/MediaBrowser.Controller/Streaming/StreamState.cs#L101 change line 101 from 6 to 1. So I had to clone the repository, do the change and then build the server with dotnet sdk and run the server with then new binary.
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.
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 !
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.
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.
Big thanks for the contribution @fhelland !
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.
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.
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. The segment length is specified here: https://github.com/jellyfin/jellyfin/blob/release-10.10.z/MediaBrowser.Controller/Streaming/StreamState.cs#L101 change line 101 from 6 to 1. So I had to clone the repository, do the change and then build the server with dotnet sdk and run the server with then new binary.
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.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?
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.
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.
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.
if (userAgent.Contains("Web0S", StringComparison.OrdinalIgnoreCase)) { return 1; }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.
Sorry to bother you @gnattu but apparently @fhelland found a good workaround!
Would it be something you would accept to push?
We will all be really happy to have this fix on our LG tvs 🥰
Many thanks
Sorry to bother you @gnattu but apparently @fhelland found a good workaround! Would it be something you would accept to push?
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
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 :)
can we add it for the next release ? @GeorgeH005 maybe ? ;-) ;-)
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.
I'm willing to try, I'm using docker, how hard is it to test this hack?
It is (relatively) easy to rebuild patched docker image if you have ubuntu machine. See here.
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.
I'm willing to try, I'm using docker, how hard is it to test this hack?
It is (relatively) easy to rebuild patched docker image if you have ubuntu machine. See here.
Great news!
In my case, I use LG DLNA to finish my movies 😢
Would you be able to push the change for approval?
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
- make a fork
- Push your changes to a branch in the fork
- Open a pull request from the branch in your fork against the master branch in the upstream repo.
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.
I'm willing to try, I'm using docker, how hard is it to test this hack?
It is (relatively) easy to rebuild patched docker image if you have ubuntu machine. See here.
Great news!
In my case, I use LG DLNA to finish my movies 😢Would you be able to push the change for approval?
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.
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.
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:
- we don't know how reliably this workaround is, it needs more testing
- how well it works across different webos versions, especially the old ones. Without possibility of user upgrade.
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.
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:
- we don't know how reliably this workaround is, it needs more testing
- how well it works across different webos versions, especially the old ones. Without possibility of user upgrade.
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.
Hi, I'm experiencing the same issue, and would like to implement what gnattu is suggesting, however, I'm not experienced at all in this subject. I've been able to build the modified web client, but I'm having trouble combining it with the WebOS wrapper.
Thanks for any tips and help
Hi, I'm experiencing the same issue, and would like to implement what gnattu is suggesting, however, I'm not experienced at all in this subject. I've been able to build the modified web client, but I'm having trouble combining it with the WebOS wrapper.
Thanks for any tips and help
I'm currently wrapping up some changes (based on gnattu's feedback) to merge in, that will allow users to toggle this workaround on or off as a setting. I don't believe the webos wrapper will require any changes, but I'll take a look too.
Hi, I'm experiencing the same issue, and would like to implement what gnattu is suggesting, however, I'm not experienced at all in this subject. I've been able to build the modified web client, but I'm having trouble combining it with the WebOS wrapper.
Thanks for any tips and helpI'm currently wrapping up some changes to merge that will allow users to toggle this workaround on or off as a setting. I don't believe the webos wrapper will require any changes, but I'll take a look too.
That’s great news, i can’t wait!
I think this is what gnattu was leaning toward... I have raised the PR for now, we will have to wait and see what they say. jellyfin/jellyfin-web#6530
In the meantime feel free to test/use this feature yourselves.
I think this is what gnattu was leaning toward... I have raised the PR for now, we will have to wait and see what they say. jellyfin/jellyfin-web#6530
In the meantime feel free to test/use this feature yourselves.
I have subscribed to the new PR, I'm following with great interest ! It seems you are almost there 👍
I see the PR is scheduled for the v10.11.0 (1st of April).
I'm not sure how it works, but I see there is a v10.10.7 listed, is it better to include it also in this release ?
Since you are all WebOS users, I was wondering if you had the same recent issue as I have: when I watch a movie, if I press Right or Left on the remote control, it skips some seconds, but then the focus doesn't remain on the video progress bar, and I cannot press again Right or Left.
I believe it has happened after 10.10.5.
I think this is what gnattu was leaning toward... I have raised the PR for now, we will have to wait and see what they say. jellyfin/jellyfin-web#6530
In the meantime feel free to test/use this feature yourselves.
Well done. Wasn't aware you could implement it in jellyfin-web. I've now been using the 1 seconds hack for a while and it has worked for all my files. So far it seems like a good workaround, at least for the C3.
If it's possible, you could implement it only for remux. It's not really needed for transcoding as FFmpeg can then insert new key-frames and generate equal length segments (3 seconds I think). The webOS issue is only there if you have segment length less than the requested hls_time, which the current HLS segmentation logic in FFmpeg allows for if the input file has a variable GOP interval.
I think this is what gnattu was leaning toward... I have raised the PR for now, we will have to wait and see what they say. jellyfin/jellyfin-web#6530
In the meantime feel free to test/use this feature yourselves.Well done. Wasn't aware you could implement it in jellyfin-web. I've now been using the 1 seconds hack for a while and it has worked for all my files. So far it seems like a good workaround, at least for the C3.
If it's possible, you could implement it only for remux. It's not really needed for transcoding as FFmpeg can then insert new key-frames and generate equal length segments (3 seconds I think). The webOS issue is only there if you have segment length less than the requested hls_time, which the current HLS segmentation logic in FFmpeg allows for if the input file has a variable GOP interval.
I have had an extremely confusing round of testing.
I updated to 10.10.6 today, just installed on top of my existing installation. I then put my jellyfin-web changes (the changes in the PR, but customised for jellyfin 10.10.6, as that repo is on 10.11.0) into my server's install. This is before I'd even tried the new updates in 10.10.6 itself.
I was observing that when I turned the segmentlength fix on, the issues were still present and I had problems, just like before. When the fix was disabled, I suddenly had zero issues. I then realised that sending the segmentlength as undefined when the user disables this fix isn't really any different to what we had before, where the client didn't even specify the segmentlength property.
So, then I reverted my changes from the server back to the vanilla 10.10.6 install. I am currently able to play any of my DV files, whether remux or not, without any issues..... So I'm just totally confused. This was definitely broken for me in previous versions, just as the issue creator @megosugit described.
Can anyone else on LG TVs update their jellyfin server to 10.10.6 and see if their issues are fixed?
This is the info from the file I was testing with, I have an LG C4 with all the latest updates possible. I have the "Prefer fMP4-HLS Media Container" setting disabled if it is of any relevance. My server is on a windows 11 machine.
Playback Info:
- Player: Html Video Player
- Play method: Direct streaming
- Protocol: http
- Stream type: Video
Video resolution: 3840x2160
Direct Streaming Info:
- Direct Stream path: HEVC (direct)
- Audio codec: AAC
Original Media Info:
- Container: mkv
- Size: 72.2 GiB
- Bitrate: 68.1 Mbps
- Video codec: HEVC Main 10
- Video bitrate: 63.1 Mbps
- Video range: HDR10
- Audio codec: TRUEHD Dolby TrueHD + Dolby Atmos
- Audio bitrate: 3.7 Mbps
- Audio sample rate: 48000 Hz
- Audio bit depth: 24
@patrickd77-eng I'm still having the same issues on 10.10.6.
Both server and web clients are unmodified, on an LG C3 with prefer MP4-HLS disabled as well.
I think this is what gnattu was leaning toward... I have raised the PR for now, we will have to wait and see what they say. jellyfin/jellyfin-web#6530
In the meantime feel free to test/use this feature yourselves.Well done. Wasn't aware you could implement it in jellyfin-web. I've now been using the 1 seconds hack for a while and it has worked for all my files. So far it seems like a good workaround, at least for the C3.
If it's possible, you could implement it only for remux. It's not really needed for transcoding as FFmpeg can then insert new key-frames and generate equal length segments (3 seconds I think). The webOS issue is only there if you have segment length less than the requested hls_time, which the current HLS segmentation logic in FFmpeg allows for if the input file has a variable GOP interval.I have had an extremely confusing round of testing.
I updated to 10.10.6 today, just installed on top of my existing installation. I then put my jellyfin-web changes (the changes in the PR, but customised for jellyfin 10.10.6, as that repo is on 10.11.0) into my server's install. This is before I'd even tried the new updates in 10.10.6 itself.
I was observing that when I turned the segmentlength fix on, the issues were still present and I had problems, just like before. When the fix was disabled, I suddenly had zero issues. I then realised that sending the segmentlength as undefined when the user disables this fix isn't really any different to what we had before, where the client didn't even specify the segmentlength property.
So, then I reverted my changes from the server back to the vanilla 10.10.6 install. I am currently able to play any of my DV files, whether remux or not, without any issues..... So I'm just totally confused. This was definitely broken for me in previous versions, just as the issue creator @megosugit described.
Can anyone else on LG TVs update their jellyfin server to 10.10.6 and see if their issues are fixed?
This is the info from the file I was testing with, I have an LG C4 with all the latest updates possible. I have the "Prefer fMP4-HLS Media Container" setting disabled if it is of any relevance. My server is on a windows 11 machine.
Playback Info:
- Player: Html Video Player
- Play method: Direct streaming
- Protocol: http
- Stream type: Video
Video resolution: 3840x2160
Direct Streaming Info:
- Direct Stream path: HEVC (direct)
- Audio codec: AAC
Original Media Info:
- Container: mkv
- Size: 72.2 GiB
- Bitrate: 68.1 Mbps
- Video codec: HEVC Main 10
- Video bitrate: 63.1 Mbps
- Video range: HDR10
- Audio codec: TRUEHD Dolby TrueHD + Dolby Atmos
- Audio bitrate: 3.7 Mbps
- Audio sample rate: 48000 Hz
- Audio bit depth: 24
I'm not sure, but I believe it can work sometimes after a complete TV restart. Did you restart the whole TV before your test?
I think this is what gnattu was leaning toward... I have raised the PR for now, we will have to wait and see what they say. jellyfin/jellyfin-web#6530
In the meantime feel free to test/use this feature yourselves.Well done. Wasn't aware you could implement it in jellyfin-web. I've now been using the 1 seconds hack for a while and it has worked for all my files. So far it seems like a good workaround, at least for the C3.
If it's possible, you could implement it only for remux. It's not really needed for transcoding as FFmpeg can then insert new key-frames and generate equal length segments (3 seconds I think). The webOS issue is only there if you have segment length less than the requested hls_time, which the current HLS segmentation logic in FFmpeg allows for if the input file has a variable GOP interval.I have had an extremely confusing round of testing.
I updated to 10.10.6 today, just installed on top of my existing installation. I then put my jellyfin-web changes (the changes in the PR, but customised for jellyfin 10.10.6, as that repo is on 10.11.0) into my server's install. This is before I'd even tried the new updates in 10.10.6 itself.
I was observing that when I turned the segmentlength fix on, the issues were still present and I had problems, just like before. When the fix was disabled, I suddenly had zero issues. I then realised that sending the segmentlength as undefined when the user disables this fix isn't really any different to what we had before, where the client didn't even specify the segmentlength property.
So, then I reverted my changes from the server back to the vanilla 10.10.6 install. I am currently able to play any of my DV files, whether remux or not, without any issues..... So I'm just totally confused. This was definitely broken for me in previous versions, just as the issue creator @megosugit described.
Can anyone else on LG TVs update their jellyfin server to 10.10.6 and see if their issues are fixed?
This is the info from the file I was testing with, I have an LG C4 with all the latest updates possible. I have the "Prefer fMP4-HLS Media Container" setting disabled if it is of any relevance. My server is on a windows 11 machine.
Playback Info:
- Player: Html Video Player
- Play method: Direct streaming
- Protocol: http
- Stream type: Video
Video resolution: 3840x2160
Direct Streaming Info:
- Direct Stream path: HEVC (direct)
- Audio codec: AAC
Original Media Info:
- Container: mkv
- Size: 72.2 GiB
- Bitrate: 68.1 Mbps
- Video codec: HEVC Main 10
- Video bitrate: 63.1 Mbps
- Video range: HDR10
- Audio codec: TRUEHD Dolby TrueHD + Dolby Atmos
- Audio bitrate: 3.7 Mbps
- Audio sample rate: 48000 Hz
- Audio bit depth: 24
I'm not sure, but I believe it can work sometimes after a complete TV restart. Did you restart the whole TV before your test?
It had been restarted recently yeah. I'll have to look into a bit more. Obviously, I'm very confused as to why it has started working flawlessly...
I was having issues both for direct stream and remux in the past. Maybe it'll return, not sure.
I don't transcode, only direct stream (and remux if it decides to).
I'm on webos 23.20.40 and the latest jellyfin app in the webos store.