[vdr] Timeouts and lost locks

Jan Ekholm jan.ekholm at smultron.net
Sat May 23 11:42:03 CEST 2009


On Friday 22 May 2009 14:22:16 Klaus Schmidinger wrote:
> On 22.05.2009 09:07, Jan Ekholm wrote:
> > Good morning,
> >
> > I see logging like this all the time in my syslog file:
> >
> > May 22 06:36:45 hex vdr: [31292] frontend 0 timed out while tuning to
> > channel 31, tp 298
> > May 22 06:37:06 hex vdr: [31292] frontend 0 timed out while tuning to
> > channel 33, tp 322
> >
> > And:
> >
> > May 22 09:59:58 hex vdr: [31292] frontend 0 lost lock on channel 41, tp
> > 338 May 22 09:59:59 hex vdr: [31292] frontend 0 regained lock on channel
> > 41, tp 338
> > May 22 10:00:01 hex vdr: [31292] frontend 0 lost lock on channel 41, tp
> > 338 May 22 10:00:01 hex vdr: [31292] frontend 0 regained lock on channel
> > 41, tp 338
> >
> > What does this mean? The channels referred to (31, 33 and 41) are
> > channels that we never, ever watch as they are encrypted. Normally these
> > three or neighbor channels are referred to in the error logging. We
> > almost never use channels above 20. So, why does VDR try to tune into
> > them and why would it fail? We have two FF cards but we still would like
> > them both to do something that benefits us, not go randomly tune into
> > uninteresting channels. :)
>
> Well, I'm still working on the code that reads the user's mind and
> determines what they might find "interesting" ;-)
>
> You can turn off the EPG scan to keep VDR from tuning through the
> various transponders.

But turning off the scanning means there's no EPG data? I would rather just 
disable the channels in channels.conf (or similar) so that they are there and 
updated with new data should they ever be needed. No point in VDR scanning a 
lot of channels (100+) that we can't anyway access nor want to have any EPG 
data for.

-- 
    There were no public health laws in Ankh-Morpork. It would be like
                installing smoke detectors in Hell.
                                            -- Terry Pratchett, Feet of Clay




More information about the vdr mailing list