[vdr] Re: Fixed tuner lock detection

[Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de>]

Wolfgang Fritz wrote:
> 
> ...
> > As far as I have observed, FE_READ_STATUS has always immediately returned
> > FE_HAS_LOCK, even if FE_GET_EVENT took several loops to do so. So my
> > interpretaton of this is that FE_GET_EVENT is the right way to go. But
> > once FE_GET_EVENT returns FE_HAS_LOCK, it must be ok for the application
> > to set filters etc. After all it says _HAS_ lock, and not
> > I_THINK_I_MIGHT_HAVE_A_LOCK_BUT_I_M_NOT_SURE_YET_ ;-)
> 
> FE_HAS_LOCK _may_ mean I_HAVE_LOCK_NOW_BUT_WHO_KNOWS_WHAT_IS_200MS_LATER
> when the signal conditions are marginal.

Bad receiption is IMHO a different story. So far ther are no explicit
mechanisms in VDR to handle such cases. Since they happen only rather
rarely, at least I haven't had any real need to do something in that area,
yet.

> With the current
> implementation, one "rising edge" of FE_HAS_LOCK signals a good locking
> condition until you retune to another channel. I never trust edges on
> level based signals. A little debouncing never hurts. OK, you may argue
> that it has to be done in the drivers.

At least if the signal is strong the driver should never cause a "spike"
in the lock indicator. With a weak signal, even if you wait for 200ms
you can't know what would happen after another 200ms.

So what I'm saying is: a "spike" in the lock indicator is IMHO a driver
bug if the signal is actually strong. If we want to be prepared for a loss
of lock in general, that would probably take a lot more in VDR than just
waiting for 200ms. A loss of lock can happen at any time.

> > I believe this makes things only unnecessarily complex.
> > What we really should focus on is to avoid this situation in the
> > first place. The modification to VDR's tuning code is certainly
> > a step in the riht direction. Now if the driver delivers "spikes"
> > of FE_HAS_LOCK, these must be fixed in the driver.
> >
> 
> I dont' focus on driver bugs here but valid reasons for a loss of lock
> (marginal receiving conditions, faulty cable etc.)

Which, as I stated above, would have to be handled differently, anyway.
Under "normal" operating conditions (i.e. we have a strong signal) there
should be a real lock at the first occurrence of a FE event that has
FE_HAS_LOCK set. Having to wait for several hundred milliseconds every
time the channel is switched would only unnecessarily slow down channel
switching.

> Two real scenarios I've experienced myself:
> 
> 1. One recording running on card 1, another one on card 2. Cable to card
> 2 interrupted accidently by user (me).
> Result: emergency exit, recording on working card 1 corrupted unnecessarily.
> 
> 2. I took my VDR to a friend for a demonstration who has only on cable
> available. During my demonstration, a timer started a recording on the
> card without cable.
> Result: Repeating emergency exits, VDR unusable until I managed to kill
> the offending timer via the RC after several tries (a 20 second timeout
> is sometimes too short). My friend was not impressed.

Well, I guess one can always construct examples to argue in any direction ;-)
If the driver were more stable, the whole "energency exit" stuff probably
wouldn't be needed in the first place. If, in your first example, you would
have accidently interrupted the cable on the recording card, the recording
would have been broken, too.

Klaus