I’ll check this tomorrow.
Have run into this problem twice in the past few months now. First time the remote randomly starting working again but now it’s down again. Same issue as well with one USB port working for anything and the other being spotty. LG remote paired to it so I can still use it, an old remote with a dongle can be used as long as it’s in the working port.
Vero V OSMC remote stopped working after a power outage. I checked everything discussed alas it still not working. Installed the RF dongle of an old OSMC remote in External USB 2: it worked perfectly after power on. I opened the Vero V and try this working dongle instead of the original one: not working. So I took out the original Vero V dongle, inserted it in the External USB 2: it worked perfectly. In my opinion, this point to a faulty internal USB port. By the way, the external USB 3 port work correctly with any USB key, as is the Micro-SD card port and the optical (SPDIF) audio output.
Latest news: original Vero V remote stopped working on External USB 2 !!! I put back in my old one on External USB 2 because this one works. Tomorrow, I’ll retry it on the internal USB and keep you posted. I will also test the original Vero V remote on another OSMC installation.
Hello!
I’ve ran into a similar problem to what is described by others here.
About a week ago, I’ve received a pop-up notification in the Kodi interface, offering to install an update. I agreed (using the remote control) and the update installed, rebooting the system in the process. The system now reports osmc version 2026.05-1 (kernel: Linux 4.9.269-93-osmc). However, once the system booted up again and Kodi started, the remote no longer worked.
When I clicked buttons, the blue LED would light up. Just to be sure, I tried to put in a new battery (checked to be above 3.0V), but still nothing. Pairing (with home+OK) also doesn’t help - the LED light just stays solid blue.
I SSHed in and tried to run lsusb and was surprised to not see the adapter listed:
$ sudo lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Any advice on how to proceed here?
I contacted the support (support@osmc.tv) a week ago (on May 8th), but haven’t heard anything back yet.
The Vero V remote has also stopped working for me after the May 2026 update.
Similar to the previous poster, when the notification appeared that there was an update available, I clicked on OK (using the Vero V remote). After the update had installed and the Vero V had rebooted, the Vero V remote no longer works.
I have unplugged the Vero V and powered it back on a few times, to no success. The blue LED flickers when I press the buttons, and if I hold Home + OK for a few seconds the LED stays on.
I don’t have anything else plugged into the Vero V - it is running as stock (I just use it to play files off a network drive).
Is there anything else I can try to get the remote working again?
If there are some instructions on how I can revert back to a previous version of the software before the May 2026 update, I can try that.
Thanks, James
As an update:
I’ve opened up the Vero V, unplugged the USB receiver, and plugged it into the USB 2.0 port (accessible from the outside). The remote now works again. So the issue was indeed limited to the inner USB port.
$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2017:1690 OSMC Remote Controller OSMC Remote Controller
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Fingers crossed that the remote keeps working now! (Unlike what MG880 posted before…)
James, can you run this for me?
sudo dmesg | grep -iE ‘usb|xhci|hub|2-1|1-1’
cat /sys/class/net/eth0/address
Hi Sam,
I tried this (logged in via SSH) and got no output.
osmc@vero:~$ sudo dmesg | grep -iE 'usb|xhci|hub|2-1|1-1'
> cat /sys/class/net/eth0/address
>
I tried pairing the remote again, but no change.
My TV remote is working OK, and I was able to remap the buttons I needed in the keymap editor, which is fine.
Thanks, James
Hi @Jimbo1, try the cmds Sam posted line by line:
osmc@osmc-verov:~$ sudo dmesg | grep -iE 'usb|xhci|hub|2-1|1-1'
...
osmc@osmc-verov:~$ cat /sys/class/net/eth0/address
...
If strange things happen, don’t use cut’n paste but type in manually.
Thanks Jim,
I typed out the commands instead of copy/paste, and I did get some output this time:
osmc@vero:~$ sudo dmesg | grep -iE 'usb|xhci|hub|2-1|1-1'
osmc@vero:~$ cat /sys/class/net/eth0/address
94:cc:04:60:03:92
osmc@vero:~$
I tried pairing the OSMC remote again with OK + Home, both before and after a reboot. The blue LED on the remote stayed lit for a few seconds, but didn’t start working.
James
Can you try reboot and upload the output of the dmesg command again?
Hi Sam, I rebooted and tried the commands again. I got some output this time:
osmc@vero:~$ sudo dmesg | grep -iE 'usb|xhci|hub|2-1|1-1'
[ 0.724807] usbcore: registered new interface driver usbfs
[ 0.724851] usbcore: registered new interface driver hub
[ 0.724889] usbcore: registered new device driver usb
[ 1.198592] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.198638] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 1.199024] usbcore: registered new interface driver cdc_acm
[ 1.199027] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[ 1.199074] usbcore: registered new interface driver usb-storage
[ 1.199149] usbcore: registered new interface driver usbserial
[ 1.199172] usbcore: registered new interface driver usbserial_generic
[ 1.199188] usbserial: USB Serial support registered for generic
[ 1.199661] usbcore: registered new interface driver uvcvideo
[ 1.199663] USB Video Class driver (1.1.1)
[ 1.200326] usbcore: registered new interface driver btusb
[ 1.202259] usbcore: registered new interface driver usbhid
[ 1.202262] usbhid: USB HID core driver
[ 1.239222] amlogic-new-usb2-v2 fe03a000.usb2phy: USB2 phy probe:phy_mem:0xfe03a000, iomap phy_base:0xffffff80081dd000
[ 1.239474] amlogic-new-usb3-v2 fe03a080.usb3phy: USB3 phy probe:phy_mem:0xfe03a080, iomap phy_base:0xffffff80081fe080
[ 1.768060] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 1.768074] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 1
[ 1.768399] xhci-hcd xhci-hcd.0.auto: hcc params 0x0228fe6c hci version 0x110 quirks 0x20010010
[ 1.768433] xhci-hcd xhci-hcd.0.auto: irq 17, io mem 0xfde00000
[ 1.768609] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 1.768614] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.768617] usb usb1: Product: xHCI Host Controller
[ 1.768620] usb usb1: Manufacturer: Linux 4.9.269-93-osmc xhci-hcd
[ 1.768622] usb usb1: SerialNumber: xhci-hcd.0.auto
[ 1.769039] hub 1-0:1.0: USB hub found
[ 1.769073] hub 1-0:1.0: 2 ports detected
[ 1.770347] xhci-hcd xhci-hcd.0.auto: xHCI Host Controller
[ 1.770358] xhci-hcd xhci-hcd.0.auto: new USB bus registered, assigned bus number 2
[ 1.770442] usb usb2: We don't know the algorithms for LPM for this host, disabling LPM.
[ 1.770563] usb usb2: New USB device found, idVendor=1d6b, idProduct=0003
[ 1.770576] usb usb2: New USB device strings: Mfr=3, Product=2, SerialNumber=1
[ 1.770580] usb usb2: Product: xHCI Host Controller
[ 1.770582] usb usb2: Manufacturer: Linux 4.9.269-93-osmc xhci-hcd
[ 1.770585] usb usb2: SerialNumber: xhci-hcd.0.auto
[ 1.771043] hub 2-0:1.0: USB hub found
[ 1.771065] hub 2-0:1.0: 1 port detected
[ 1.773550] dwc_otg: usb0: type: 2 speed: 0, config: 0, dma: 0, id: 0, phy: fe03a000, ctrl: 0
[ 1.773554] dwc_otg_driver_probe host only, not probe usb_otg!!!
osmc@vero:~$ cat /sys/class/net/eth0/address
94:cc:04:60:03:92
osmc@vero:~$
Not sure if that helps or not. It didn’t fix the OSMC remote (I tried pairing it again before and after a reboot).
James
Unfortunately it’s not expected to resolve any issue but to give me more insight in to the issue.
Sam
We’ve now pinned down what’s behind the small number of USB reports on Vero V in this thread (and a couple of related ones), and I want to explain it properly because it ties
several symptoms together.
The tell. If a USB 2.0 stick works in the standalone USB 2.0 port but won’t work in the USB 3.0 port — while USB 3.0 drives still work in that USB 3.0 port — then there’s a very good chance your internal USB port has also stopped working. On Vero V the OSMC remote receiver lives on that internal port, so your remote will most likely have stopped working too (unless you’re using a TV/CEC or another remote). Several of you reported exactly that pairing of symptoms, and that’s the clue that ties it all together.
So, a question for those affected: did your remote stop working at around the same time? That would confirm what we’re seeing.
Why it happens. There’s a small USB 2.0 hub chip on the Vero V board, and the board is wired like this:
- the internal port (remote receiver) and the USB 2.0 data lines of the USB 3.0 port both run through that hub;
- the standalone USB 2.0 port and the USB 3.0 SuperSpeed lines run straight to the processor and never touch the hub.
On a small number of units, that hub chip can fail. When it does, everything behind it disappears at once — the internal port (so the remote stops) and USB 2.0 devices in the USB 3.0 port. Anything wired directly to the processor keeps working, which is why your standalone USB 2.0 port is fine, and why a USB 3.0 (SuperSpeed) drive still works in the USB 3.0 port while an older USB 2.0 stick in the same socket does not — SuperSpeed bypasses the hub; only the older USB 2.0 signalling needs it.
You can confirm it yourself. On a healthy Vero V, lsusb over SSH shows a line like:
Bus 001 Device 00x: ID 1a40:0801 Terminus Technology Inc. USB 2.0 Hub
On an affected unit that line is simply gone — the hub isn’t on the bus at all. We’ve also checked the kernel boot logs: the processor, the USB controllers and both root hubs all come up perfectly; the hub chip just never appears.
A few honest points:
- This is a hardware fault and it cannot be fixed by software. The hub chip isn’t responding on the bus at all, so there’s nothing the OS can do about it.
- It is not caused by an update. We’ve verified there were no USB-related changes in our software, and we see this on both older and newer OSMC versions. It can appear right after
an update only because installing one reboots the device — and a hub that has begun to fail often doesn’t come back after a power cycle. The update is when you notice it, not the
cause. - It’s rare. This affects a small number of units; the large majority are completely unaffected.
Vero V — USB port routing (simplified)
+-----------+
| |--- USB 2.0 (direct) -------------------> [ external USB 2.0 ] OK (survives)
| S905X4 |
| (SoC) |--- USB 3.0 SuperSpeed (direct) --------> [ USB 3.0 port: SS ] OK (survives)
| |
| | +-----------+
| |--- USB 2.0 ---------> | USB 2.0 |----> [ USB 3.0 port: USB2 ] FAILS
| | | HUB |
+-----------+ | |----> [ internal port ] FAILS
+-----------+ (remote receiver)
If the hub chip fails, everything on its branch drops off the bus:
the internal port (remote) and USB 2.0 devices in the USB 3.0 port.
Anything wired directly to the SoC keeps working.
If you think you’re affected, please email support@osmc.tv (mention this thread) and we’ll take a look and go from there.
4 Likes
Thanks for the info, Sam!
My situation appears consistent with this. I haven’t tested the USB 2.0 device in the USB 3.0 port, but I can if needed – let me know if you’d need another data point.
For me, this started with the installation of the May update (around the first weekend in May). That fact that several other posts reported this exact time point as the start of the issue leaves me suspicious that it’s not just a coincidence. At least in my case, I reboot the device semi-regularly, so I’m not convinced it was all triggered by just the reboot… Is there perhaps any way we could test this?
Either way, now that I’ve moved the remote receiver to the outer USB 2.0 port, everything works fine and I’m happy to just continue using the device this way. I never connect anything to those outside USB ports, anyway.
Valentyn
Thanks also for the detailed explanation.
Unfortunate that it is a hardware fault, but at least it’s good to know for developing any future Vero devices.
James
It’s not related to the update. You’re welcome to install a previous version of OSMC to verify it yourself. I have explained above why it can’t be caused by an update