TBS 6981 debacle

We’ve recently been having lots of problems reported with the TBS6981 device (something I used up until very recently when TBS very kindly sent me a 6985 to allow me to do more development while keeping my TV viewing uninterrupted). Anyway there has been a lot of speculation about what exactly is the fault and where the blame lies.

Both camps (Tvheadend and TBS) have clearly got very different opinions on the matter. TBS stand by the position that since Tvheadend is the only application that appears to be affected it must be at fault. Not an entirely ridiculous statement. However the reasons for the failure are, to put it mildly, ludicrous.

The current position is that Tvheadend is sending too many requests to the driver and overloading it causing it to fail. I should at this point state that we only request the status every 1 second once locked, and during the lock period once every 50ms. This is admittedly quicker than previously (as we changed the architecture) but hardly something I would expect to strain a device of this nature. And the reason why this seems to only affect the TBS6981 (we’ve had no reports of other devices suffering such problems, including several other TBS devices), because it includes a “professional grade feature” that most other OSS drivers do not include. So the addition of such a high performance feature is the reason a simple application like Tvheadend is able to overload the device, really!

However Tvheadend have a very different view. This failure was seen previously (when we were not querying so fast) albeit it with a much lower frequency. In addition we also saw other similar failures, where for example the tuner would lock but would take an unexpected period (for no obvious reason). Unfortunately due to time constraints I was never able to get to the bottom of this problem before retiring my 6981 (I see no such problems with my 6985).

Recently a Tvheadend user also got so fed up with his tuner not working that he decided to embark on writing his own version to see if he could understand what was causing the failure and what might be done to remedy the situation. This driver has proved very successful and I would urge any 6981 users to try it, .

We now believe that we understand why the TBS driver fails so miserably. We have even managed to create a simple test application that appears to demonstrate the failure, with a simple “workaround” (hack really) to make the TBS driver appear to work (we’re pretty sure why this works). Luis’ driver has no such problems and always works, and with typical zap times that are slightly quicker than the official driver.

However TBS are sticking to there guns and are continuing to place blame on Tvheadend. To this end their driver maintainer, Konstantin Dimitrov, has created a “fixed” version of the driver that appears to work with Tvheadend 3.4. It should be noted that this version of the driver has the “professional grade” feature, as well as a whole host of other features (of varying degrees of importance) removed.

In some respects this driver does appear to “fix” the problem, indeed Tvheadend 3.4 appears to perform much more like 3.2 with this driver. However the test application we developed throws up a few more interesting results. It does appear to eventually lock, where the official driver would fail, however only at the expense of a 1-3s delay in zap time. Hardly what I’d call fixed. And although in the limited testing we’ve done so far we’ve not managed to cause this version to entirely lock up, we wouldn’t rule it out as a possibility. Though we have a suspicion as to what might have been done to stop this from happening (and also explain the delay in lock time on the second tuner).

Anyway for the sake of openness, and to keep all Tvheadend users informed, I have copied the current email thread (and will try and keep things updated).

Adam
(on behalf of the Tvheadend team)

UPDATE:

We’ve now had a couple of responses from Konstantin. One seemed slightly more positive in that he admitted not having read my test code and acknowledging he should do this. Then another saying he’d missed something he’d added to the 6984 driver, but basically still placing the blame on Tvheadend.

To be honest I’ve gotten a bit bored with this whole thing, so I’m going to send a very frank and to the point response. Including possibly a reference to a recent Linus quote (just for fun).

UPDATE:

OK, it’s now been over 2 weeks since we explicitly stated our understanding of the problems in the TBS drivers. We’ve had ZERO response from anyone inside TBS. We know that they’re now fully aware of the work Luis’ has done as its got further through the review process for acceptance into the kernel. And Konstantin has at least commented on a peripheral topic related to the submission.

I guess we can only hope that Konstantin and TBS are busy beavering away looking at Luis’ driver and discovering how to write a driver properly when it uses multiple threads accessing a shared resource!

For his part Luis’ has begun supporting other cards from TBS that use the same chipset. So far I believe this includes the TBS6980, TBS6981 and TBS6984.

—

Email Thread (I have temporarily removed Rob’s comments, this is simply because I didn’t ask his permission, and having now done so I will remove the comments until I’ve heard back from him)

---

TBS6981: Issue when using both frontends simultaneously in Tvheadend

---

Rob Hunter	10 June 2013 13:02
To: euro_support@tbsdtv.com
<removed>

---

Adam Sutton	10 June 2013 15:12
To: Rob Hunter Cc: euro_support@tbsdtv.com
All, I should clarify that my TBS6981 did work, the issues I experienced were a long time ago and were worked around by ensuring that the FE devices were not closed (this because an issue when I added features to shut down tuners to reduce power consumption, in response to user requests). It appeared that my 6981 (and others) had trouble with opening the various devices in a particular order. I could reliably cause my device to fail (symptons was low/no signal on one tuner) by opening up all device handles (FE, DMX, DVR) on an adapter, closing all but the FE and then doing the same on the second. I simply never found the time to investigate and since I wasn’t too concerned about power consumption I simply added a config value to disable the power saving mode and keep my tuners permanently open. The recent issues might relate to the fact we’ve once again changed the model to close down DVR devices when not in use since not doing this between tunings results in stale data entering the pipelines (and is against the suggested best practice of the DVB API) and can cause TVH to get confused regarding mux configuration (i.e. its assuming the incoming data is for the currently selected mux, but if stale data exists this might not be the case). None of these problems seem to exist with my 6985, and unfortunately I can’t easily re-insert my 6981 as I only have the 1 PCIe port. Adam P.S. Some details above might be sketchy/wrong, this all happened 6+months ago. [Quoted text hidden]

---

Konstantin Dimitrov	11 June 2013 08:40
To: Adam Sutton Cc: Rob Hunter, support <support@tbsdtv.com>
hi All,based on details Adam gave i believe TVHeadend together with 6981 driver can trigger problems related to the use of ‘hotplug’ for firmware upload or any similar way for firmware upload, i.e. on-demand firmware upload, especially when there are multiple frontends involved. few months ago i sent to one customer driver for 6984 (which is basically like 2 x 6981 on one board as far as frontend is concerned) with disabled any on-demand firmware upload, because he was experiencing issues with TVHeadend. what Adam described about open/close and so on, can be explained with on-demand firmware upload, but what Rob is describing here:https://tvheadend.org/boards/5/topics/8524cannot be explained with that, because if on-demand firmware upload is messed-up with close/open of different devices that will leave the frontend in completely uninitialized state in which it can’t function at all and will result in simple no signal lock – as how it was in the 6984 case i’ve just mentioned. so, what we can try first is i make driver for 6981 without on-demand firmware upload and see if that will help and based on the results proceed from there. that idea makes sense at the moment, because on-demand firmware upload is the only common thing for both frontends, i.e. there is nothing else that can cause interference in work of one frontend to the other at least in software. so, please, give me few days to make such changes to 6981 drivers.best regards, konstantin

---

Adam Sutton	11 June 2013 09:29
To: Konstantin Dimitrov Cc: Rob Hunter, support <support@tbsdtv.com>
Konstantin, Thanks that’s very useful input. A few questions: – What is the purpose of the on-demand firmware download (is it just to ensure it keeps the FW up to date on each open of the device)? – And what’s the alternative: Load it once on module start/device registration? What are the real advantages of on-demand? – What is it that triggers the on-demand load, is it opening of the FE device? – And if this is a known problem on some setups, maybe it would be useful to create a module option that allows it to be disabled (rather than having custom modules etc…). Regards Adam [Quoted text hidden]

---

Konstantin Dimitrov	11 June 2013 11:05
To: Adam Sutton Cc: Rob Hunter, support <support@tbsdtv.com>
Adam,i’m going to answer your questions in no particular order, because they are all related. so, with GPL drivers the biggest advantage and purpose, i guess, of on-demand firmware upload via ‘hotplug’ is that it actually makes the things possible at all, because those firmware blobs are not under GPL and in fact for many drivers you need to extract them from the Windows drivers on your own, because even distribution rights are not clear. so, that allows to keep GPL driver and firmware blob separate and avoid any conflicts with different licenses. in case of 6981, since the whole frontend driver is not under GPL, the biggest advantage of on-demand firmware upload is faster boot time. it’s exactly, because the alternative is to load it every time on module load and that costs a lot of CPU time, because firmware upload is done via slow communication line, needs a lot of interrupts and that way it causes huge CPU load – even that’s just for several seconds, it could be quite a problem if you have many cards in the system, because on all of them firmware will be uploaded during boot time – the end result would be total lost of responsiveness during boot and that can last minutes depending on the number of cards that need firmware upload. so, on-demand firmware upload from side of the driver is done in similar to the following way – every time the frontend is accessed for something that requires full initialization, the driver analyzes briefly the status of frontend and decides based on that if on-demand firmware upload should be performed or not. so, in the usual case close/open won’t cause firmware upload as far as some of those operations (or their particular order) didn’t cause power down (of blocks) of the frontend or de-initialize something. i guess the things would be much more consistent and predictable if status of power management of V4L was better. anyway, if that’s the problem there is nothing, at least i see, that can be done from the side of user-space software and if removing on-demand firmware upload helps for TVHeadend then next step is exactly module parameter that allows user to choose firmware upload mode.best regards, konstantin

---

Adam Sutton	11 June 2013 11:30
To: Konstantin Dimitrov Cc: Rob Hunter, support <support@tbsdtv.com>
Konstantin, If closing the FE device “could” be a trigger for this problem I could definitely investigate including an option in TVH to keep the FE open. I think the main concerns for this have come from users running NAS boxes (and may or may not be related to TBS devices) where they want the devices to power down when idle. But this is a problem on many DVB devices where they will not enter low power state until all possible device handles are closed (which can also be important for TVH to operate properly with suspend as well, else devices can often get into funny states and things lock up). However I’m pretty sure the current problems are being experienced even without closing the FE, but I’m not 100% sure about that. Is there any way to determine when a FW download occurs? Or why this would only be an issue when using a dual+ device from a single process with specific device open/close ordering. My own tests when I had hte problem showed it all worked fine if I used each of the 6981 tuners independently from 2 TVH instances, it was only ever if I opened them both from the same process and open/closed the device handles in a particular order. Adam

---

Rob Hunter	16 June 2013 15:21
To: Adam Sutton Cc: Konstantin Dimitrov, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	21 June 2013 19:10
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
hi Rob,sorry for the delay, i just needed some time to prepare the driver changes i mentioned in my initial comments on the issue. so, please, download install and test the following driver from here:http://wikisend.com/download/976690/linux-tbs-drivers_130621.tar.bz2or:http://www.basicupload.com/gt0rawhie4bnand let us know if it makes any difference for you.thank you, konstantin

Konstantin Dimitrov	21 June 2013 19:44
To: Adam Sutton Cc: Rob Hunter, support <support@tbsdtv.com>
hi Adam,sorry, that i wasn’t able to get back to you earlier. however, in the mean time i prepared driver for Rob to test and it has the following changes:a) no any power-down or clocks down on frontend close b) no on-demand firmware upload, which together with a) means firmware stays running no matter what’s going onso, let’s see if that will make change for Rod.i don’t believe closing the frontend gives any results in the general case for reducing power consumption for NAS users, etc. – maybe there are frontend drivers in which proper power management was achieved on close, but if i review open-source frontend drivers for chips which i have datasheet or that datasheet is public, most of them have no any power-down on close or it’s not entirely proper. so, as far as DVB-S/S2 frontend drivers are concerned most of the power consumption can be saved with just shutting down the LNB power – that in fact is always the main source of power consumption in case of DVB-S/S2 card.there is no way to know the firmware upload status, but i believe it would be useful if V4L is extended and be able to report such information as part of the frontend status, i.e. there is flag for frontend capabilities that indicates the frontend use firmware and different information for the firmware can be obtained including its version. unfortunately, such changes happen very slow or don’t happen at all with V4L – good example for that is so many years after DVB-S2 support was added, still ‘get_frontend’ ioctl is not DVB-S2 aware – that’s TBS drivers for Linux report information for DVB-S2 signal via ‘get_frontend’ ioctl in not some standard way and the rest of the drivers don’t do it at all. so, there are many aspects in which V4L needs work.best regards, konstantin

---

Adam Sutton	21 June 2013 20:08
To: Konstantin Dimitrov Cc: Rob Hunter, support <support@tbsdtv.com>
Konstantin, The comment about power-saving was in relation to some specific drivers (non TBS), it was just that it implied generic behaviour within in tvheadend (closing FE) which might have related to the effects we’ve been seeing with the TBS. And yes we also turn the LNB off independently of the close FD option (though that’s also configurable as some multi LNBs seem to have poor isolation and closing one can  cause short burst of interference on others). I completely agree, there are some very bad things (short comings) in the DVB API. One we came up against recently is we added a full mux RX feature (Andreas has some crazy idea to use this for 0-time zapping within a given mux, by pre-buffering data etc… to find first i-frame, though that’s me just waffling 🙂 ) but what we realised is there isn’t actually anyway to determine if a card supports full mux reception. You basically have to set it up and see, but before that’s useful you need to know that you expect data on a mux in the first place, bit chicken and egg. I know there has been quite a lot of recent effort in improving the V4L API, I think IIRC the DVB API is no longer part of the kernel tree. But I’ve not really followed the developments. I’ve only really started to get more closely involved since embarking on this DVB rewrite for TVH. Maybe once that’s out of the way I can start kicking people about the things I think are missing. Anyway thanks for teh driver and hopefully Rob will test it, I’ll also point a few others at it that have been reporting various issues with the 6981. Regards Adam

---

Rob Hunter	21 June 2013 21:07
To: Adam Sutton Cc: Konstantin Dimitrov, support <support@tbsdtv.com>
<removed>

---

Rob Hunter	21 June 2013 23:04
To: Adam Sutton Cc: Konstantin Dimitrov, support <support@tbsdtv.com>
<removed>

---

Adam Sutton	22 June 2013 09:12
To: Rob Hunter Cc: Konstantin Dimitrov, support <support@tbsdtv.com>
Rob, To rule out recent changes in TVH can you try and older version, say 3.2, you’ll need to build this yourself from git. But if you need help let me know and I’ll walk you through it. Adam

---

Rob Hunter	22 June 2013 17:33
To: Adam Sutton Cc: Konstantin Dimitrov, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	1 July 2013 16:26
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
hi Rob,thank you for all those tests – it looks to me what you’re describing can’t be caused by the drivers – the two frontends are completely independent – if it’s driver fault then it won’t be possible to use the two frontends simultaneously in any software (in fact that’s good test to do in your environment, i.e. use the two frontends simultaneously with running 2xDVBlasts), which is not the case – 6981 is very popular in Linux, we have customers building embedded systems with it and run tens of 6981 cards in the same system via PCIe backplane with no complains. so, i see two options left:a) there is fault on your 6981 or more general something in your environment causes the problem and it’s on hardware level – using the two tuners means the two LNB power circuits on 6981 are on and active, that increases the power consumption and could trigger the problem – even your LNB, especially if it’s Dual LNB, could be at fault in such case and cause the problem – for example it experiences some frequency shift when the two LNBs inside are powered-up and receive power.b) how tvheadend access the two frontends – they share the same PCIe endpoint and i can’t exclude that option, but i highly doubt it, because there are thousands Linux users of 6981 and i believe it’s safe to assume significant number of them are using tvheadend, which would mean at least hundreds of complains, but 6981 is in production for several years now – no such complain have reached me except yours.so, what you can do to get better idea is what i already suggested – run any other software – preferable something that is known to work fine like DVBlasts and that way utilize the two frontends at the same time – if the problem occurs again then basically b) is ruled out and that leaves a) for which what we can do is replace your 6981 board with new one – no guarantee it’s that, but at least we make sure what depends on us is done. best regards, konstantin

---

Konstantin Dimitrov	1 July 2013 16:37
To: Adam Sutton Cc: Rob Hunter, support <support@tbsdtv.com>
hi Adam,after i read last reports by Rob, i don’t believe the problem has anything to do with the drivers and even 6981 in general – most likely there is some interference on hardware level – either due to fault on Rob’s 6981 board or in his LNBs – that can be confirmed if any other software experience problems with using the two frontends at the same time – especially software like DVBlast, which we have customer running tens of DVBlast processes with tens of 6981 cards in the same system and it can be trusted as working free of any issues. there is slight change though, that it could be how and how often tvheadend access the frontends and some weird timing issue related to the common PCIe endpoint, because that’s the only shared thing between them – both in hardware and in software the two frontends are completely independent, but that’s really very wild idea. i want to get to the bottom of this problem and when you’re aware of any other issues with tvheadend and TBS board – please, point me out to them to review what the users reports – in my own experience maybe in 95% of all cases of problem reports it’s hardware fault and only in 5% it’s a bug. in fact if it’s not some mass problem reported by many people it’s almost always hardware fault, because that’s make it isolated case to some customer and his/her particular environment.best regards, konstantin

---

Rob Hunter	1 July 2013 16:46
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	1 July 2013 17:02
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
Rob, i see and that means option b) is in place, because if other software like vdr works then it just can’t be driver problem or anything that i can affect from driver side. i have no idea what could be wrong in Tvheadend, but what we can try in such case from driver side for a fast test is remove as much as possible from the code that access the frontends – what i mean – for example instead report the real signal strength and quality obtained from the hardware just report constant number and so on. that will reduce the load on the hardware if by some chance Tvheadend causes too many such transactions and can at least give some new clue. that’s really the only other idea i have, because i can’t think of anything else except that maybe Tvheadend access and get frontend status too often and overloads the board that way. i will review the driver code and prepare such test driver as soon as possible – maybe even later today if i find some spare time from the rest of my tasks.–konstantin

---

Rob Hunter	1 July 2013 17:08
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	1 July 2013 17:24
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
Rob, in the mean time, please, do test with the following changes:* open in text editor “linux-tbs-drivers/linux/drivers/media/video/cx23885/cx23885-core.c”* find the line:dev->i2c_bus[1].i2c_period = (0x27 << 24);and change it to: dev->i2c_bus[1].i2c_period = (0x9d << 24); printk(“cx23885_130701_mod\n”); * save the file and rebuild and reinstall the driver that line “printk(“cx23885_130701_mod\n”);” is added just to check on ‘dmesg’ and confirm you really run the modified driver. BTW, what “tbs6981fe – software version is:” you currently get on ‘dmesg’ after the driver is loaded? thanks, konstantin [Quoted text hidden]

---

Rob Hunter	2 July 2013 11:26
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	10 July 2013 19:47
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
hi Rob,sorry for the delay, i have a lot work to do. so, here is the new test driver:http://wikisend.com/download/514978/linux-tbs-drivers_6981_11.tar.bz2orhttp://www.basicupload.com/zas87ivg9fnh please, give it a try and let me know your results – any change in the behavior you’re currently having is important to get better idea. so, just one more time for completeness to mention what i already mentioned the last time – the changes in this drivers are to lower as much as possible transactions to the hardware, because i do believe TVHeadend with the way how it access the frontends overloads the hardware – that’s done in different ways in this new driver version, but to give one example – instead return real signal strength and SNR obtained from the hardware this driver just returns fixed dummy values in order to lower the number of real transaction to the hardware caused by TVHeadend access and use similar ways for almost everything that can be avoided as transaction to the hardware. so, if such driver even not fixes, but just improves a little the work that in my opinion means my hypothesis is confirmed. thank you, konstantin [Quoted text hidden]

---

Adam Sutton	10 July 2013 20:16
To: Konstantin Dimitrov Cc: Rob Hunter, support <support@tbsdtv.com>, Luis Alves
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 to our IRC channel. 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 investigate the issue further. He has managed to write an OSS 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

---

Konstantin Dimitrov	10 July 2013 21:26
To: Adam Sutton Cc: Rob Hunter, support <support@tbsdtv.com>, Luis Alves
Adam,i can’t quite agree with those arguments – as i mentioned we have customers running tens of 6981 card in the same Linux system with PCIe back-planes – no problems, i.e. if that issue was driver performance problem alone it will be quite obvious in such configuration. also, even i haven’t seen that OSS driver i bet it implements partially the Linux DVB API, e.g. things like “get_frontend” ioctl and such are missing and not implemented. so, pretty much those missing things from full API implementation do the same, i.e. dummy or empty functions and result in the same – lower the transaction load on the device and that by no any mean exclude TVH – i mean it doesn’t prove TVH can work with let’s say driver that have full “get_frontend” ioctl implementation and transaction load due to that and not missing or dummy one. also, if TVH wasn’t involved then VDR, DVBlast, etc will suffer from the same issue. last, but not least i’m interested for which other Dual DVB-S2 cards you’re talking, because the other one that came in mind are using Montage chips for which the Linux drivers are made by me too. so, it’s not that simple to state TBS drivers are at fault, especially when no other application except TVH with the same transactions from the driver side can create the problem.best regards, konstantin [Quoted text hidden]

---

Konstantin Dimitrov	10 July 2013 21:52
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
Rob, have you tested with those changes below – they lower the transaction speed to PCIe bridge ‘cx23885’ and are not part of the mainline Linux kernel driver for ‘cx23885’, which could be another reason that can explain what Adam reported in his last email.thanks, konstantin [Quoted text hidden]

---

Rob Hunter	10 July 2013 22:03
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Rob Hunter	10 July 2013 22:03
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	10 July 2013 22:15
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
Rob, thanks, so you have tested it and that rules out the transaction speed to ‘cx23885’. i have a feeling that issue might me related to something in ‘cx23885’ driver that is not part of the mainline kernel and contributes to the overload when the device is accessed often – the only other such difference that came to mind is IR support for ‘cx23885’ – in mainline kernel IR support is disabled by default and if it’s enabled that most likely will cause interrupt storm and won’t work properly. so, that’s different in TBS drivers and please, next time when do tests disable IR support in TBS driver – the easy way is with creating text file called for example “tbs.conf” in “/etc/modprobe.d” that contains the line “options cx23885 enable_tbs_ir=0”:# cat /etc/modprobe.d/tbs.confoptions cx23885 enable_tbs_ir=0and then reboot or rmmod/modprobe the modules to activate.–konstantin

---

Rob Hunter	10 July 2013 22:56
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Konstantin Dimitrov	10 July 2013 23:36
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
hi Rob,thank you for doing the test so fast – i understand Adam won’t like what i will say, but your test results show that what i stated as hypothesis earlier is true and what i further elaborated as contra-arguments to Adam’s statement that’s fault of TBS drivers is correct too. so, considering i’m quite sure those OSS drivers Adam mentioned doesn’t implement things from the API like ‘get_frontend’ ioctl that means they work only due to that, i.e. not due to some big magic and superiority, but because they already have lowered number of transactions due to those missing things or the same reason for which “linux-tbs-drivers_6981_11.tar.bz2” works for you. so, everything adds up now.what we can do as next steps is one-by-one re-add the things i removed from the driver to lower the transactions until their number reach the point when TVH will cause overload and break the work. also, ‘get_frontend’ ioctl is my main suspect at the moment, because no OSS driver in Linux implements that, because it’s quite hard – even when you have datasheets under NDA there is usually not enough information to implement it, but it’s mandatory requirement by all customers doing professional-grade solutions. so, maybe, soon we will be able to say something quite concrete like TVH causes overload when there is ‘get_frontend’ ioctl implemented or something like that due to most likely some timing problem, because that ioctl is called by V4L on lock acquisition. anyway, as next step i will flood you with at least several drivers that re-adds different things from what i removed to test them in order to narrow it down until it’s pin-pointed. in any case there is no doubt for me TVH has some implementation problem, because removing things defined in Linux DVB API made it works normal, that’s not normal, no matter if Adam admits it or not. also, from driver point of view there is almost no freedom how to implement the API, but from application point of view there are for sure wrong ways to use the API.BTW, there is no point to do the IR test, because obviously from your test results it’s not that – current conclusion is quite clear – that with way how TVH access the frontends the frontend driver needs to make limited number of transactions otherwise TVH will cause overload and it seems the number of transactions that driver for 6981 is doing is close to that threshold, i.e. removing not that much transactions made the work stable even in such case. however, that’s really huge performance degradation caused by TVH considering what i mentioned several times – that we have customers running 16 or even 32 x 6981 cards in the same system via PCIe back-planes with DVBlast and overload happens only with 2 tuners of one such card when the card is used with TVH. also, it means, the other Dual tuner cards that are working fine with TVH are probably working only because they have faster frontend chips that can take those transactions without overload.best regards, konstantin

Rob Hunter	11 July 2013 09:33
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>

---

Adam Sutton	11 July 2013 21:34
To: Konstantin Dimitrov Cc: James Liu@tbs, bob@tbs, support <support@tbsdtv.com>, Rob Hunter
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 1-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  awful zap times on one tuner (or bodge your app 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.

---

Konstantin Dimitrov	11 July 2013 22:04
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
hi Rob,please, send me ‘uname -a’ output from your test computer – just to know for what kernel to build the module, which will save me time instead build modules for all kernels as for the release drivers. so, since we both are very busy my idea is every few days to give you one or few versions that you can test in the mean time. that way we should be able to narrow it down quite fast.thanks, konstantin

Konstantin Dimitrov	11 July 2013 23:09
To: Adam Sutton Cc: James Liu@tbs, bob@tbs, support <support@tbsdtv.com>, Rob Hunter
Adam,the test you’re describing with opening, tune, etc consecutively the frontends including the test application for that was sent to me by John Smith <johns90812@gmail.com> few months ago. maybe, you worked with him on that and use the same test application or you made new one, i don’t know, but the test you’re describing is exactly like the one he made. anyway, there is nothing for the reader to figure out on that further, because the problem was created due to way how frontend is powered-up on ‘open’, which resulted in instability and random tuner power cut if there is no any delay. since John Smith reported that for 6984 (same frontend as 6981), i investigated and fixed that for 6984 and provided fixed drivers to him, but release drivers do not include that fix, with which i guess you’re testing. however, that fix is included in 6981 drivers i gave here to Rod some time ago – the first test version without on-demand firmware upload and i kind of doubt you will be able to reproduce such problem with that same test using driver with the necessary fix included. also, as you can see from Rob’s reports “linux-tbs-drivers_6981_11.tar.bz2” i provided works fine with two tuners running even in TVH. so, that makes the problem clearer to me too. i’m not in the business of “your software is crap” argument, because as you see i’m obviously after the truth, i.e. trying to understand the problem and that’s why worked on it and provided those test version i made, otherwise i will do just nothing and do not make a single test driver version. however, the true statement “6981 official drivers work fine with any other software except with current versions of TVH” is equally good to the other true (according to you) statement “6981 OSS reverse-engineered drivers work with current versions of TVH”, because none of those excludes TVH as source of the problem, as well none of them excludes 6981 official drivers, but the working “linux-tbs-drivers_6981_11.tar.bz2”, which is after all based on the official driver gives idea in another direction. so, in my opinion, definition of driver problem is problem that is reproducible with all applications, if it’s reproducible only with one particular application then even if fix for that is introduced in the driver that fix is workaround for that particular application and not fixing driver bug. i wish i have the spare time to review and investigate in-depth what TVH is doing and why the issue is triggered and say something completely concrete, but unfortunately i don’t because i maintain over 20 Linux drivers – that’s the reason why i kindly ask Rob to do the tests instead do them myself and count on that. however, i believe with the further tests Rod is going to do, that will narrow it down and something quite more concrete as conclusion would be made. also, contrary to you, i believe it would be quite more lucrative for you to do the same as what i do, i.e. as how i made different changes and as result of that have “linux-tbs-drivers_6981_11.tar.bz2”, which is working and that gives me ideas from driver perspective, do changes in TVH until you get stable work with unmodified driver the same how those same drivers work with the rest of Linux DVB applications, because otherwise you don’t really get idea from TVH perspective – mean you can’t answer why even according to you broken driver works just fine with VDR and DVBlast.best regards, konstantin

---

Adam Sutton	12 July 2013 10:44
To: Konstantin Dimitrov Cc: James Liu@TBS, bob@TBS, support <support@tbsdtv.com>, Rob Hunter, Luis Alves
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)

---

Konstantin Dimitrov	15 July 2013 19:48
To: Adam Sutton Cc: James Liu, bob, support <support@tbsdtv.com>, Rob Hunter, Luis Alves
Adam,it seems to me a lot is lost in the translation actually, because more we discuss it’s less clear if we talk for the same things. also, i’ve just noticed in your previous email you sent me your test application – sorry, i missed to read your P.S. and that now seems like the main reason for the confusion to both of us – i will check your code in that test application and get back to you. so, first on the points and then i will go a little outside the points:1. at least the only complain about 6984 and TVH that reached me is what i already mentioned, reported by John Smith <johns90812@gmail.com> and he sent me very simple test application to demonstrate that, which as functionality seems to do the same as what you described about your test application – for me that was just a description, because i have missed to notice your actually sent me the code, as i’ve just mentioned – that’s no doubt that’s my fault to overlook the whole P.S. note in your previous email. that’s why last time i just assumed what your test application does, but now i will be able to tell more after i review it. however, if the problem is the same as the one i know with 6984 (and it will be active on 6981 too) – tuner power-up fails if delay between opening the frontends is less than 1ms then there is no mystery about that problem to me, i.e. it can be explained based on NDA technical information for the chips i have. so, i don’t know any other problem with 6984 and TVH even though the frontend driver is the same, as well the connection of that frontend driver to the PCIe bridge is the same. so, the question that needs clarification on this point is do we talk for the same or different problem in case of 6984 and John Smith <johns90812@gmail.com> test application, which is already fixed in reliable way or you mean and found something completely different with 6981 – at least i mixed those two problems – maybe that way confuse both myself and you. i will dig up John Smith <johns90812@gmail.com> test code – it’s also useful to test drivers. 1a. the only purpose of the last test version i provided to Rob “linux-tbs-drivers_6981_11.tar.bz2” is for testing purposes, i.e. to be able to get some clues and those i shared with you in details. also, even the first version i provided Rob (which doesn’t lack any features) should not experience the problem in 1, at least the one i believe we’re talking about. so, either we’re talking for completely different things or we totally misunderstand each other, which hopefully it will be cleared out, after i check your test code. 2. then think from another point of view to it – let’s assume the driver is broken then if TVH is immune to the problem that broken  driver has, like the other applications, it would mean TVH performance is better than it has before, don’t you agree? i agree with you it’s best drivers to be made in way resilient to anything that can be trigger from application side, but the same is true for the applications – it’s just the application is with better overall performance if it’s immune to any possible problems that some driver might have. in both ways though, that’s either the application or the driver introducing an workaround for respectively that driver or application problem. 3. where i claimed such thing – i can’t claim anything about your test application, because as i mentioned i haven’t seen it, because i haven’t noticed your P.S. – as i told you in my previous email as well in point 1 of this i just assume based on the description you made it’s like the one John Smith <johns90812@gmail.com> sent me. they could be completely different, even the problem(s) you can reproduce in your test application can be due even some minimum difference with one that John Smith <johns90812@gmail.com> sent me. i believe even from my previous email is obvious by the way how i’m talking, e.g. “maybe, you worked with him on that and use the same test application or you made new one, i don’t know, but the test you’re describing is exactly like the one he made.” that i just didn’t notice the link to the test application you sent m and it’s just based on the description you made what the test application does. 4. completely wrong – you can read my previous email, where i basically said that both statement are equally good, when no one can explain the real cause of the problem at the moment. in fact, as i believe is obvious from my actions so fat, that i’m trying to understand it and once again that’s the reason why driver mentioned in 1a exists and not that’s my proposal for final solution, i.e. some driver with features removed, that’s just part of the road that needs to be traveled until the cause is narrowed down and then workaround for it is introduced – no matter if it’s the driver or application fault. so, as i said, if i don’t believe i can avoid it from driver side then i basically will do nothing and don’t even make a single test driver. however, what i’m saying is that it seems to me your explanation is that “close source drivers are bad” and as well it seems again to me that from my side you believe that my position is “your software is crap”. none of which is correct, i don’t even need to sound like i’m defending myself on this, because ask anyone at TBS that i vouched for TVHeadend to be included on MOI as default software – initial company position was to go for completely proprietary software solution. 5. i don’t understand this point at all – what delay and where i proposed such thing, that seems like you putting words in my mount 5a. that misunderstanding seems is caused by the same reason – that i missed to notice P.S. note with link to your test application in your previous email altogether. 6. the same reason as 5a so, outside those points – you can see another driver that is made by me, which use cx24116 structure for the API implementation: http://git.linuxtv.org/media_tree.git/blob/61c4f2c81c61f73549928dfd9f3e8f26aa36a8cf:/drivers/media/dvb/frontends/ds3000.c and i’m pointing out that driver only because of the comments regarding the work of the hardware – for example: /* set low-pass filter period */ /* ds3000 build-in uC reset */ /* enable ac coupling */ and so on. BTW, that driver also drives a lot of Dual tuner cards. so, with such comments present that driver more or less can be maintained even if you don’t have datasheets as far as you have idea about how such kind of chips work in general and it’s something basically everyone with such knowledge can modify, extent, improve, really in an open-source spirit and can be considered open-source. however, i saw Luis email to linux-media today – the obvious problem is that can’t be maintained – with everyone that has access to the datasheets not really allowed to contribute and with all hardware settings as it seems to me just reverse-engineered from the driver i made, i.e. simply firing up the proprietary driver in disassembler and cloning all hardware settings without any understanding what they really do (or with some limited understanding) those setting are just some magic numbers in that code in the style: writereg(0xea, 0x00); writereg(0xea, 0x01); writereg(0xea, 0x00); so, in case of hardware related problems (i.e. some transponder can’t be locked due to wrong initialization) or need of feature extension (i.e. something that’s not as feature in my driver) that can’t be a solution, i.e. as hardware related features it’s limited to what can be cloned from the proprietary driver as settings. also, when all those settings came from disassembling the proprietary driver – it’s good that to be mentioned – even if you wish as credit, because those settings the author didn’t make, just “clone” them from someone’s else work – many of them are not even my work either, which mean note like “RE from Conexant and TBS proprietary driver” is something that seems appropriate. there is nothing wrong though in clean-room reverse-engineering – it’s not work that can be undermined, because it do requires skills – kudos for that. last, that i want to mention – is that from all mentioned by you tests, i haven’t got if you’re using the exact same ‘cx23885’ (and even V4L) code-base when test both codes – the proprietary one and not, because if not that’s not very conclusive testing either. best regards, konstantin

---

Konstantin Dimitrov	18 July 2013 19:06
To: Rob Hunter Cc: Adam Sutton, support <support@tbsdtv.com>
hi Rob,i didn’t bother you to test different version in order to narrow down the cause, because Adam provided test application and i just waited to find some spare minutes to look at it and do some fast tests with that application. so, here: http://www.basicupload.com/1d8vdhahm35n and here: http://wikisend.com/download/305944/linux-tbs-drivers_130718.tar.bz2 is driver that fixes what at least i can see with the test application – in general that’s the same driver i sent you on June 21 with the only difference back then i didn’t move everything to 6981 driver from the old fix i made for 6984. so, it’s up to see if that’s the same what’s going on in TVH. thank you, konstantin

Konstantin Dimitrov <cody@turbosight.com>	18 July 2013 19:23
To: Adam Sutton Cc: James Liu, bob, support <support@tbsdtv.com>, Rob Hunter, Luis Alves
Adam,at least what i can reproduce with your test application is the same that i can reproduce with John Smith <johns90812@gmail.com> tool that he made for 6984, which i’m attaching for completeness – it’s simpler than yours – even transponder parameters are hard-coded. so, that’s the exact same problem for which i told you from the very first time after you and Rob contacted me about the problem – what i did wrong though is that the driver i provided to Rob on June 21 with supposedly that fix from 6984 driver fully applied was wrong, i.e. i didn’t move all related parts from the 6984 fix to that 6981 driver. so, as i explained back then that’s caused by not enough time for proper tuner power to be applied. anyway, if what is reproducible with those two test applications is the same that’s going on with TVH then it’s nothing generally wrong with the driver, certainly nothing that requires the entire driver, which is tested in the last 3-4 years by thousands, to be re-written and that way one problem be fixed and unknown number of new ones be introduced. so far all that is consistent with why no other applications hit that problem – because they are not that demanding. in any case it will become clear, because as you can see in the other email that i sent, there are links to the June 21 driver with properly applied the 6984 fix i made March this year for John Smith <johns90812@gmail.com>. best regards, konstantin

---

Adam Sutton	18 July 2013 21:25
To: Konstantin Dimitrov Cc: James Liu, bob , support <support@tbsdtv.com>, Rob Hunter , Luis Alves
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…) 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 hardware is very good in terms of both performance and value for money. Regards Adam — Quote of the day: “We never EVER blame the user programs.”, Linus Torvalds [Quoted text hidden]

---

Rob Hunter	18 July 2013 22:40
To: Konstantin Dimitrov Cc: Adam Sutton, support <support@tbsdtv.com>
<removed>