Konstantin,

Apologies for the delay in replying, I've been very busy the last few days and to be honest I've been losing the energy to deal with this.

1. With regard to making Tvheadend robust to flakey drivers, I'm not totally against this. Ultimately I want the best user experience for our users. If that means putting in workarounds for broken hardware and/or drivers, then we'll do it (if there is no other option). However in this instance, there is another option. Well 2; 1) use the OSS driver that doesn't suffer the problems of the TBS closed driver or 2) continue to deal with TBS in the hope that eventually it will get fixed upstream.

2. This brings me neatly on to my second point. I have never said that "close source drivers are bad". Personally I prefer open drivers, it allows more eyes on problems. It also removes issues with on-going support should a closed product no longer receive support (end-of-life) etc... However I'm well aware that many HW vendors do not like the technicals details of their products being revealed (mostly for flawed reasons, but that's another issue). And so we have to live in the real world and accept that sometimes drivers will be closed. Sometimes this works (NVIDIA would be the obvious example) and sometimes it does not.

3. With regard to your statements about the test code and TVH being "demanding". You're seriously still on that line? You think the test application is too demanding because it happens to open 1 tuner immediately after another in a simple sequence. And that the application should add an artificial and arbitrary delay (since there is no documentation of any of this, and if such a delay is required for this peice of hardware it should be in the driver) to solve the problem. And what if 2 completely unconnected applications were used to communicate with 2 tuners and they happened to open them very closely? That's not hypothetical, we've tested that as well and it fails. Now these 2 unconnected applications need to communicate with each other to work around the problem?

4. And now to the latest explanation of this (there have been several) "caused by not enough time for proper tuner power to be applied". So let me get this straight, there is a fundamental hardware limitation that means opening the two tuners one after another means there is not enough time for power to reach the frontends and causing them to fail? I've read Luis' driver and I must be missing something because I cannot find any "void bend_the_laws_of_physics (void)" function that allows him to magically overcome this limitation.

5. I should point out that we've not tested your latest driver (attached to last email). I have asked for volunteers on the IRC channel, unfortuantely its very hard to find anyone willing to actually install TBS drivers since Luis' is performing so well and doesn't suffer the limitations of the official one. But I will try and get someone to try it and see what, if anything, has been fixed (without needing horrible workarounds in TVH).

5. And finally I'm going to lay it out straight what we believe the issue to be. This is based both on Luis analysis of the official driver and development of his. It's also been my suspicion for a long time (back when I first had similar issues with my 6981), and certainly fits very well with the results of the test applications we've written. You are of course free to reject this and ultimately we have little we can do to counter, since we cannot see the code.

There is a complete failure to lock concurrent access to the shared I2C bus between the dual tuners (and on the 6984 the pairs of dual tuners). This results in I2C commands sent to the frontends trashing each other, this completely explains why we're able to cause one tuner to (fairly) reliably fail by tuning both one after the other. It most likely explains why your "fixed" driver no longer fails to lock indefinitely, but takes so bloody long. I'm assuming something is doing some background checking and eventually resending commands.

Luis' driver clearly doesn't have this limitation, he has properly protected all access to the shared I2C. His driver performs flawlessly (though I accept there could be problems in the future, and ultimately we'd still prefer to see upstream TBS support for fixing this issue) and has some side benefits (like being easier to deploy etc...)

Now hopefully this will give you something to think about and I really hope we can finally get this problem sorted. We all still agree that the TBS kit is very good in terms of both performance and value for money. And it seems a real shame that it's all being let down by some rather poor software.

Regards
Adam

--

Quote of the day: "We never EVER blame the user programs.", Linus Torvalds