Audio and visual tracks start at different times on LG TVs

[BionicLlama]

I have not been able to discern a rhyme or reason for this, or been able to reproduce this 100% of the time every time.

WebOS25, UA7000 TV. I've tested this with MPEG2VIDEO and HEVC (all of my 1080p and up files are HEVC for storage concerns). I first mucked around with Star Trek: First Contact. I have it in 1080p MKV, 4K MKV, and 4K MP4. Several times in a row there was a slight delay in the audio. Pausing and unpausing resulted in the audio playing first, and then the video started playing. Going to the setting to change the audio delay in TV settings, setting it to 1 results in the audio track outright stopping and then starting again, landing where it's supposed to be. I haven't noticed this sort of thing happening again after the audio's been corrected.

Is this a TV issue or a Jellyfin issue, and what further info is needed if so?

[Rust]

sounds like a problem with transcoding I'm guessing your tv is not compatible with the format you are using for direct play . are You using hardware transcoding with a gpu or just your cpu. What are you using for your setup?

[BionicLlama]

I'm legitimately having trouble finding a response to this that isn't just covered in snark. It's transcoding MPEG2? It is not transcoding, and only remuxes because it doesn't like video tracks labeled "Dolby Vision Profile 8.1" while in MKV format.

[BionicLlama]

So I've selected Star Trek: First Contact as my guinea pig, but it happens with just about every movie. Almost every time I start it, whether it's 1080p or 4K (MKV or MP4), the audio and video tracks are out of sync until I hit the delay, almost like the audio track on a timeline being offset by a half-second. Putting TV Speaker Delay from 0 to 1 and then back again fixes it. There's an audible gap in audio while it rights itself. This is really annoying and I hope someone knows what the devil the cause is. Is it something that can be solved with a soundbar, or is it server-side?

[esjaysee]

Try updating the TV software?

[BionicLlama]

Try updating the TV software?

It's already on the latest patch.

[raulo1985]

Do you have the prefer fMP4-HLS setting enabled or disabled on your WebOS client? Try disabling it if it's enabled. And if that doesn't work, try enabling it again and also enable the use shorter segments setting. And I would remux the file first before testing those settings, MKV is problematic on WebOS, specially with DV.

If nothing of the above works and if you can and have backups of your setup, I would try downgrading to JF 10.11.2 (if you do, don't forget to have backups). Since JF 10.11.3 a commit was reverted and the web client is using the WebOS native player again instead of hls.js. Some users (including myself) have better results avoiding the WebOS native player, which is kind of buggy. JF 10.11.2 still used hls.js in the case of WebOS. If you could try this, I would reinstall/downgrade jellyfin-server and jellyfin-web to version 10.11.2, and try with your files (ideally MP4) with both prefer fMP4-HLS and use shorter segments settings enabled.

[BionicLlama]

Do you have the prefer fMP4-HLS setting enabled or disabled on your WebOS client? Try disabling it if it's enabled. And if that doesn't work, try enabling it again and also enable the use shorter segments setting. And I would remux the file first before testing those settings, MKV is problematic on WebOS, specially with DV.

If nothing of the above works and if you can and have backups of your setup, I would try downgrading to JF 10.11.2 (if you do, don't forget to have backups). Since JF 10.11.3 a commit was reverted and the web client is using the WebOS native player again instead of hls.js. Some users (including myself) have better results avoiding the WebOS native player, which is kind of buggy. JF 10.11.2 still used hls.js in the case of WebOS. If you could try this, I would reinstall/downgrade jellyfin-server and jellyfin-web to version 10.11.2, and try with your files (ideally MP4) with both prefer fMP4-HLS and use shorter segments settings enabled.

So one problem I have is that my TV is not the only TV in the house. The roommate uses an Insignia Android TV, and since the androidTV client is updated far more often than the WebOS client is, that might prove problematic.

I did have a thought though, could the audio being transcoded to AAC be a problem?

[BionicLlama]

Do you have the prefer fMP4-HLS setting enabled or disabled on your WebOS client? Try disabling it if it's enabled. And if that doesn't work, try enabling it again and also enable the use shorter segments setting. And I would remux the file first before testing those settings, MKV is problematic on WebOS, specially with DV.

If nothing of the above works and if you can and have backups of your setup, I would try downgrading to JF 10.11.2 (if you do, don't forget to have backups). Since JF 10.11.3 a commit was reverted and the web client is using the WebOS native player again instead of hls.js. Some users (including myself) have better results avoiding the WebOS native player, which is kind of buggy. JF 10.11.2 still used hls.js in the case of WebOS. If you could try this, I would reinstall/downgrade jellyfin-server and jellyfin-web to version 10.11.2, and try with your files (ideally MP4) with both prefer fMP4-HLS and use shorter segments settings enabled.

Okay, so a re-remux to mp4 from a fresh rip with un-transcoded audio results in the same problem. With all of those settings in various configurations, nothing changes.   I feel like I'm being cursed with this.

So the WebOS client will behave differently based on the Jellyfin server version?

[EDIT] It seems downgrading to 10.11.2 has done the trick. Where the problematic movie had delayed audio every time, now it's fine. I would never have thought to downgrade Jellyfin if not for your advice, thank you very much!

[raulo1985]

Do you have the prefer fMP4-HLS setting enabled or disabled on your WebOS client? Try disabling it if it's enabled. And if that doesn't work, try enabling it again and also enable the use shorter segments setting. And I would remux the file first before testing those settings, MKV is problematic on WebOS, specially with DV.

If nothing of the above works and if you can and have backups of your setup, I would try downgrading to JF 10.11.2 (if you do, don't forget to have backups). Since JF 10.11.3 a commit was reverted and the web client is using the WebOS native player again instead of hls.js. Some users (including myself) have better results avoiding the WebOS native player, which is kind of buggy. JF 10.11.2 still used hls.js in the case of WebOS. If you could try this, I would reinstall/downgrade jellyfin-server and jellyfin-web to version 10.11.2, and try with your files (ideally MP4) with both prefer fMP4-HLS and use shorter segments settings enabled.

Okay, so a re-remux to mp4 from a fresh rip with un-transcoded audio results in the same problem. With all of those settings in various configurations, nothing changes.   I feel like I'm being cursed with this.

So the WebOS client will behave differently based on the Jellyfin server version?

[EDIT] It seems downgrading to 10.11.2 has done the trick. Where the problematic movie had delayed audio every time, now it's fine. I would never have thought to downgrade Jellyfin if not for your advice, thank you very much!

You're welcome   . Apparently your setup has one of those buggy native HLS players and there's no combination of settings that can make it work in an acceptable way. So your best bet is to use hls.js instead of the native player, and the last JF version that used it with WebOS was 10.11.2.

I understand the concept of wanting that everything works out of the box without needing the user to tweak many technical settings, but imo this is one case when it's almost unavoidable. With current releases there's no way I can make it work without using hls.js (in my case, I build from source and modify the code to use hls.js, but a simpler fix is to just stay on 10.11.2), and apparently I'm not the only one. So if I didn't know about hls.js and the commit that was reverted, I wouldn't be able to keep using JF with my C1. Your issue (and mine) could be a good reason to add a toggeable setting only for WebOS to enable or disable hls.js (because there are people that have better experience with the native player. Consistency is not LG's thing). Hopefully LG fixes its player, but until then (if it happens), the toggeable setting is the best I can think of without adding too many technical settings that might confuse the user.

Anyway, glad I could be of help and that things are working as expected now.