I was looking into why the driver doesn't recover after a loss of signal (like when pulling the antenna cable for a few seconds) and found that apparently (at least with DVB-S) it starts a dvb_frontend_recover() sequence, but aquires a lock at a completely different frequency, which is some 16MHz off the original transponder.
This is not surprising, because the fe->lnb_drift takes on values of up to +/-15462 or so, which lets it run into the next transponder at the same polarization as the current one. So no wonder there is no more picture then, because the PIDs may be totally different on different transponders. I therefore limited the range of fe->lnb_drift in dvb_frontend_recover() to some 8MHz, but then it didn't lock on to any transponder any more. This is what puzzles me, because the original transponder was perfectly locked on with fe->lnb_drift==0, and that value is the first one that gets tried in dvb_frontend_recover(). And since there can (due to the limitation to 8MHz) be no more other transponder it might lock on to by mistake, I don't understand why it doesn't lock on to the original transponder any more. It just loops through the original frequency +/-8MHz in 32 steps over and over again. Note that I did all these tests with the most recent CVS version of the DVB driver, but dvb_frontend.c appears to be quite the same (with respect to the dvb_frontend_recover() mechanism) as in the dvb-kernel driver. Does anybody have an idea why this doesn't work as expected? We should really get this to work in order to make an application automatically "come back" after the signal was lost, for instance due to bad weather. Klaus -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.