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.