Ugoos AM6b+ Dolby Vision not working when Soundbar (eARC) plugged into TV

Hi all - facing a really challening one here, and I’m not really an AV expert so really struggling with this one, goes quite deep. This is on a new Ugoos AM6b+ as I was aiming for complete Dolby Vision support.

Here’s where I’ve got to:

  • Dolby Vision does not work when the soundbar (Sonos Beam Gen 2) is connected to the eARC port of my TV (TCL 65C645) but does work when I remove it.
  • When I insert and remove the soundbar from the TV I can see CoreELEC change display modes.
  • My setup works on the Android partition; that is the Dolby Vision output (tv switches mode) and the audio via the soundbar so there does appear to be a way to resolve this in software - at a minimum Android is handling this.
  • Based on some snippets in this forum I’ve got the hint that something strange is happening with the EDID provided to the Ugoos AM6b+ when the soundbar is plugged in; possibly that the soundbar ‘doesn’t support’ Dolby Vision. This is corroborated because when the soundbar is plugged in I only get limited display resolutions. I believe the soundbar is overriding the valid EDID modes of the TV.

Does anyone with more knowledge know what I can do here. I can provide more logs if needed - I’ve zoomed in to what I think is relevant here:

Without HDMI eARC Soundbar:

CoreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/dv_cap

DolbyVision RX support list:
VSVDB Version: V2
2160p60hz: 1
Support mode:
IEEEOUI: 0x00d046
EMP: 1
VSVDB: eb0146d0004d1a968c4a6785
CoreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/rawedid


Soundbar Connected:

CoreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/dv_cap

The Rx don't support DolbyVision
CoreELEC:~ # cat /sys/class/amhdmitx/amhdmitx0/rawedid

Full log:

  1. System boot up as normal (Soundbar connected)
  2. Disconnected soundbar after CoreELEC fully loaded.
  3. Upload log straight after (no other actions).


Does anyone know how to resolve this? Hopefully not facing a dead-end :crossed_fingers:

Looks for me a issue on the EDID decoder.
When I test it online by EDID Decode I get:

  Vendor-Specific Video Data Block (Dolby), OUI 00-D0-46:
    Version: 2 (12 bytes)
    Supports YUV422 12 bit
    DM Version: 5.x
    Backlt Min Luma: 75 cd/m^2
    Interface: Standard + Low-Latency
    Supports 10b 12b 444: Not supported
    Target Min PQ v2: 60 (0.00478965 cd/m^2)
    Target Max PQ v2: 3225 (1450 cd/m^2)
    Unique Rx, Ry: 0.67187500, 0.31250000
    Unique Gx, Gy: 0.27343750, 0.64453125
    Unique Bx, By: 0.15234375, 0.05078125

When I find time I will take a look into it…

Slightly off topic, but this appears to be the first example of a system that can use the hdmi 2.1 dynamic metadata specification with extended metadata packets for tv-led DV.

From a development perspective this is an pretty interesting mode that sends in DV metadata in the same fashion as hdr10+. May actually be a fairly “straightforward” (-ish) bit of work to get this mode running from a device without a DV licence as this mode appears to avoid all the difficulties with embedding metadata into pixel values

1 Like

It should be fixed with tomorrow nightly 20240606 but I can’t promise all do work as expected. On newer kernel all this EDID functions are completely reworked and do not have such issues anymore with this EDID. Only Amlogic-ng is affected.

Amazing response here Portisch, and much appreciated that you picked this one up so soon. Glad in all honesty that it wasn’t some hardware fault with the combination of devices I’m using. Will keep an eye on the nightlies and report back!

To be honest, on a qualified report you get a qualified response…


Reporting back that this has solved it, no issues found so far - all buttery smooth. Thanks again!