Nothing has changed regarding CEC in this update. As always if you experience a CEC issue I recommend checking if there’s been a firmware update on TV or AVR and leaving things powered down at the mains for a few minutes so everything can reset
Sam
Nothing has changed regarding CEC in this update. As always if you experience a CEC issue I recommend checking if there’s been a firmware update on TV or AVR and leaving things powered down at the mains for a few minutes so everything can reset
Sam
Don’t quite follow. Could you clarify the issue?
Sam
Turning of spashscreen for more verbose boot
Oh, the update is lovely.
My LG OLED EVO C4 is just really cranky when it comes to CEC.
Here in the Netherlands my Vero V still doesn’t update. Did the manual look-up, but no updates available. Is this normal?
No, suggest to upload debug enabled logs so it can be checked
I just wanted to confirm the after the update, and nothing else if I recall correctly, somehow the remote for our LG TV (TV OLED42c24LA) stopped working. The instructions above made it working again. Thanks so much for the information. (@Sam, indeed, I did power the TV and RPI down, but not for several minutes. I’ll try this next time…)
CEC stopped working after updating OSMC (Vero V).
After the update, I had the same issue on my Sony TV.
Luckily, I had made a backup of my settings before. It can be accessed via My OSMC.
What I did:
After the update, I restored my old settings through the OSMC menu — and surprisingly, CEC started working again with May Update.
Nothing has changed with CEC in this update.
I’d suggest powering down everything at the mains for a few minutes. This usually resolves CEC issues.
Sam
First of all, thanks for your good work which is highly appreciated.
After installing the May update, I noticed a change in the behavior of the USB ports: I have a powered USB 3.0 7-port hub connected to vero’s USB 3.0 port. Before the update, I could operate mixed USB 2.0 / USB 3.0 devices on the hub and all worked fine. Now the USB 3.0 port only recognizes USB 3.0 devices.
Funny enough, if I attach the USB 3.0 hub to vero’s USB 2.0 port, it recognizes only USB 2.0 devices.
Has anything happened to mixed xHCI / eHCI operations?
Do you know which version you updated from? A log would help. I can think of a potential change but it happened a while ago
Sam
I updated from OSMC’s November 2025 release.
The behavior is actually more nuanced: For quite some time, I used to detach all USB 3.0 devices on the hub on every reboot of the Vero V. This made the USB 2.0 devices come up successfully, despite them being attached to the USB 3.0 hub on the USB 3.0 port on the Vero V. Then in the live system, I could re-attach the USB 3.0 devices, and they were enumerated successfully on the fly.
However this workaround does not work any more since the May release.
Are you familiar with SSH? I could suggest a small adjustment that may help.
Sam
Yes, just throw it over the fence ![]()
In a recent update I removed a kernel parameter (xhci_hcd.quirks=0x800000) that changes how the USB controller handles memory addressing.
You could edit /boot/cmdline.txt and add
user_bootargs=xhci_hcd.quirks=0x800000
and reboot.
To undo it, just delete that line from /boot/cmdline.txt and reboot.
Cheers
Sam
Unfortunately, it did not work.
The “quirks” parameter appears in /proc/cmdline, but with no change in USB behavior.
A few more details: If I plug a USB 2.0 device into the USB 3.0 port directly (without any hub or adapter), it does not work either. The USB 2.0 device is only recognized in the USB 2.0 port of the Vero V.
dmesg does not show any output related to the plugged-in device.
As a hint: Claude Sonnet 4.6 says the following regarding the kernel build flags of the -93 kernel:
This is the most significant flag for your problem. When enabled, this option makes the EHCI root hub act as its own Transaction Translator (TT), which allows USB 2.0 devices to be connected directly to a USB 2.0 root hub that shares a port with USB 3.0 hardware.
When disabled (as in your config), the TT function must be provided by an external hub’s built-in TT. If the hub’s internal USB 2.0 TT doesn’t enumerate correctly (which is exactly the Amlogic/xHCI race condition described earlier), USB 2.0 devices behind the hub will simply not be recognized. This is very likely a contributing factor to your mixed-device failure.
I have noted the same problem with my Vero-V. Is there a “user_bootargs” that can be added to /boot/cmdline.txt to initialise CONFIG_USB_EHCI_ROOT_HUB_TT ?
No – it’s a compile time option.
I’m still looking in to this and should have something in a bit.
Up until now, restarting the Verso has always worked. Today, however, the problem was very persistent, and I had to unplug the TV and the Verso. It probably has nothing to do with the update, just as you said.
So everything is solved now?
Sam