Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: Fixed tuner lock detection



Wolfgang Fritz wrote:
> 
> ...
> >          if (tunerStatus != tsIdle) {
> >             dvb_frontend_event event;
> > -           if (ioctl(fd_frontend, FE_GET_EVENT, &event) == 0) {
> > -              if (event.status & FE_REINIT) {
> > -                 tunerStatus = tsSet;
> > -                 esyslog("ERROR: frontend %d was reinitialized - re-tuning", cardIndex);
> > +           while (ioctl(fd_frontend, FE_GET_EVENT, &event) == 0) {
> > +                 if (event.status & FE_REINIT) {
> > +                    tunerStatus = tsSet;
> > +                    esyslog("ERROR: frontend %d was reinitialized - re-tuning", cardIndex);
> > +                    }
> > +                 if (event.status & FE_HAS_LOCK) {
> 
> Question 1: Are you sure the drivers always signal a valid lock on the
> first "rising edge" of FE_HAS_LOCK? They didn't in the past (the "spike
> problem").

Well, if the driver sends an event that indicates FE_HAS_LOCK I'd say
it's ok for the application to assume that there actually _is_ a lock.
Anyting else is a driver bug and should be fixed there. IIRC there was
a fix in the driver for this recently.

The problem in the old code in VDR was that it has fetched the current
status with ioctl(fd_frontend, FE_READ_STATUS, &status) instead of reacting
on FE events. My tests showed that after tuning to a different transponder,
the FE_READ_STATUS immediately returned FE_HAS_LOCK, while the actual
event arrived somewhat later. I guess the FE_READ_STATUS call (sometimes)
delivered the status of the _previous_ lock.

> Question 2: How is the case of a loss of lock handled (May occur e.g. in
> bad weather conditions?). This case is not handled in
> DvbTuner::Action(). Do we get a VDSB error and an emergency exit?

There hasn't been any special code regarding loss of lock so far, and this
modification doesn't introduce one, either. I did try to do FE_READ_STATUS
in every loop and wanted to retune if the lock was lost, but apparently
the FE_HAS_LOCK sometimes gets 0 even though there is a perfect lock.
Maybe this is caused by the problem with the ves1x93, which sometimes
returns bogus status values.

Anyway, if there is no more data while a recording is going on, there
will still be an emergency exit. This fix here is only supposed to prevent
the DVB card from getting into an unstable condition by starting filters
before there is an actual lock.

> ...
> Fine! I am using a similar patch since quite some time now without problems.

I hope _this_ one will also work for you. It's mainly everything from
the existing suggestions that made sense to me.

Klaus




Home | Main Index | Thread Index