LibCEC behaviour change between Raspberry Pi and Vero4K

I ran Raspberry Pi 2 model B for a log time with a python script that reads events from CEC (a modified LibCEC Python example) and reacts on them, Kodi worked fine, no issues with that. I switched to Vero4k, but when I run the same script, it now eats most of the key clicks from the remote (over HDMI/CEC) - the Kodi does not get the events and does not want to react on most of them.

The script stops Kodi playing the TV (from tvheadend) when the TV shuts-down and pauses the non-TV playback when the TV switches to a different source.

Please find the Python script and used systemd startup script. The Python script needs the kodipydent module.

Does the Pi run OSMC?
It’s possible you want to change the role Vero 4K advertised itself, but worth confirming what software the Pi is running first

Yes, I have OSMC with latest updates on both - RPi and Vero4k. I just retested this on both the RPi and Vero4k, the problem persists.

See CEC TV Remote stopped working - #6 by Giovanni_Garcea. It will probably help.

Unfortunately that did not work, the TV sends more TV remote keys when on profile Recorder. Using profile Player did not fix anything.

I updated the python script to log debug messages from libCEC and tested it on RPi and Vero4k. Result from running ./ -c | tee cec-watcher.txt 2>&1 on Raspberry Pi (HDMI2 port) and Vero4k (HDMI1 port).

The Vero4k version contains some write failures, so this might influence the CEC handling - Vero4k does not recognise there is another Recorder 1 and re-assigns logical address Recorder 1 instead of using Recorder 2. Also I checked the 4.9 kernel source code and AMLogic CEC looks more in shape (i.e. looks like having some communication fixes) there when compared to the current 3.14.xx version.

I think we have fixed all of the write issues some time ago. We don’t rely on AMLogic’s AOCEC anymore.

Can you send me output of dmesg when you experience failures?

As a test, have you tried stopping Kodi first?


Here is dmesg and dpkg -l output (just to be sure I have correct packages). With stopped Kodi, the result is identical and stand-alone cec-client (no arguments) test shows exactly the same write errors in the console output - path is /dev/aocec, which is kernel. There is nothing regarding write error in dmesg.

Any update? I am still getting write failures on script. As a workaround, I use Raspberry-Pi on another HDMI cable, which controls Kodi on Vero4k… I would like to use Vero4k only.

An occasional write failure shouldn’t be a problem.
The CEC bus doesn’t allow shared access. So you would need to stop Kodi or disable CEC via Kodi to control it using an external script.

As already stated, with stopped Kodi, there are identical write failures. So no, this is not an occasional write failure, but a permanent one.

Just to be sure, I tried it again - run the script as ./ -c and sudo ./ -c:

<< Recorder 1 (1) -> Recorder 1 (1): POLL
<< 11
>> TV (0) -> Broadcast (F): device vendor id (87)
Write: write failed
<< 11
Write: write failed
>> POLL not sent

Ok, I’ll check this in more detail shortly


Raspberry-Pi worked like a charm, so some support for shared client access is at least for RPi driver implemented. What is the status of newer kernel in Vero4k?

The mainline work is coming alone. Perhaps something by end of year.

CEC implementation is the same however, so I will have to do some digging for you



Thanks for your patience.

The output of cec-client looks reasonable – I think a POLL will sometimes fail until the LA is established. If you stop Kodi, and put cec-client in monitoring mode, can you pick up the events you’d like to monitor (TV standby)?

Do you plan to use CEC with Kodi? I ask because currently only one handle is possible on /dev/aocec at a time. I will see if we can adjust this as we did for Vero 1 (2015).

I’ve merged some fixes from AMLogic (SoC vendor) and have prepared a test build.

I’d appreciate it if you could test this and provide feedback before we potentially release this as an update to other users. To test this update:

  1. Login via the command line
  2. Edit the file /etc/apt/sources.list
  3. Add the following line: deb stretch-devel main
  4. Run the following commands to update: sudo apt-get update && sudo apt-get dist-upgrade && reboot
  5. Your system should have have received the update.

Please see if the issue is resolved.

I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.


Yes, definitely, otherwise I will not be able to control Kodi from the TV’s remote control. I will test your changes.

The changes likely won’t reach your mirror for an hour yet.

Thanks for clarifying your requirements. In this case I’d recommend monitoring via XBMC


The improvements seem to cause regressions, from early reports by the development team. I’m not keen on making changes unless we can prove that they do improve things.

I think Kodi gets a callback when TV is standbyed and you could use this directly, instead of a separate daemon.

Alternatively, you could check:

/sys/class/amhdmitx/amhdmitx0/hpd_state or

for changes during standby.

You should be able to get a hint there.


I have no action set on this and according to xbmc/peripherals/devices/PeripheralCecAdapter.cpp, there is no event sent in case nothing is being configured. Additionally I need to react on source switch, so the possibility is to change the method CPeripheralCecAdapter::CecCommand somehow to allow interactions from plugins.

I see there is /sys/class/amhdmitx/amhdmitx0/uevent too - is it usable to monitor events on CEC?

No – but HPD should deassert if your TV standbys.