LG G5 dropped DTS again, and Emby didn't work...?

[TurkeyMan 17]

I got a G5 a few months ago now, and the Emby app seems to think that the TV supports DTS, but it doesn't. It just transmits the bitstream and it's silent rather than automatically transcoding like it does on my CX (which also doesn't support DTS).

 

It's been several months and there have been a couple of Emby updates, but it's not fixed... is there a reason? 80% of my film library doesn't play anymore  .. I had guessed it would have been resolved in the very next update.

I have tried "playback correction" to force transcoding the audio; stats for nerds does show that it's kicked into transcoded audio mode, and it makes sound, but for some reason the stream freezes and the UI stops responding after about 5-10 seconds. All UI just goes unresponsive until I stop playback after enabling first level playback correction.

If I very quickly hit payback correction a second time to engage video transcoded too, then it actually works; stats for nerds shows both audio and video are being transcoded, and it doesn't freeze anymore, but the video looks like shit... unwatchable

So, can we just get this fixed? It works fine on my LG CX, which Emby seems to know doesn't support DTS and it just does the right thing. LG 5-series client needs to ask the server to transcoded...

[SamES 1056]

Thanks for reporting.

Actually, I think you might be the first person that's reported this as being an issue on 2025 models, so we need to get this into the next update.  I believe you are correct about LG dropping DTS support again.

Do you know if it has been dropped on all 2025 models?

[TurkeyMan 17]

Sorry, I only have this G5 to test, dunno for sure about C5/B5...

I've just realized too just now while trying to pick something else to watch that all my DV P5 material is also not playing correctly. The TV shows 'Dolby Atmos' at the top right, no HDR or Dolby Vision, and displays the wrong colour space

This is actually quite terrifying, I hope there's a solution... all the same material that's been playing perfectly on my CX for years.

Edited August 22, 2025 by TurkeyMan

[visproduction 315]

https://www.techradar.com/televisions/lg-removes-dts-audio-from-its-2025-tvs-heres-what-that-means-in-practice

 

[SamES 1056]

6 hours ago, TurkeyMan said:

Sorry, I only have this G5 to test, dunno for sure about C5/B5...

I've just realized too just now while trying to pick something else to watch that all my DV P5 material is also not playing correctly. The TV shows 'Dolby Atmos' at the top right, no HDR or Dolby Vision, and displays the wrong colour space

This is actually quite terrifying, I hope there's a solution... all the same material that's been playing perfectly on my CX for years.

For the no HDR issue, can you confirm if it is DirectPlay or transcoding?  Can you please attach server and any ffmpeg logs for an example that has this issue?  Thanks

[SamES 1056]

9 hours ago, TurkeyMan said:

I got a G5 a few months ago now, and the Emby app seems to think that the TV supports DTS, but it doesn't.

Should be fixed in the next release.

Be aware that this will cause the audio stream to be converted to AC3, you still won't get DTS.

You might be better off to manually add AC3 tracks to your files. The benefits being:

• You can resolve this issue now as you will just ignore the DTS track
• You could specify higher quality AC3 encoding compared to the servers optimised settings
• You only after to do this once instead of the server doing it on the fly for every playback
• The file will continue to DirectPlay which will minimise the chance of other negative effects from on the fly conversion such as DV/HDR issue, server load, etc.

See these two posts for examples on how to do this in single file and batch mode:

 

 

[TurkeyMan 17]

2 hours ago, SamES said:

Should be fixed in the next release.

Be aware that this will cause the audio stream to be converted to AC3, you still won't get DTS.

Perfect! Thank you!Of course, I expect auto transcoding to AC3; this was working fine on my CX for years.

2 hours ago, SamES said:

You might be better off to manually add AC3 tracks to your files. The benefits being:

• You can resolve this issue now as you will just ignore the DTS track
• You could specify higher quality AC3 encoding compared to the servers optimised settings
• You only after to do this once instead of the server doing it on the fly for every playback
• The file will continue to DirectPlay which will minimise the chance of other negative effects from on the fly conversion such as DV/HDR issue, server load, etc.

I see no reason to transcode my media;

1. No TV exists for a lifetime, I don't want to butcher my archive quality media for one TV

2. Many people share my library, with many different TV's, it's impossible to form media files that suit all devices; Emby must aggressively transcode to suit whatever device is playing

3. I have thousands, maybe 10s of thousands of media... it would take me months to format it all specifically for the G5... it could meanwhile break on my friends and families TV's, and then what when I get a G8 or change teams to Sony or whatever?

4. I'm not a fan of adding a bunch of duplicate tracks to the media; it doesn't play well; 1, usually the compatibility track needs to come first, or the device won't select it by default and you transcode anyway, 2, if the compatibility track DOES come first, then nobody ever selects the best track for their player and just roll with the most inferior transcoded experience anyway!

Emby's realtime transcoding is the best thing about the software. Lean-in to that awesome feature! I desperately wish Emby would do MP4 transcoding for LG TV's when playing any DV media in MKV files... I transcode all MKV content to MP4, but it's a lossy conversion (subs -> mov_text) and I feel sad every time, because I'm destroying the source material.

Please consider adding DV MKV->MP4 transcoding; `ffmpeg -i [src.mkv] -c copy -c:s mov_text -map 0:v -map 0:a -map 0:s -strict unofficial dst.mp4` is all it takes, unless the source mkv also has pgs subs and/or unsupported audio format; then I have to work out the ID's of all bitmap sub files and selectively strip those streams from the dest, which is something that should be performed so much nicer by emby! (It's a tragedy to destroy my archive media just for LG players! also, I can't share/seed any of my archive after I've butchered it)

 

I'll experiment with the DV playback from memory stick shortly and get back to you...

Edited August 23, 2025 by TurkeyMan

[TurkeyMan 17]

Okay, so I tested some DV P5 content from a memory stick, it played fine. I also went back and tested the same content in Emby, and it also played fine this morning. My theory is that because I was trying to force a bunch of media into compatibility mode last night (to play films with DTS tracks, and stop the freezing) that some piece of state was retained when I tried to play the DV media and it didn't attempt to direct play even though it was a different title... all P5 media wasn't working last night; so yeah, my best guess is some bad state was being retained somewhere.

[rbjtech 5282]

The beta release has also added support for external audio files -

• Support external audio tracks for movies and episodes

So you now have the additional option to add better quality / pre-made external audio files vs a transcoded version.

Depending on the naming of the files, I believe these can act as Default audio without the need to add tracks within the MKV.

ie adding

<movie file name>.default.eac3 

will add a Dolby Digital Plus file and make it the default audio playback option - as I believe external default files are a preference to internal ones - but not 100% on that.  @Luke?

[Luke 42077]

2 minutes ago, rbjtech said:

 

will add a Dolby Digital Plus file and make it the default audio playback option - as I believe external default files are a preference to internal ones - but not 100% on that.  @Luke?

No they are not. Not for audio, because you're going to lose direct play with external audio files.

[TurkeyMan 17]

12 minutes ago, Luke said:

No they are not. Not for audio, because you're going to lose direct play with external audio files.

Just lean-in to realtime transcoding; it's very fast if you're not transcoding the video stream. It's by far the best feature of Emby, and it should be celebrated.

There are many devices playing the media, they all need different treatment; their respective clients should know the proper way to request the media is massaged by the server for each device.

[rbjtech 5282]

10 minutes ago, TurkeyMan said:

Just lean-in to realtime transcoding; it's very fast if you're not transcoding the video stream. It's by far the best feature of Emby, and it should be celebrated.

There are many devices playing the media, they all need different treatment; their respective clients should know the proper way to request the media is massaged by the server for each device.

I believe Luke was replying to the 'Default' part of my question - ie Direct play (video) will be prefered over transcode, BUT if the external audio track is then the same (or better) then what the transcoded audio would have been - then it should just use that file instead and not use the on-the-fly potentially lower quality audio transcode.     Worth testing to see what combo's Emby attempts to use imo. 

Edited August 23, 2025 by rbjtech

[TurkeyMan 17]

It's still a pointless exercise though; I'm just going to type the exact same ffmpeg command that emby's server could execute in realtime to generate any parallel audio streams; and then storing and managing those files is nothing more than a hassle, and listing additional streams in the audio stream selector is equally a confusing hassle for normies. Maybe it matters for weak or feeble media servers, but I reckon most people spec their media servers understanding that Emby may do realtime transcoding. Audio or bitstream transcodes are nothing; assuming no video transcode, Emby is welcome to transcode to its hearts content, in particular; DV mkv -> mp4!

[rbjtech 5282]

It is not pointless at all. ffmpeg is a poor audio conversion utility - there are far better utilities to convert audio.  Some formats ffmpeg can't convert to at all - such as to DTS or 7.1 AAC for example.   So yes, the Emby transcoding process via ffmpeg will get you 'audio', but currently it's low bitrate poor(ish) quality 5.1 AC3 at best. 

 

Edited August 23, 2025 by rbjtech

[TurkeyMan 17]

Yeah, sure. Granted that if you want to go to the effort of managing these streams for an improved experience, then the world is your oyster. But even in the event that it is supported to accept audio separated into external streams; Emby still needs to remux that external audio track into the stream to transmit the media to the player. If you want to manage such an external stream, it's a nice option to have, but the machinery is already engaged to just transcode to ac3 with no additional trouble. I don't think it simplifies this problem space in any way... maybe I just missed the point?

If people want to curate to their local best experience, great; but in my case, I have a large library shared among many people who all have a broad assortment of TV's and players. There's no way to structure the media for all of them; rather, it's entirely preferable to store my media in the best state for archival as possible (this would include not butchering them into MP4!), and then lean in on the Emby clients appropriately requesting that the server perform compatible transcoding. The shape of what a compatible stream actually looks like drifts over time with devices; as demonstrated here; LG used to do DTS, and then they didn't, and then they did again, and then they didn't again! They also only play DV from MP4, whereas others will play DV from mkv... maybe the G6 finally support DV in MKV, and/or puts DTS back again? Not butchering our media library knowing that compatibility drifts like the wind should be the very highest priority. In my view, Emby's single most important feature is to take media from the archive, and make it play however the client requires to the best of its ability.

I do perform DV->MP4 conversations, because LG TV's are overwhelmingly popular for people who favour fidelity, so that particular audience do want the best experience for their device which Emby doesn't seem to want to provide. But it tortures my soul every time I ruin the source media; stripping audio codecs and subs that are not MP4/LG compatible, and I can't share/seed it after I butcher it.

It really wouldn't be hard to have the LG client request that the server output MP4 if DV is present, and absolutely essential for P5.

[SamES 1056]

8 hours ago, TurkeyMan said:

t really wouldn't be hard to have the LG client request that the server output MP4 if DV is present

This is on my list to take another look at, but so far I’ve not been able to make it work effectively or reliably. It’s not a straight conversion and while you do it ‘once off’ for a media file, the server needs to do it on the fly and delivered via hls, which can cause different issues like out of memory on LG TV’s. It doesn’t just make an mp4 file. as you are doing.

But I do plan to have another look at this soon. 

[TurkeyMan 17]

8 minutes ago, SamES said:

This is on my list to take another look at, but so far I’ve not been able to make it work effectively or reliably. It’s not a straight conversion and while you do it ‘once off’ for a media file, the server needs to do it on the fly and delivered via hls, which can cause different issues like out of memory on LG TV’s. It doesn’t just make an mp4 file. as you are doing.

But I do plan to have another look at this soon. 

Oh excellent. Thanks for the insight. This out of memory thing is interesting; I have noticed in the last year or 2 that it's not unusual for my TV to crash during playback, like, the screen just goes black and the power light goes off. I turn the TV back on and resume playback from where it crashed and it works just fine from there... have you ever seen this? Is this possibly an out-of-memory thing as you describe? I was mildly surprised to find my G5 does it just as much as my CX.

[TurkeyMan 17]

Here's a crazy thought; maybe add an experiment mode to the client, like right beside stats for nerds add an item which shows a text box pre-populated with the ffmpeg command line in use, and allow the user to edit it and restart the stream with the user edits? Then we can dick around it with and help fine-tune the flags for various devices?

At very least, maybe add the ffmpeg command to the stats-for-nerds text? I'd be interested to know precisely what ffmpeg is doing at any given time. Might help debug or offer better bug reports from time to time.

[SamES 1056]

8 minutes ago, TurkeyMan said:

Here's a crazy thought; maybe add an experiment mode to the client, like right beside stats for nerds add an item which shows a text box pre-populated with the ffmpeg command line in use, and allow the user to edit it and restart the stream with the user edits? Then we can dick around it with and help fine-tune the flags for various devices?

At very least, maybe add the ffmpeg command to the stats-for-nerds text? I'd be interested to know precisely what ffmpeg is doing at any given time. Might help debug or offer better bug reports from time to time.

Have you looked in the ffmpeg logs?  

[SamES 1056]

22 minutes ago, TurkeyMan said:

Oh excellent. Thanks for the insight. This out of memory thing is interesting; I have noticed in the last year or 2 that it's not unusual for my TV to crash during playback, like, the screen just goes black and the power light goes off. I turn the TV back on and resume playback from where it crashed and it works just fine from there... have you ever seen this? Is this possibly an out-of-memory thing as you describe? I was mildly surprised to find my G5 does it just as much as my CX.

Yes I think this is somewhat common on LG TVs. I don’t think LG allow the apps to have much memory allocation. For example, I’ve never seen out of memory on a Samsung TV. During development when testing various things I can consistently cause OOM in many cases on LG, and as features need to work or be disabled across all year models, it’s a fine balance balancing act when adding new features, particularly when we don’t have a quick way to roll back if something is deployed and causes big issues for users. 

[TurkeyMan 17]

Yeah sometimes, but I generally don't get up, walk across the house, and turn on the computer to dig through log files to satisfy a passing curiosity. If you're sitting and watching TV (often with family), you're probably nowhere near a computer.

Maybe you find the logs easy to parse with experience, but they're pretty spammy and takes me some time to find the bit I'm interested in when I'm just casually curious. I would say generally speaking, the sauce isn't worth the squeeze

Just an idea anyway; showing it right there in stats for nerds feels interesting and useful; it's definitely another stat for nerds... it would casually offer users some more insight into how Emby works and increase some awareness of particular problems and how they may manifest.

[TurkeyMan 17]

4 minutes ago, SamES said:

Yes I think this is somewhat common on LG TVs. I don’t think LG allow the apps to have much memory allocation. For example, I’ve never seen out of memory on a Samsung TV. During development when testing various things I can consistently cause OOM in many cases on LG, and as features need to work or be disabled across all year models, it’s a fine balance balancing act when adding new features, particularly when we don’t have a quick way to roll back if something is deployed and causes big issues for users. 

Right, that's really interesting. I reckon we might be able to offer insight for a broader depth of models if we could tweak ffmpeg flags ourselves, like the HLS buffer lengths and what not (I saw there's a mountain of associated flags). Does LG offer any API to report the process memory availability? Can we print process memory stats also in stats-for-nerds?

Edited August 23, 2025 by TurkeyMan

[SamES 1056]

10 minutes ago, TurkeyMan said:

 I would say generally speaking, the sauce isn't worth the squeeze

And for this same reason, it's not worth trying to fit it in Stats for Nerds, besides the fact that it would never fit! The ffmpeg logs aren't too bad, but yes, really only a curiosity for most users.

9 minutes ago, TurkeyMan said:

Does LG offer any API to report the process memory availability?

Nothing particularly useful unfortunately. Their app API's are very minimal.

11 minutes ago, TurkeyMan said:

I reckon we might be able to offer insight for a broader depth of models if we could tweak ffmpeg flags ourselves, like the HLS buffer lengths and what not (I saw there's a mountain of associated flags).

It's temporary (ie: it doesn't persist across restarts) and it's definitely an advanced user option, but if you want to do some tests have you looked at the Diagnostics Plugin?

[TurkeyMan 17]

2 minutes ago, SamES said:

And for this same reason, it's not worth trying to fit it in Stats for Nerds, besides the fact that it would never fit! The ffmpeg logs aren't too bad, but yes, really only a curiosity for most users.

Haha, it's that bad is it? Yeah the logs are fine, but they're distinctly not-on-the-living-room-couch

2 minutes ago, SamES said:

Nothing particularly useful unfortunately. Their app API's are very minimal.

:,(

While I do actually really like the WebOS user experience, it's definitely my biggest complaint about LG's whole thing.

2 minutes ago, SamES said:

It's temporary (ie: it doesn't persist across restarts) and it's definitely an advanced user option, but if you want to do some tests have you looked at the Diagnostics Plugin?

No, I had no idea that was a thing. Interesting; thanks for the tip.

[TurkeyMan 17]

Hey, not to be a nag, but what timeframe might we see the update with the DTS fix be available? I've got guests staying, and basically all blurays are silent rn.