> Hi, I'm using a WinTV Nova DVB-T card in the UK. > > I've used the older 0.9.4 drivers, and the newer drivers from > the 2.5.47 kernel. I am having the same problem reported > earlier by others... Namely that the 2.5.47 drivers do not > tune in as well as the 0.9.4 ones. > > Observing the output of dvbtune with 2.5.47, I see the driver > attempts to tune for a short time, but then returns > FE_TIMEDOUT to the application.. Which then gives up.... > However if you try it repeatedly, it eventually works fine.. > I'm using exactly the same parameters for tuning with both, > so I suspect this has to be a driver problem. > > With the 0.9.4 drivers, tuning is pretty much instantaneous. > > I am wondering if anyone else is looking into this behaviour? > If not, I shall try and fix it...
Hi, I've found exactly where the problem is in the DVB code now. Somehow the kernel HZ timing also affected this as I reported in my other mail, but I think this must be a side effect, perhaps something just being "on the edge". The issue is in dvb_frontend_thread(), specifically when it calls dvb_frontend_recover(). The problem seems to be that on the initial tuning, the card doesn't have long enough to tune itself, so the thread loops round, and calls dvb_frontend_recover(). Which then starts off a zigzag scan to compensate for LNB drift (which isn't actually happening). I tested this by commenting dvb_frontend_recover() out... Now my card always tunes perfectly. However, this is obviously not a solution as it disables LNB drift compensation. A solution might be to differentiate between tuning because-the-application-requested-it, and tuning-because-sync-was-lost in dvb_frontend_thread(). I'm going to have a look into doing this tomorrow. I see there is already something like this elsewhere in the code (the first_trial parameter in dvb_frontend_set_parameters()). -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
