Which issue of the two? Tuners dropping out occasionally or the device freezing with 251220.005308 (only)? I’ll keep you posted about the former but even that would be kind of weird since (see above) those correlate rather strongly with my migration to the Vero V, after using the same tuners and the powered hub for years without significant problems. Sure, things can age but that would be too much of a coincidence.
He’s also using the latest driver
I don’t argue that the latest driver is universally broken. The root cause is likely a combination of the driver and OSMC’s kernel, OS (userspace) and potentially even TVH. I’m fully aware that you need to reproduce the issue in order to help but as long as the previous driver works well enough, I can’t take my production device out of service again. It’s a real PITA to always set it up from scratch to a large degree (takes hours).
Thanks
Which kernel version is this system running?
There was a generic USB Controller driver issue around Linux 6.8.10, mainly related to device disconnect handling which was able to trigger a full system lockup. USB-level problems can have multiple root causes once a disconnect or reset is involved.
A USB disconnect (or reset/freeze that looks similar from userspace) can be triggered by various factors, for example:
-
Insufficient or unstable power delivery
-
USB cable quality or marginal signal integrity
-
USB hubs with poor impedance matching or timing behavior
-
Host controller behavior on the new platform (Vero V)
-
Defective or marginal host or USB hardware
So even if the same tuners and powered hub worked fine for years on a different system, a platform migration can expose borderline conditions that were previously hidden.
I fully understand that repeatedly rebuilding a production setup is a real pain. However, diagnosing a one-off issue without being able to observe the system is extremely difficult. To use an analogy: if you drive a car to a repair shop, you’d also expect the technician to have access to the car — not to guide you remotely through a long list of possible issues.
That’s why I suggested remote access — not as a requirement, but as the most efficient way to look at logs, kernel state, and USB behavior without both sides spending significant time on blind troubleshooting. Without reproducibility or access, it’s unfortunately not economical to chase every possible interaction between kernel, userspace, and hardware.
If you can share the kernel version and any relevant USB or kernel logs, that would already help narrow things down.
No analogies needed, I’m (literally) a pro myself. 
There was a generic USB Controller driver issue around Linux 6.8.10
Please note that the Vero V uses 4.9.269-87-osmc (aarch64) and is otherwise still based on Debian “bulleye” (armhf/armsysvhf), running TVH 4.2.8. How far back does that upstream USB issue go? Any backport to 4.9 needed?
If you can share […] any relevant USB or kernel logs, that would already help narrow things down.
Will do as soon as the original issue resurfaces. So far it hasn’t… 
Cheers
Ok, it happened again, THV couldn’t find any available adapters anymore. At that point adapter #0 still was marked green but the THV log showed linuxdvb: Sundtek DVB-S/S2 (VIII) #0 : DVB-S #0 - DTV_CLEAR failed [e=Permission denied] indicating the device nodes being inaccessible (despite permissions being in fact correct). In contrast, adapter #1 was marked red and its device nodes were gone entirely.
Looking at dmesg one can clearly see that the USB hub (device number 24) and the two tuners attached to it got disconnected and subsequently reconnected:
[Thu Jan 8 00:15:46 2026] usb 1-2: USB disconnect, device number 24
[Thu Jan 8 00:15:46 2026] usb 1-2.2: USB disconnect, device number 25
[Thu Jan 8 00:15:46 2026] usb 1-2.4: USB disconnect, device number 26
[Thu Jan 8 00:15:46 2026] usb 1-2: new high-speed USB device number 27 using xhci-hcd
[Thu Jan 8 00:15:46 2026] usb 1-2: New USB device found, idVendor=05e3, idProduct=0608
[Thu Jan 8 00:15:46 2026] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Thu Jan 8 00:15:46 2026] usb 1-2: Product: USB2.0 Hub
[Thu Jan 8 00:15:46 2026] usb 1-2.2: new high-speed USB device number 28 using xhci-hcd
[Thu Jan 8 00:15:47 2026] usb 1-2: USB disconnect, device number 27
[Thu Jan 8 00:15:47 2026] usb 1-2.2: device descriptor read/all, error -71
[Thu Jan 8 00:15:47 2026] usb 1-2-port2: attempt power cycle
[Thu Jan 8 00:15:47 2026] usb 1-2.2: the parent's name is 1-2
[Thu Jan 8 00:15:47 2026] usb 1-2-port2: Device no response
[Thu Jan 8 00:15:47 2026] usb 1-2: new high-speed USB device number 32 using xhci-hcd
[Thu Jan 8 00:15:47 2026] usb 1-2: New USB device found, idVendor=05e3, idProduct=0608
[Thu Jan 8 00:15:47 2026] usb 1-2: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[Thu Jan 8 00:15:47 2026] usb 1-2: Product: USB2.0 Hub
[Thu Jan 8 00:15:48 2026] usb 1-2.2: new high-speed USB device number 33 using xhci-hcd
[Thu Jan 8 00:15:48 2026] usb 1-2.2: New USB device found, idVendor=2659, idProduct=1805
[Thu Jan 8 00:15:48 2026] usb 1-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Thu Jan 8 00:15:48 2026] usb 1-2.2: Product: eLight
[Thu Jan 8 00:15:48 2026] usb 1-2.2: Manufacturer: Sundtek
[Thu Jan 8 00:15:48 2026] usb 1-2.2: SerialNumber: 1234
[Thu Jan 8 00:15:48 2026] usb 1-2.2: Unsupported device
[Thu Jan 8 00:15:48 2026] usb 1-2.4: new high-speed USB device number 34 using xhci-hcd
[Thu Jan 8 00:15:48 2026] usb 1-2.4: New USB device found, idVendor=2659, idProduct=1805
[Thu Jan 8 00:15:48 2026] usb 1-2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Thu Jan 8 00:15:48 2026] usb 1-2.4: Product: eLight
[Thu Jan 8 00:15:48 2026] usb 1-2.4: Manufacturer: Sundtek
[Thu Jan 8 00:15:48 2026] usb 1-2.4: SerialNumber: 5678
[Thu Jan 8 00:15:48 2026] usb 1-2.4: Unsupported device
Yes, this does indicate an issue with the USB hub and I am going to try a different one with a current of at least 1A per port.
However, I’m wondering if the driver shouldn’t be able to handle reconnects more gracefully. I had to restart the sundtek service (i.e. mediaclient) in order to get all the device nodes back and fully working. Can this be improved? One way that comes to mind is a udev rule that restarts the service.
Thoughts?
1 Like
Yes, udev could trigger a restart.
It might be an idea for Sundtek to handle this upstream with their driver.
The driver is listening to what the kernel is sending to it (disconnects are part of that), I don’t think that tvheadend can handle sudden disconnects properly.
Bad USB Hubs I’ve seen that a few times over the years.