Konstantin,

You're quite right in your assumption that the answers you have provided will not satisfy me, or the dozen plus (and growing) number of users who have begun to abandon the TBS official driver.

They are, to but it mildly ludicrous. I don't really want to get into a "your software is crap" argument, for one thing its futile. TVH's code is completely open, you're free to browse it and point out where we're putting too much strain on the TBS6981 (or even other devices, though we've yet to find one). In fact this would be in TBS's best interest, since they're using the particular version of TVH on their MOI devices. Of course I cannot do the same with the TBS driver, though through the work we've done we can make a reasonable assumption of the failures.

Whether the driver "works" with other applications or performs in a large (presumably) IPTV arrangement is also mostly meaningless, it doesn't imply the driver is perfect and without fault. It's just an arbitrary demonstration that given certain circumstances the driver will work and given another set it might not. For example I can tell you that TVH works perfectly well in many installations, with other multi-tuner rigs (including TBS cards) and several very large IPTV setups (incidentally using TBS cards, but not the 6981). But what does that really tell us about this particular problem?

Clearly something has changed in TVH, as the problem didn't appear (so often, but it did happen), in the previous release. And indeed one change is we have increased the rate at which we check the frontend status while waiting for lock. Previously status was checked once per second (always), now its checked once every 50ms until lock (then reverts to once per second). However there are other changes that might also be relevant.

If you're seriously telling me that the addition of a "professional grade feature" (that we don't, knowingly, use) can create a total failure at this (very meagre) rate, that's very concerning indeed (for TBS). At the very least if it was that the hardware couldn't cope, it would seem sensible to put some basic rate limit protection in place to stop the hardware being hit so often. Returning cached values in between periodic calls to the hardware.

Given that we have a pretty good understanding, based on the work Luis has done with his driver, what the real failure case is we put together our own tests. We have managed to create a small test application that produces some very interesting results.

If we open and tune each FE in quick succession (i.e open FE0, tune FE0, open FE1, tune FE1), which would seem a fairly benign operation (and could hardly class as a high rate of interactions), we can make the tuner fail. Even without rapidly querying it for its state. Now this failure is NOT 100%, its random, but it's a fairly high probability. However if we introduce a small delay between the open/tune operation of each FE (open FE0, tune FE0, wait, open FE1, tune FE1), the problem magically goes away.

Now can anyone think what class of problems occur in software that cause symptoms where adding arbitrary delays between operations results in the removal (or addition) or seemingly random operation? I'll leave it as an exercise for the reader to figure that one out.

For now, we will simply be recommending that no one use the official TBS 6981 driver with TVH, as its known to be very flakey and prone to failure. And instead they should use Luis' version. It is however an unfortunate position, we've had a good relation over the past year and I think we all accept the TBS hardware (when it works) is very good and very competitively priced.

Regards
Adam

P.S.
If you're interested in trying the test code, you can find it here, https://www.dropbox.com/s/mz1i2xmkfv04v4r/tbs6981.c. The params are as follows:

-a "ADAPTER_NUMBER FREQUENCY POLARITY BAUDRATE FEC_INNER MODULATION DELSYS SWITCHPORT"
-d DELAY // in ms between open/tune calls
-p PERIOD // in ms (max 1000) between FE_READ_STATUS calls (when not locked, always 1s when locked)

Note: will only work with Universal LNB, and its hardly had extensive testing of all params.

For example,

./tbs6981 -a "0 12524 H 30000 AUTO QPSK S 0" -a "1 11778 V 27500 AUTO QPSK S 0"  -p 1000 -d 0

will fail, randomly. Usually the first tuner appears to work, the second does not.

./tbs6981 -a "0 12524 H 30000 AUTO QPSK S 0" -a "1 11778 V 27500 AUTO QPSK S 0"  -p 1000 -d 50

will always succeed (more precisely, the likelihood of success increases with DELAY)