[linux-dvb] Re: Another issue: frontend timeout value and low symbol rates

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

On Monday 23 February 2004 20:29, Johannes Stezenbach wrote:
> 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.

Cool, I'll look into that tomorrow.

Actually, the update_delay() is fine; its just that the TIMEOUT doesn't take 
into account how long it takes to write to the frontend itself... I put in 
some instrumentation, and its taking 25 jiffies to call FE_SET_FRONTEND... 
I've checked the frontend code: no delays or anything.... (I'll check that 
out again tomorrow in case I missed something).

I need to know more rationale behind the timeouts in the frontend loop though. 
Is it meant to do at least one iteration of the zigzag scan when the lock is 
lost?

You see it doesn't actually make sense to me as to why the timeout stuff is 
there at all.. surely if a complete zigzag scan is done, and fails to lock on 
at any point, it should set FE_TIMEDOUT. Then, if the lock is regained (e.g. 
the cable is plugged back in), it can clear it again.

There is no point in setting FE_TIMEDOUT partway through a zigzag scan, 
because the next attempt in the scan might be the one which works... 
especially with low symbol rates which are _very_ sensitive to this.

To my understanding, the additional stuff with the TIMEOUT value is 
superfluous, and causes problems. If this isn't the case, can you tell me 
what I'm missing...


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.