[linux-dvb] Re: cinergyT2: which kernel/usb module to use?

[Andrew de Quincey <adq_dvb@lidskialf.net>]

> >> I any case the frontend_notifier callback code in dvb_frontend.c
> >> should work around this av711x/stv0299A bug, doesn't it works
> >> anymore, did any of the recent changes introduced a bug in this code?
> >
> > The problem is that the dvb-kernel driver just doesn't run reliably
> > (at least
> > for me). I recently tried the linux_2_4 branch, but every now and then a
> > channel switch failed. So if these "recent changes" are not in the (old)
> > DVB driver, I won't benefit from them.
>
> Ermmm... isn't the linux_2_4 branch exactly the 1.1.x release source?
> You are really encountering new problems there?
> With "recent changes" I meant Andrew's refactored code (now in the HEAD
> branch but not in linux_2_4).

There is a mysterious problem when you use VDR with a fullfeatured card as 
primary, and a budget card as secondary.

VDR uses the primary card to watch TV on, and the secondary one to download 
EPG information.. it constantly scans through all the frequencies on the 
secondary getting the latest EPG information.

The bug is that after a while, no more data can be received on the budget. 
Reloading the drivers does not help. It requires a reboot.

Supposedly older versions of DVB do not have this problem, while the problem 
appeared at some point around the time the change to 2.6 was made. However, 
no one has had the time yet AFAIK to go though the drivers month by month and 
locate the exact version at which the problem occurs, so it could have been 
at any time. This is essential if people want this problem fixed.

Could someone at least tell me a known good version of the DVB release?

We've been trying to identify the cause. I don't have an FF card, so I tried 
replicating it using two budget DVB-T cards (where one of them I simulated a 
user zapping between channels every 30 seconds, and on the other I did the 
EPG scan). I was unable to duplicate the problem.

Once the bug occurs, no interrupts are generated by the budget card (checked 
by catting /proc/interrupts). However, the frontend is able to tune and 
appears to work as normal - there is just no data. Note that the primary (FF) 
card still functions as normal - its the *budget* card that stops working.

It doesn't seem to be tied to any particular frontend either. Or a specific 
motherboard, or kernel version.