Konstantin,

I'm somewhat confused by your response, though maybe something is being lost in translation. However I will try to cover your points as clearly and concisely as I can:

1. I was aware that you'd also been experiencing problems with the reliability of the 6984 driver and that some users had been helping with investigations. However the performance of that system, for whatever reason, does not appear as bad as the 6981 (even though I believe the boards share many components) with TVH. I have my suspicions as to why this might be so.

1a. If this "fix" is in the drivers you have provided Rob, which we tested, that may indeed explain why it appeared to eventually resolve itself. However I strongly dispute the claim that the version you have provided Rob is "fixed". What it is, is a heavily bodged implementation to get "something" to work, even though that appears to be at the expense of lots of functionality and pretty awful performance.

2. You're definition of a driver problem being "problem that is reproducible with all applications" is rubbish, and I must say I'm shocked that someone would try and claim this. By your definition (this is hypothetical) if all other applications in the world don't use (or trigger) some particular code path, but 1 particular does and causes the driver to fail, it must be the application at fault because nothing else can generate the failure.

3. Your claim my test application is just another pointless data point, is also nonsense. My test application is not some large multi-faceted application (like TVH or VDR). It is a very small and concise application whose primary purpose is to demonstrate a failure case in another piece of software (in this case your driver). Now I'm sure you've come across such things in your professional career. But just in case you haven't, we'd generally define that as a "Unit Test Case".

4. So far you are suggesting that TVH is the root cause of the problem, and is able to cause your driver to lock/fail. If someone claimed this about TVH, even if they were explicitly trying to make the application fail by sending it bad instructions, I would not be blaming that user/client. I would be trying to understand how to defend against such things and ensure the application is robust to such inputs.

5. And you're only proposed fix is that we add an arbitrary delay between tuning calls. This smacks of a complete lack of understanding of the problem. Adding arbitrary delays to make things "go away" is not the sort of solution I would expect from a professional software engineer. Now of course if you can explain "why" we need that delay (only for this device) and what the required delay is then I'll be happy to add a "TBS driver delay" option.

5a. Maybe you can explain why your "fixed" driver will flawlessly tune/lock a signal (within a few milliseconds) if we insert an arbitrary delay between the tuning calls (approx 20ms is enough) to each frontend. However without this delay, the driver takes in the order of 1-3s seconds to achieve a lock. And let me repeat this bit, this is very important: You really considered this a "fix"? that requiring an application to add an (small) arbitrary delay to stop it from taking a considerable (and unnecessary) time to achieve an operation is acceptable?

6. You've absolutely no need to investigate what TVH is doing, I have provided you with a very concise test application that replicates the sequence that TVH performs. It even has some helpful command line flags for changing the delay between tuning calls to allow you to see what effect this has on the performance of your driver "fixed" or not. The results of using this test application perfectly match what we see with TVH.

Maybe it would be worth you (or TBS) contacting Luis, to seek his advise an insight into where he believes the current driver is failing. Since he seems to have a pretty idea and has been able to generate a driver that performs reliably. I accept there may well be bugs in his driver that our tests do not expose, however clearly he has managed (and I don't believe by accident) to overcome this specific shortcoming in the official driver.

Regards
Adam (and a growing number of very disgruntled TBS customers)