libCEC is effectively a database of TV quirks with hacks around different manufacturer’s implementations.
CEC is a one-wire bus protocol and a standard, but it is implemented individually by every manufacturer and then re-branded so it seems a unique feature to that brand: Anynet, Easylink, Bravia Sync etc. To make matters worse – TVs often get OTA updates that cause regressions.
Don’t install these two packages on your Vero 4K +
We don’t use edid-decode on a Vero 4K/4K+, it’s only needed for Pi.
debootstrap isn’t needed on the system either. It is used at file system generation time, so makes no sense to include it on the target system environment.
No such file or directory: ‘/etc/osmc_build_info’
This just means that your system before August 2021, when this commit was introduced in to the filesystem build scripts:
The lack of the file isn’t a problem. We just include a timestamp for filesystem generation date so we know what the original installation version of OSMC is; as this may be useful in the future.
Since then, I’ve wiped my Vero 4K+ and re-imaged with the latest release image.
My setup is:
Panasonic GZ OLED TV
> Apple TV 4K - TV HDMI1
> Samsung soundbar - TV HDMI2 (ARC)
> OSMC Vero 4K+ - Soundbar HDMI1
Symptoms when CEC goes haywire include:
Apple TV unable to adjust volume via its remote
“Auto via HDMI” no longer listed under Settings > Removes and Devices > Volume Control
Audio coming out of both TV speaker and Samsung soundbar when playing back on Apple TV
Panasonic TV unable to enable ARC
Business as usual for Vero 4K, no playback issues
I’ve been temporarily resolving this issue by:
Shutting down, powering off Vero 4K
Put Apple TV to sleep (TV and soundbar sometimes remain powered on)
Wake Apple TV up using Apple TV remote
Applied this test build above however the issue still manifested about once a day, requiring powering off of the Vero 4K unit to temporarily resolve this issue.
Enabled logging and I was lucky enough to have this replicating within 15 minutes (yay!)… roughly in the order below:
P/s: Could potentially be related, I’ve experienced a similar CEC-related bug when I’ve upgraded the Odroid N2+ from CoreELEC 19.4-Matrix to 19.5-Matrix_rc1, using similar setup as per above, replacing the Vero 4K+ with the Odroid instead.
I’ve been taking this issue seriously, but have had little to go on.
I’ve made some changes to CEC and have sent @nick.rogerson; @cct; @rodhull a USB test image. If anyone else would like to test, do let me know. I’ll wait for their feedback.
If the issue persists, I can only presume it’s due to a spin lock issue and will look further.
Before booting any test image, please turn off all equipment connected on the same CEC bus at the mains. AVRs; Xbox etc for at least two minutes.
I did indeed, and I had different ideas on how to implement a fix. But it will require too much end user testing for now to fix it in the way that I had ideally wanted.
In the near future we should be able to use the upstream CEC kernel driver, so I’d rather get things working as before and put a pin in it.
I’ve been having the same problem as everyone above, I tried the first fix posted, but no luck. For me it seems to happen everytime it goes into standby mode. It locks up my av receiver and ignores cec remote forcing a reboot.
My setup: Vero 4K → HDMI → Samsung Q9FN → audio out via ARC → Sony STR DN-1050.
I had actually noticed that prior to this update if my vero was ever turned off it would lock up the av receiver and hide it from my TV. Unplugging the hdmi cable of the Vero from the TV would resolve this (or just turning it back on), but since the Vero was rarely off this wasn’t much of a issue. Thanks for any help.
Right now it’s a no - but I can’t unplug everything from the wall because the fambo will complain that they’ve lost the internet (shared sockets that is hard to deal with)
Up to now it was all working fine but the loss of cec comms started again.
I’ll isolate everything later, but I think if it was all working then the behaviour should be the same as if I had unplugged everything, right?
My Vero has been up for >24hrs on the latest test build without incident. So, looking good (but the previous build lasted >48hrs before the problem appeared again so…)
Will report back tomorrow (or before then if it goes awry).
OK, so it’s been up for >48 hours without any issue for me. Have watched a few things and also left it idle for v. long periods of time which by now would have shown one of the behaviours with the affected build.
(shared sockets that is hard to deal with)