Andrew de Quincey wrote: > > > In the meantime, I've found another problem in dvb_frontend.c: > > > > Although the code has the ability to scan about on frequencies surrounding > > the requested frequency, it isn't actually being given the time to do so. > > The following patch fixes this, and ensures at least one cycle of scanning > > completes before giving up. The reason I haven't checked this in is because > > I'm worried it breaks something else, and I want to give anyone time to > > object. > > Actually on second thoughts that big initial delay on the first tune seems to > be about 3 seconds.... and the initial value of delay in the frontend_thread > IS 3*HZ... > > In that case, the first attempt to tune if it needed a zigzag scan would fail > because the initial delay is so huge. Then the next attempt would work, as > long as the thread hadn't died too fast. > > Sound familiar anyone?
IMHO the sane thing to do would be: - FE_SET_FRONTEND sets some flag meaning "were are changing channels" and then wakes up the frontend thread - FE thread then reinitializes "delay" to some sane initial value The schedule_timeout(1) in FE_SET_FRONTEND is just bogus. But the whole update_delay() thing is the result of many experiments done by Holger, and works fine most of the time... I would be happy if you could clean this up. Johannes -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.