CEC trouble with a Vero V connected through a soundbar

Help and Support
1

Hi everyone,

First of all, thanks for all the work on OSMC. The Vero V has been great here, and I’m hoping someone can point me in the right direction on a CEC question.

Upfront: I used an AI assistant to help me troubleshoot this and to draft the post. I ran every command myself and reviewed the whole thing before posting, so I can answer follow ups and rerun anything you’d like to see.

My setup is Vero V into HDMI IN 1 of a Samsung HW-Q990F soundbar, and the soundbar into HDMI 3 of a Samsung S90C TV. I run it this way so the Vero can bitstream TrueHD and DTS-HD MA straight to the soundbar. Video and audio work perfectly, so this is only about CEC.

The issue is that pressing Home on the OSMC remote makes the soundbar switch to its TV/eARC input instead of HDMI IN 1, where the Vero actually is.

Looking at the bus, the Vero seems to be announcing something invalid:

echo scan | cec-client -s -d 1

device #0: TV            0.0.0.0   Samsung TV
device #1: Recorder 1    a.0.a.0   CECTester
device #4: Playback 1    2.0.0.0   PlayStation 5
device #5: Audio         3.0.0.0   HW-Q990F
device #8: Playback 2    1.0.0.0   Apple TV

Everything else looks sane, only the Vero ends up at a.0.a.0. Given the topology I’d expect 3.1.0.0. The driver reports the same thing:

$ cat /sys/class/aocec/physical_addr
a0a0

What makes me think this is the whole story: with the mediacenter stopped, if I send Active Source by hand with the value I’d expect, the soundbar switches to HDMI IN 1 every single time, and repeating it doesn’t bounce back to eARC.

echo "tx 4F:82:31:00" | cec-client -s -d 1

So the soundbar handles Active Source fine. It seems to come down to what the Vero is putting in the message.

Things I’ve tried so far:

  1. Setting Physical address in the CEC Adapter peripheral settings to 3100. It shows as 0 again next time I open the screen.
  2. Editing cec_CEC_Adapter.xml by hand with the mediacenter stopped, setting connected_device to 36038, device_type to 36052 and physical_address to 12544. After a restart, device_type stuck but connected_device and physical_address were back to their defaults.
  3. Writing the value to the driver directly. It’s accepted while the mediacenter is stopped, but goes back to a0a0 once Kodi starts.
$ echo 0x3100 | sudo tee /sys/class/aocec/physical_addr
$ cat /sys/class/aocec/physical_addr
3100
  1. New HDMI cable, different soundbar input, full power cycle of everything.

So my questions, in case anyone has been down this road:

  1. Is there a supported way to pin this on a Vero V when the device upstream doesn’t provide a usable value?
  2. Does the AOCEC driver honour the libCEC override at all, or does it always take it from the EDID?
  3. Would writing to the sysfs entry after Kodi has finished starting be a reasonable workaround, or does libCEC keep refreshing that value while it runs?

I’m probably missing something obvious, so any pointers are welcome. Happy to upload a full debug log with the CEC component enabled if that would help.

Thanks!

2

I’m not sure if this is it, but your CEC settings in Kodi should have a setting where you tell it if you have just a TV or a TV and AVR. Is this set to you having both? If the option is missing you can try to reset to defaults in the screen, press OK, and then go back in which might make it show back up.

Also, you might need to restart your Vero after playing with CEC on the terminal. I don’t remember the details but I remember there are some commands run there that break the connection to Kodi till a reboot.

3

Update: I got it working, after messing with AI a bit more.

Two things had to happen, and the order turned out to be what mattered.

The hdmitx EDID parser was reporting the wrong Source Physical Address. Writing to /sys/class/amhdmitx/amhdmitx0/edid returns an I/O error, but it still triggers a reparse, and after that the driver reports the correct value:

$ sudo sh -c ‘echo load /home/osmc/edid_dup.bin > /sys/class/amhdmitx/amhdmitx0/edid’
sh: 1: echo: echo: I/O error
$ cat /sys/class/amhdmitx/amhdmitx0/edid | grep “Source Physical”
Source Physical Address[a.b.c.d]: 3.1.0.0

Then writing the address to the CEC driver sticks:

$ sudo sh -c ‘echo 0x3100 > /sys/class/aocec/physical_addr’
$ cat /sys/class/aocec/physical_addr
3100

The key part is that both of these have to be done with the mediacenter stopped. Doing it while Kodi is running changes the sysfs values but has no effect on behaviour, which makes me think libCEC reads the address once at startup and keeps it in memory. With the mediacenter started afterwards, the value survives and the remote finally behaves: the soundbar switches to the right input and CEC control works.

For background, the EDID my soundbar presents is 384 bytes but byte 126 declares a single extension. The correct SPA sits in the HDMI VSDB at offset 165 with bytes 31 00. The a0 a0 the driver was reporting appears at offset 263, inside the third block, which is past what the EDID declares. Block 2 starts with 02 03 04, meaning no data blocks, so it looks like the parser reads it as one anyway.

1 Like
4

Oh, this is so bizarre. I’m having the exact same problem, and weirdly, with an almost identical setup (exactly the same model TV, but a Q930D Atmos soundbar instead of the Q990F). The only addition is that my Vero is plugged into a four channel HDMI switcher (4K, 120Hz), that also takes feeds from a PS5 and AppleTV.

Whenever I click the ‘Home’ button on Vero to spin things up the soundbar will default to TV/ARC, which continues for around 10-15 seconds, before then it automatically boots up the PS5 and then takes the feed from that. I then have to manually switch channels via the switcher remote control. Eventually the Vero ‘wakes up’ and I can use it as normal.

This isn’t the end of the world, but it is quite a faff having to do this each time rather than the Vero just pinging ‘on’ when I click home on its remote.

Sadly my technical expertise is very limited compared to the OP above. Is there a way of fixing this CEC/handoff issue without bringing in a team of specialists?

Cheers,

Tom