[linux-dvb] Re: Drivers not reporting TIMEDOUT

[Nico Sabbi <nsabbi@tiscali.it>]

Holger Waechtler wrote:

> Nico Sabbi wrote:
>
> > Hi,
> > 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?
Additionally, why can't I specify the timeout threshold?

At the current state of things I have to set 2 timeouts:

tm1 = tm2 = time(NULL);
while (((festatus & FE_TIMEDOUT)==0) && ((festatus & FE_HAS_LOCK)==0) && 
(tm2 - tm1 < 3) && (locks < 2))
{
   ...
   tm2 = time(NULL);
}

that is very ugly.

> Why would you want something like this, can you please try to 
> elaborate your needs a little more in detail? A simple "tuning 
> failed/no or bad signal" message can easily get implemented in 
> userspace, just set the poll()/select() timeout to your user-defined 
> limit and then check whether the READ_STATUS ioctl reports a lock 
> within this time.
>
> Holger
done as above.
There's another problem: ghost locking. If you 1) tune to a "good" 
frequency, then 2) tune to a wrong one,
often the FE_READ_STATUS on the wrong one (2) reports FE_HAS_LOCK, even 
though the frontend
didn't lock at all, so it seems it's reporting the FE_HAS_LOCK related 
to 1).
This happens both on my Nova-S and on my Airstar2 with yesterday's 
dvb-kernel and all previous versions
that I used.
That's why I added && (locks < 2) in the while loop.

   Nico