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 put it mildly, incredulous. 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 this 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 without fault. It's just an arbitrary demonstration that given certain circumstances the driver will work, but given another set it might not. For example I can tell you that TVH works perfectly well in many installations, with other multi-tuner devices (including TBS cards) and several very large IPTV setups (incidentally some using TBS cards, but not the 6981's). 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, though 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 (more likely).

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.

However, 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, I think its about 10 ioctl's to each FE in sequence), 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 starts to goes away.

Now can anyone think of a 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.

I should at this point make it clear this problem does not occur with Luis' driver, at all, ever, period! Oh and his driver does now include a get_frontend call, you can dispute whether its an accurate reproduction, but we have no way to substantiate such claims.

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 (at best). 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.

Also I can be considered to represent a reasonable (and growing number) of disgruntled, paying customers of TBS, who feel this problem is not being properly investigated and instead the sole intention is to place blame on the Tvheadend project (simply for demonstrating the weaknesses in the driver). Now of course, if TBS can explain exactly why and what we're doing wrong. And how they think we should fix it, without having to suffer poor performance elsewhere (or adding arbitrary delays to cope with the flakiness of the TBS driver). I'm all ears.

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: I don't actually have any diseqc kit, so I've not been able to check this, so if you're using a non-zero port number it might fail to tune.

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)

UPDATE:

We have now tried the supposedly "fixed" driver. And guess what, apart from the fact that its got most of the functionality stripped out, and has terrible performance I guess you might called it "fixed". I don't think anyone else would though.

Running the same tests as above, we now find that with an enforced delay between tuning calls to the 2 FE's, we see that the driver enters the same "failure to lock" state for several seconds (approx 2-3) before eventually locking. The frequency at which this long delay occurs appears to drop as the delay between tuning ops is increased. So yes, the driver is indeed "fixed" as long as you're willing to live with such awful zap times (or bodge the userland to cope with such poor driver implementation).

This unexplained failure to lock for several seconds was something I used to see with my own 6981, but never did get to the bottom of, now I have a pretty good idea of what is happening.