Also, what’s the changelog for 251220.005308? It’s still missing from the German thread and the English forum referenced on the drivers page apparently hasn’t been updated since 2017.
Thanks
Yes, blue is USB3.
But which port you use should not matter. If you plan to attach a hard drive that can utilise USB3 speeds you are better off having the Sundtek tuner on the USB2 port because there is no benefit (throughput wise) having it on USB3
Sam
I would say nothing has changed for those drivers, we are using those drivers to test all the devices we ship out - before shipping. You wrote that you have two devices are both the same? (maybe you can send me the serial number so I know what you have)
elight is the codename for SkyTV 8 which is a pretty good tuner.
we recently fixed a race condition when opening / closing the tuner with VDR that’s all the only issue I might think about.
A complete tuner loss is usually a power problem as mentioned, maybe USB 3.0 might be shaky - or standby is kicking in on your system.
Try to obtain some system logs when tvheadend loses the tuner, there’s a reason for that.
check autosuspend:
cat /sys/module/usbcore/parameters/autosuspend
set it to -1 for testing if it’s another value.
echo -1 > /sys/module/usbcore/parameters/autosuspend
Yep, hence my question 
That’s exactly my setup.
See above, they are two “SkyTV Ultimate 8” (same order, so should be same revision).
I’ll report back when I the system is in a testable state again.
Hang on
So you’ve got a hard drive and two tuners attached?
You will almost certainly need a powered hub for this to work reliably.
Sam
Guys, please read more carefully. I already wrote twice that I’m using a powered hub for the two tuners, attached to USB2. The hub’s power supply provides 5.2V (measured) so power shouldn’t be an issue.
Thanks for clarifying.
I would be curious how things perform with just a single tuner attached
Sam
Try to use the tuner without hub, and the rest with the hub.
I think I did so during my initial tests but that didn’t help either. Stay tuned, I’m still trying to restore my TVH setup…
Looking at the suspected mapping (last updated: 2025-12-04 02:28) it seems fine but “My OSMC” reports 2025.08 after installation and a manual follow-up update indeed installs 2025.11, so something appears to be off with OSMC_TGT_vero5_20251201.img.gz 
Hi guys,
here’s an update: I restored my setup reinstalling OSMC 2025.08 and then replaced my ~/.kodi folder including the THV config from backups (while mediacenter being stopped). I then installed TVH from OSMC’s app store and finally installed the 251220.005308 Sundtek driver. Upon reboot the Vero V again locked up either during boot or shortly after - same as earlier. As above I wasn’t able to debug the problem any further as ssh access as well as frontend access isn’t possible anymore at that point. Please note that these lockups also happen without any tuner being connected.
I then restored the whole thing again the same way but instead used the 250816.183236 driver. It did not exhibit those lockups. So for my setup there’s clearly a regression in 251220.005308 which means I’m stuck with 250816.183236 and back to where I started three days ago.
So instead of trying the latest Sundtek driver I’ll now monitor TVH for lost tuners and will try to analyze the root cause of that, if possible.
Just a side note on bus power:
is your power connection to the USB ports suitable for that? Long term 300mA per port (when active), short term 400mA hike (transponder with poor signal).
While testing I noticed that USB2 (0.5A/black) probably can’t reliably power the tuner as dmesg shows multiple connect/disconnect cycles when plugging it in. This issue doesn’t happen on USB3 (0.9A/blue) or when using my powered hub (on USB2). Again, this doesn’t affect me due to the hub but it might help others, so I wanted to put it on record.
With my system now running as before (using 250816.183236) I had another look at mediaclient.log and found the following entries:
[2422] semaphore error:
[2422] unable to connect to driver: 1521 (111)
[2422] up failed 1:
Looking at the timestamps these triplets always occur during boot exactly 49 times, each with a different PID (assuming that’s what brackets mean). I presume they are emitted by the sundtek systemd service.
Hope this helps @Sundtek
That just means that the driver is not started, the driver is part of the binary “mediasrv” on the system.
Agreed, but doesn’t this mean that things happen in the wrong order? Ideally client/server wouldn’t emit any errors in a self-controlled workflow.
please join the chat and prepare some remote access so I can check the state of the driver on your system (the system itself doesn’t matter for me since everyone is using the same driver anyway).
Will do tomorrow but remote access isn’t an option. I also can’t debug the 202512 driver issue any further as I neither have a spare device nor the means to take a full image of the device (to easily restore it).
Cheers
try to sort out remote access so I can go through it quickly, eg. rustDesk and remote terminal from a desktop (you can set up the terminal before connecting, so it will be quicker). The quicker we’re done the better.
Thanks, I truely appreciate your offer. However, as I said, remote access isn’t an option. Keep in mind that the original problem (tuners dropping out of TVH) can’t be reliably reproduced right now. ATM it’s not even clear if the issue still persists after I reflashed my Vero.
Furthermore the 251220.005308 driver regression can’t be debugged remotely anyway since losing remote and direct access to the device is part of the symptoms. Apart from that I just can’t use my production device for further testing of that driver, unless there’s a way to fully dump and restore a system image (think Nandroid backup). Maybe Sam can lend you a test device?
As I said, thank you, but I’m going to keep monitoring how my system behaves with 250816.183236 and will investigate further if and when the original issue reappears.
Cheers
Thanks for the detailed explanation, and I understand your concerns—especially regarding using a production device and the difficulty of reproducing the issue reliably.
From our side, I’d like to be transparent about the situation: at the moment, we don’t see similar reports from other users, and all customers—including our own test setups—are running the same driver versions without comparable symptoms. This makes your case quite unusual, both from the Vero/OSMC perspective and from our driver side.
Because of that, the only realistic way for us to determine what’s happening is to observe the system directly while it’s running in your environment. We have daily driver builds and continuously test them across our devices, but without visibility into your setup, we’re essentially guessing—and that doesn’t lead to reliable conclusions.
Unfortunately, there’s no practical way for us to debug this purely offline or remotely via logs alone. A short period of remote access is currently the only method that allows us to inspect driver state, kernel interactions, and runtime behavior in a meaningful way. Without that, we simply don’t have enough data to identify whether this is a driver issue, an interaction with the system, or something else entirely.
Drivers can be extracted manually and started manually in eg. /tmp, a full installation is not even required.
Of course, it’s entirely your decision if remote access isn’t an option, and we respect that.
If at any point you change your mind or have access to a non-production or test device, we’d be happy to take another look.
Today I just got the feedback in from one customer who had an issue with his harddisk on a NAS system (his harddisk died), he is using two dual DVB-S/S2/S2X tuners and one single DVB-S/S2/S2X tuner and all of them work. He’s also using the latest driver, I think your problem is an electrical issue in some way