On 08.01.2009 07:10, Jan Ekholm wrote:
Hi folks,
Should I worry when my syslog fills up with stuff like this:
Jan 8 06:30:51 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:30:52 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322 Jan 8 06:30:52 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:30:53 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322 Jan 8 06:30:53 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:30:54 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322 Jan 8 06:30:54 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:30:56 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322 Jan 8 06:30:56 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:30:57 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322 Jan 8 06:30:57 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:30:59 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322 Jan 8 06:30:59 hex vdr: [2965] frontend 0 regained lock on channel 33, tp 322 Jan 8 06:36:15 hex vdr: [2965] frontend 0 lost lock on channel 33, tp 322
My VDR is 1.6.0 and the kernel is what's stock on a stable Debian, ie. 2.6.18-6-amd64. Everything seems to work ok and I think frontend 0 is the one that's only used for recording, frontend 1 is the one with the CI and which supplies the image (two FF DVB-c cards in use (does anyone still use those?)).
Anyway, should I worry and/or is this something I could "fix" by upgrading something?
This means that either the signal is actually so weak that the lock is lost over and over again, or there is a flaw in the driver that makes VDR "think" the lock has been lost.
What happens if you switch both devices to that transponder? Do both frontends behave the same then?
Does it also happen with other transponders, or only with this one?
Klaus