Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Drivers not reporting TIMEDOUT
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?
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.
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
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.
Main Index |