Konstantin,

I'm afraid things have moved on quite a bit since we last spoke. I have seen the above arguments elsewhere. A TVH user, it might have been Rob, posted the comments elsewhere.

I must say I was very disappointed by the answers. I agree that the problem with the TBS drivers seems to be exposed by the way TVH operates (compared to other systems), but this really shouldn't imply fault on the part of TVH. Especially since we are able to operate with pretty much every other dual tuner device, including many TBS devices. And if we're querying the driver too quickly, and this restriction is not clearly documented, then its the fault of the driver for not protecting itself (which is probably true even if it is a documented limitation).

The solution of returning "fixed" values is a very poor one, it demonstrates a lack of understanding of the problem at best, and poor judgement at worst. Assuming you can't find the underlying issue, that causes the device to fail when queried for its status at a mere 50Hz. I would have thought a much more sensible solution would be to simply rate limit the querying of the device, returning cached values in between periodic queries to the hardware.

However, as I mentioned things have already moved on. Because one user was so perturbed by the problems and had the same belief this was a driver issue, he has taken the  time to reverse engineer the driver (pretty much copying an existing OSS driver for a similar conextant chip). This has proved very fruitful, his driver doesn't suffer from the issues the TBS official driver does and we have a very good idea what the underlying cause of the problems in the TBS driver is.

We're hoping that this driver will be submitted to the Linux kernel in the coming weeks and will be strongly recommending that anyone using this device migrates to this version.

Regards
Adam