[linux-dvb] Re: Drivers not reporting TIMEDOUT

[Johannes Stezenbach <js@linuxtv.org>]

Nico Sabbi wrote:
> Holger Waechtler wrote:
> >Nico Sabbi wrote:
> >>it seems that not all drivers set TIMEDOUT when tuning on a "wrong"
> >>frequency, in my case Airstar2 does not.
> >>It would be nice if all frontends implemented this mechanism :) 
> >
> >There is no objective criteria for a timeout on DVB, especially for 
> >DVB-T the signal cn disappear and reappear at any time, not?
> 
> It's a matter of clarity: why some frontends set the flag and others don't ?
> If a timeout flag exists I should have a way to determine if I can use 
> or not, correct?

What the original Nokia spec said was that after tuning you get
either a "success" of "failure" event, where it is up to the driver
to decide how long it tries before reporting failure. Additionally
the spec had an "unexpected" event (i.e. when someone pulls out
the antenna cable).

We changed this to FE_TIMEDOUT in the V3 API, after much discussion.
Basically Holger wanted to drop the timeout altogehter, because he
thinks that the driver cannot know how long an application is willing
to wait.

OTOH my thinking is that the worst case tuning time depends on the
hardware (e.g. struct dvb_frontend_tune_settings .min_delay_ms),
thus the app cannot know how long to wait.

But basically this is only relevant for channel scanning when you want
to hop to the next frequency as soon as possible. For normal zapping
the timeout is only relevant for displaying "no signal" to the user,
and thus should be chosen to match user expectations.

BTW, applications should always listen for frontend status changes
(from an event loop or a thread, via poll() or select() on the
frontend file descriptor) because they can happen at any time,
and then use FE_READ_STATUS to find out what's up.

> Additionally, why can't I specify the timeout threshold?

Just use the proper timeout for poll() or
compare gettimeofday() values to implement the timeout.

Johannes