Status on official LG app

[pastorn 2]

Hmm, seems server logs disappeared. :-/  How to include them here? Email? Personal message?

 

Best regards

Martin

[pastorn 2]

There, finally figured out how to do it. :-)

 

Best regards

/Martin

Emby server log.txt

FFmpg log 1.txt

FFmpg log 2a.txt

FFmpg log 2b.txt

FFmpg log 2c.txt

[Hitsville 37]

Hi,

 

Have now tested more. Used Schindler's list with three audio tracks (english TrueHD, spanish DD, french DD). The behaviour is same as other movies so not file related. Server logs are uploaded and links provided. Hope you can download them...

 

Case 1. Schindler's list, all boxed ticked. Stats for nerds says "transcoding because audio codec not supported". Video is transcoded as well (SDR, poor quality). See FFmpeg log 1.

 

Case 2. Schindler's list, video transcode disabled (other boxes ticked). No playback, "no compatible streams available".

See Ffmpeg log 2a, 2b and 2c

 

Case 3. Schindler's list, video transcode & video conversion disabled (other boxes ticked). No playback and nog FFmpeg log. App says "no compatible streams available".

 

Case 4. Schindler's list, all transcode and conversion disabled. App direct plays (video HDR and looks fine) but chooses last audio track on the list, not the second one (!). No FFmpeg log. Stats for nerds unavailable (!).

 

server       https://file.io/QQ4RMH

1               https://file.io/y8ZHeT

2a             https://file.io/uhi2Ll

2b             https://file.io/Vjxn4u

2c             https://file.io/7GafCR

 

Interesting. As we cross posted, I just tried my HDR copy of Schindlers List.

With the True-HD track selection it direct streams and passes HDR.

With the AC track it direct plays and passes HDR.

[SamES 890]

@@Hitsville, are you running Emby release or beta version?

 

@@pastorn, looks like you're on release.  Can you please confirm if you have hardware acceleration on?  If so, can you please turn it off and try again.

[Hitsville 37]

@@Hitsville, are you running Emby release or beta version?

 

@@pastorn, looks like you're on release.  Can you please confirm if you have hardware acceleration on?  If so, can you please turn it off and try again.

 

I'm on 4.0.3.0 on Windows.

[pastorn 2]

Yo!

 

Pretty sure I've tried this already (turning hw-acc off) but I will confirm tonight. Do you need new logs, same combinations but with hw-acc off? Or just confirmation that it behaves the same?

 

I'm on latest release version of the server for windows. I'm running Windows Server 2012 R2 if that could possibly make a difference… (?).

 

Interesting that it works differently for Hitsville. Hopefully there's an explanation as to why it doesn't work for me. And I agree with him: in all other aspects, Emby rocks! (But the previous version rocked to a higher level at my place.     )

 

I have a (philosophical) question: Is FFMpeg configurable in this application; is there some INI-file or something that can be edited to control how it transcodes audio? I wouldn't mind it if it could transcode TrueHD to some lossless 2.0 format in my case, like 24/48 PCM, as long as it doesn't wreck the video in the process (as it is now). Or is the transcode behaviour locked and controlled by Emby?

 

And do you have any idea why the previous version respected color coded SRT files and the new one doesn't? This was a mega-super-hit feature since brightness for HDR subtitles could be controlled to a comfortable level, even if it wasn't intentional when you made the (previous) app. I hope this feature can be restored…?

 

Best regards

/Martin

[SamES 890]

Yo!

 

Pretty sure I've tried this already (turning hw-acc off) but I will confirm tonight. Do you need new logs, same combinations but with hw-acc off? Or just confirmation that it behaves the same?

 

I'm on latest release version of the server for windows. I'm running Windows Server 2012 R2 if that could possibly make a difference… (?).

 

Interesting that it works differently for Hitsville. Hopefully there's an explanation as to why it doesn't work for me. And I agree with him: in all other aspects, Emby rocks! (But the previous version rocked to a higher level at my place.     )

 

I have a (philosophical) question: Is FFMpeg configurable in this application; is there some INI-file or something that can be edited to control how it transcodes audio? I wouldn't mind it if it could transcode TrueHD to some lossless 2.0 format in my case, like 24/48 PCM, as long as it doesn't wreck the video in the process (as it is now). Or is the transcode behaviour locked and controlled by Emby?

 

And do you have any idea why the previous version respected color coded SRT files and the new one doesn't? This was a mega-super-hit feature since brightness for HDR subtitles could be controlled to a comfortable level, even if it wasn't intentional when you made the (previous) app. I hope this feature can be restored…?

 

Best regards

/Martin

 

 

Yes, if you can do logs that's great.

 

Server OS shouldn't matter for this issue, if they're both Windows based then it should be comparable.  Different OS types (windows vs linux or other) may have been a different concern.

 

It's great that Hitsville is seeing the right behaviour, we just need to understand the differences now.

 

ffmpeg isn't configurable in this case, but the intention is always to minimise the change to the format, so unless required the video should not be being touched.

 

No idea about the subtitles, and as Luke mentioned, that wasn't a feature of the previous version, so it was probably a side-effect of something unintended if it was working that way.  Let's get this issue sorted then we'll see if we can understand why that might have been the case.

[Hitsville 37]

 

Interesting that it works differently for Hitsville. Hopefully there's an explanation as to why it doesn't work for me. And I agree with him: in all other aspects, Emby rocks! (But the previous version rocked to a higher level at my place.     )

 

 

 

It's great that Hitsville is seeing the right behaviour, we just need to understand the differences now.

 

 

 

 

Pastorn I am wondering about the physical files. I only recently switched back to 4K remuxes from 4K encodes. Are yours self rips, encodes or remuxes?

The whole experience with some encodes was less than stellar and often displayed varying odd behaviour. Worse still some encodes would play issue free on certain clients and not on others. I just never figured out a pattern (with regards to the Audio track/Subtitles/client combination) and switched back to the issue free (on all clients) remuxes. 

 

I'm probably not offering anything that helps...but thought it worth throwing out there anyway.

Edited March 26, 2019 by Hitsville

[pastorn 2]

Good morning!
 
Have tried disabling hw-acc and also disabling "throttling", see enclosed logs when both disabled. Behaviour is exactly the same so please see earlier post for the results of each case. Got three logs in case 1 instead of just one, so maybe some clue there? Also got a "hardware detection log" so I'm enclosing that one as well.
 
@Hitsville: I've tried a bunch of different types of files, and the main problem is that this version of the app behaves differently (and not as well) compared to the previous. I've tried numerous movies that played perfectly on the previous app. But thank you for thinking "out of the box"! :-)  Sometimes that's needed to find a solution. If you think of anything else, please let me know.
 
Best regards
Martin

HW detect.txt

Emby server log.txt

FFMpeg log 1a.txt

FFmpeg log 1b.txt

FFmpeg log 1c.txt

FFmpeg log 2a.txt

FFmpeg log 2b.txt

FFmpeg log 2c.txt

[rbjtech 4222]

1a - 

 

Stream mapping:

  Stream #0:0 -> #0:0 (copy)

  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

1b - 

 

  Stream #0:0 -> #0:0 (hevc (native) -> h264 (libx264))

  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

1c -

 

Stream mapping:

  Stream #0:0 -> #0:0 (hevc (native) -> h264 (libx264))

  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

2a -

 

Stream mapping:

  Stream #0:0 -> #0:0 (copy)

  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

2b -

 

Stream mapping:

  Stream #0:0 -> #0:0 (copy)

  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

2c -

 

Stream mapping:

  Stream #0:0 -> #0:0 (copy)

  Stream #0:1 -> #0:1 (truehd (native) -> ac3 (native))

 

So I have highlighted in Green what is expected and in Red what is not optimal.

 

The Emby LG App (and all others from what I've been advised) does not work with Dolby True-HD - and thus Emby transcodes to AC3.  This is for both internal and external sound output.   This is normal and was exactly the same on the previous version of the app.  Note it is always picking the first Audio Steam (1).  Further note - Dolby Atmos only works with EAC3 (Dolby Digital Plus) and only then on the internal speakers... (again, an LG limitation)

 

For all the (copy) video streams, you should be getting HDR if it's encoded, as Emby is simply copying the video stream directly into LG's player factory player.

 

If it's transcoding into h264 (as in the case for 1b & 1c) then you will be losing HDR.  What is the difference with 1b and 1c ? Subs ?  If yes, then you MUST use .SRT (external) subs as anything else will transcode, regardless of whether it is compatible or not.

Edited March 27, 2019 by rbjtech

[pastorn 2]

@rbjtech: Thank you for your reply!

 

Case 1: Three logs. Not sure why. Could first log (video copy) be failed attempt, rejected by the app? Second log is playing (beginning of movie) and third is where I have forwarded the movie to see what language the dialogue is in? There was no playback in HDR here, only transcoded video. So 1a (video copy) never played.

Case 2: None of these played, the app reported "no compatible streams available".

 

The above means that I can not use transcode mode at all, I have to force direct play. When doing so (un-ticking the boxes in transcode options) I get perfect video (4K/HDR) but I get the last audio track in the list which can be anything from commentary track to thai dialogue. I can switch to another track but when I choose TrueHD it again switches to the last audio track. This should not be case, I believe (?). Another weird thing is that when forcing direct play "stats for nerds" is unavailable which is unpracticle for diagnostics and should also not be the case, I suppose…?

 

My LG Oled is configured to put out optical audio in LPCM which I believe is the same situation for audio decoding as playing via the internal speakers? So I am not looking for putting out Atmos/TrueHD bitstreamed, I just want the TrueHD track to be decoded in the TV and sent out in a lossless format to my stereo. I believe this was the case with the previous version of the Emby LG app. But I can not revert to it...

 

 

PS: I had no subs activated in any of these cases. And I am aware that only external SRT subtitles work. This has been tried also now and does not affect the behaviour so I think this is unrelated to subs.  DS

[rbjtech 4222]

What LG TV is this being tested on - model number ?

 

I've tested this on an LG C8 OLED - and don't have these issues at all.

Edited March 27, 2019 by rbjtech

[pastorn 2]

The B6!

 

Wish I had another SmartTV to test on to know if it’s the client or the server side of it, but no such luck. But didn’t have any problem with previous version of the app...

 

/Martin

[rbjtech 4222]

Also just read your point about the sub colour - and whilst I can't confirm that colour used to work on the old version (as I never used it) - it does not work on my TV either - but italics and underline do ..

 

1

00:03:25,247 --> 00:03:27,124

normal:Look who we have here. Works fine

 

2

00:03:32,296 --> 00:03:33,923

<b>bold:You have our money?</b>      May work, but as it's so bright anyway (HDR) I'm not sure it's any more bold than a normal sub  .. 

 

3

00:03:38,469 --> 00:03:39,470

<i>italic:Search him.</i>   Works fine

 

4

00:03:41,060 --> 00:03:43,395

<u>underline:Not if I shoot you.</u> Works fine

 

5

00:03:45,998 --> 00:03:50,458

<font color="#808080">colour:Coaxium is precious.</font> Doesn't work - just retina burning white ... 

 

Lets hope this can be restored - as I agree with you subs are FAR too bright - I've never tested as I've never had any HDR movies using SRT subtitles .. 

[rbjtech 4222]

 

My LG Oled is configured to put out optical audio in LPCM which I believe is the same situation for audio decoding as playing via the internal speakers? So I am not looking for putting out Atmos/TrueHD bitstreamed, I just want the TrueHD track to be decoded in the TV and sent out in a lossless format to my stereo. I believe this was the case with the previous version of the Emby LG app. But I can not revert to it...

 

I don't believe this is the case - I've just set mine to Optical - PCM (instead of Auto) and it still converts to AC3 but now only sends a 2.0 channel stereo to my AVR (Dolby Pro Logic), which I believe is the correct behaviour.  'Auto' sends the full Dolby Digital 5.1 bitstream as reported by my AVR.   But both convert from True-HD to AC3 fine without any video conversion or HDR loss.

Edited March 27, 2019 by rbjtech

[pastorn 2]

@rbjtech:  Nice work in investigating subtitle support! :-)  Maybe this should be documented somewhere? I consistently used #808080 (half brightness) for HDR movies in the previous movies of the app, mainly to avoid having a single line of subtitles light up the entire room in a dark scene, ruining the viewers night vision...   Do you still see settings for subtitle size? I am not 100% sure about this but I think there was a setting (like 5 options?) in the previous version of the app but now I don't see it anymore...?

 

For SDR movies I felt full brightness for the subtitles was okay since the color settings in the TV is normally different. This could obviously depend on your color settings in the TV, though. If you're running SDR movies with some "HDR effect mode" perhaps the problem is the same (?).

 

The alternative would obviously be if one could choose between a few different colors in the Emby App but then there would have to be two settings; one for SDR and one for HDR. Perhaps too complicated... The previous support for color coded SRT files was a completely satisfactory solution (at least to me) since the files are unique for each movie and tweaking them with color took like 10s with a proper editor.

 

Could you try (if you have the time) un-ticking the transcode boxes on the server (forcing direct play), try a movie with TrueHD track as default and see if you also get the last audio track instead of the second one, and "stats for nerds" disappear?

 

Have a good day!

 

Best regards

Martin

[rbjtech 4222]

@rbjtech:  Nice work in investigating subtitle support! :-)  Maybe this should be documented somewhere? I consistently used #808080 (half brightness) for HDR movies in the previous movies of the app, mainly to avoid having a single line of subtitles light up the entire room in a dark scene, ruining the viewers night vision...   Do you still see settings for subtitle size? I am not 100% sure about this but I think there was a setting (like 5 options?) in the previous version of the app but now I don't see it anymore...?

 

Could you try (if you have the time) un-ticking the transcode boxes on the server (forcing direct play), try a movie with TrueHD track as default and see if you also get the last audio track instead of the second one, and "stats for nerds" disappear?

 

Have a good day!

 

Best regards

Martin

 

The only other official .SRT formatting is screen location (co-ordinates) - I don't see anything else about size. https://en.wikipedia.org/wiki/SubRip

 

I removed the transcode option from the user - and my testing also confirms what you get - it it (unreliably) plays the last track and stats for nerds disappears ..

 

In my case - my file has 1:h265 2:TrueHD 3: AC3 and 4:DTS

 

On the first attempt, I could see my AVR flash on and off the DTS indicator for a few seconds, but fail to produce any sound.  Video did not play.

On the second attempt, the AVR switched to DTS and played the Audio and Video fine.  But no stats for nerds to confirm but AVR indicator shows it's playing the last DTS track.

On the third attempt, I could see my AVR flash on and off the DTS indicator, but fail to produce any sound.  Video did not play.

On the fourth attempt, the AVR switched to DTS and played the Audio and Video fine.  

 

So it's consistent - but wrong as it probably should be picking the next track (AC3 in my case) 

 

But to be clear, all this only happens when I force remove transcoding, normally it just converts True-HD to AC3 on the fly (even though there is a perfectly good AC3 or DTS stream there that 'could' have been used)

 

I hope that helps you and the Dev's understand this a little better and hopefully track down the bug.

Edited March 28, 2019 by rbjtech

[rbjtech 4222]

To add,  it looks like LG have just released a new firmware (20/03/2019) which may change the 'Dolby Atmos' support - will have a play later but unfortunately I don't have an Atmos AVR... 

 

SW File (Version 04.10.31) Detailed applicable model list : Please check with reference Tab exactly

d applicable model list : Please check with reference Tab exactly

* SW information  

1. Improvement  
 1) Improved issue of external AV Receiver "Not Supported" error when playing Dolby Atmos content.   
 2) To improve issue of Macro Block Noise. 

 

Edit - updated via USB, well good news is Emby is still working as it was before so the update hasn't broken anything (which is a relief) but need somebody with an Atmos AVR to determine what improvements they made and if Emby can make use of them.

 

Edited March 28, 2019 by rbjtech

[yuny14utv 0]

This might be awesome news? Can anyone test Dolby Atmos with external sound with the latest firmware?

[kwilcox 78]

what version of WebOS are you running @@rbjtech?

[rbjtech 4222]

what version of WebOS are you running @@rbjtech?

 

Hi @@kwilcox - WebOS v 4.1.0-561101 (goldilocks-glacier)

[pastorn 2]

I got an answer from Luke on the Samsung Forum. I am posting his reply here (and mine) since it's LG related. I hope nobody minds..

 

We were previously rendering SRT subtitles using our own custom rendering, and it might have accidentally supported this, however in the latest release we switched back to having the LG video player render them.

 

So now it's a question of whether it supports this or not, and it looks like it probably does not. And no, we can't switch back to the custom rendering because that has it's own problems, it is really only a last resort when the built-in LG rendering doesn't work. And it turns out the custom rendering is only needed for WebOS 1.X and 2.X.

 

Thank you so much for explaining this; that makes sense if you have switched from your own rendering to LG official. I can not argue against your decision since it is not my app and i am not a developer. I can only stress that it is an unfortunate consequence if this means it is impossible to reduce the brightness of the subs, now and forever. :-(   The visual aspect of subtitles can really have a big impact on the experience of a movie, and getting blinded by a single line of white subtitles in a dark scene has become a menace with the introduction of HDR movies and big TV screens. It litterally lights up the room (!). This was easily avoided in the previous version of your outstanding Emby app using color coded SRT files.

 

If you look at competing software such as Kodi for example, there are a lot of different subtitle options to improve the viewing experience. I can not agree to the idea that an app installed on a device should have to be limited by the shortcomings of the original device; if anything, an app should try and overcome the limitations of the device to offer additional features and improved experiences.

 

The DLNA player on my LG TV has the options to select four different subtitle colors. I believe they are white, red, blue and green (pretty useless options). So the official LG subtitle rendering engine CAN show other colors than white and I would be surprised if this was hardcoded in the rendering engine (?). More likely, it is a limitation of the DLNA player, and the color can probably be freely chosen if only one figures out how the DLNA player specifies the color to the rendering engine. Could this be a way forward? If so, an option could perhaps be introduced in the Emby app instead? It would have to be one color for SDR and another one for HDR since the requirements are different.

 

I would happily participate in some kind of beta testing if you want? I Think there is a guide to be found on how to put an LG TV in "developer mode", which makes it possible to install apps from other sources than the app store. Just let me know if I can be of assistance in any way.

[pastorn 2]

@rbjtech: Thank you for trying and replicate the behaviour I experienced when forcing direct play! At least now I know I'm not crazy.  

[KevinSartori 8]

FWIW, the XPlay app for LG (using Plex) has different color options.  At one point, the creator of the app added a "Silver" color subtitle option to resolve this exact HDR issue.  With XPlay, the subs are also being rendered by LG, so this should be possible as a feature add in Emby.

 

Is there a formal "feature request" process?

[rbjtech 4222]

I got an answer from Luke on the Samsung Forum. I am posting his reply here (and mine) since it's LG related. I hope nobody minds..

 

 

Thank you so much for explaining this; that makes sense if you have switched from your own rendering to LG official. I can not argue against your decision since it is not my app and i am not a developer. I can only stress that it is an unfortunate consequence if this means it is impossible to reduce the brightness of the subs, now and forever. :-(   The visual aspect of subtitles can really have a big impact on the experience of a movie, and getting blinded by a single line of white subtitles in a dark scene has become a menace with the introduction of HDR movies and big TV screens. It litterally lights up the room (!). This was easily avoided in the previous version of your outstanding Emby app using color coded SRT files.

 

If you look at competing software such as Kodi for example, there are a lot of different subtitle options to improve the viewing experience. I can not agree to the idea that an app installed on a device should have to be limited by the shortcomings of the original device; if anything, an app should try and overcome the limitations of the device to offer additional features and improved experiences.

 

The DLNA player on my LG TV has the options to select four different subtitle colors. I believe they are white, red, blue and green (pretty useless options). So the official LG subtitle rendering engine CAN show other colors than white and I would be surprised if this was hardcoded in the rendering engine (?). More likely, it is a limitation of the DLNA player, and the color can probably be freely chosen if only one figures out how the DLNA player specifies the color to the rendering engine. Could this be a way forward? If so, an option could perhaps be introduced in the Emby app instead? It would have to be one color for SDR and another one for HDR since the requirements are different.

 

I would happily participate in some kind of beta testing if you want? I Think there is a guide to be found on how to put an LG TV in "developer mode", which makes it possible to install apps from other sources than the app store. Just let me know if I can be of assistance in any way.

 

The other thing I noticed when testing, during the Emby information 'overlay transparency' the bright HDR subs were also heavily dimmed.  So while far from ideal, Emby obviously has 'control' over the screen - so maybe something could be done here to just dim the portions of the screen that uses the subtitles.  I'm going to see if .SRT 'co-ordinates' work - and if so, Emby will know exactly where to dim (and for how long).