[vdr] Re: Broken stream detection (again)

[Peter Dittmann <peter.dittmann@freenet.de>]

On Fri, 13 Jun 2003, you wrote:
> Peter Dittmann wrote:
> > On Thu, 12 Jun 2003, you wrote:
> 
> >> So I assume you told VDR to set the system time from a transponder?
> > 
> > Yes, but I disabled this today evening and the glitches are still there. They
> > are more or less precize 72min +/- 30sec (to precize to be concidence !)
> > And they correct automaticly in the next log entry without VDR now kicking in
> > (with enabled time setting VDR was kicking in to fix the system time).
> > If you read carefully: according log it was not VDR that caused this offset,
> > but VDR was fixing it !
> > I'm absolutely shure no other service is running that set/tweak
> > system time on this system.
> > To me this locks like a race condition, e.g. checking time at a critical time
> > window that caused some temporary overflow.
> > (by the way 2^32usec are 71min 34,9673sec and timer.c counts usec's;
> > strange coincidence ;-) )
> 
> What kind of hardware do you have? This sounds very unusual and I think
> you should take this to the kernel developers at
> linux-kernel@vger.kernel.org.
It's a rather standard BX board (ABIT) with P2/300. Nothing fancy, but the board
runs rock solid now for 2 1/2 years.
With the old Suse7.1 I was using a custom compiled kernel so may be this
improves the behaviour.
Currently I'm using the of-shelf kernel Suse 8.1/2.4.19, may be it's not
running optimal.
Anyway the kernel files (timer.c) mention allready a lot of workarounds for
buggy clocks. Maybe there are more variants they think.
> 
> >>> I was just pointing towards there are several people complaining
> >>> about LIRC time problems, some complain about glitches in
> >>> recordings (which I have now as of timers being continously
> >>> stopped and restarted), a lot are complaining about emergency
> >>> exits.
> >> 
> >> These seem to be different problems, but if your time jumps (for whatever
> >> reason), than all kind of things may break - not only VDR.
> > 
> > Shure ??!
> 
> Yes. People have problems with "emergency Exits" because the receiption
> on the cards get bad due to rain and therefore VDR restarts. Most
> glitches in recordings were due tu bugs in the driver/firmware.
> 
Yes, but normally it should wait for 30 seconds util exit. Because of the
broken time on my board a single event is sufficiant to cause the emergency
exit. So the problem multiplies. 
I've just added a conter additional to the timeout and now it prevents the
broken stream exit
> Lirc problems often (but not always) happen, because people run 
> rdate/ntpdate. Which was not the case for me
> 
> Actually, I have the feeling that you are barking up the wrong tree - but
> it's just a feeling.
Possibly.
I was just thinking we should take a wider view. 
If we rule out things too early that we don't like or that we believe that
could not fail we do a mistake.
I was just stumbling across a software crash in the DVD code I'm working on for
my living that was caused by assert() (a library function that should
normally work). We had considered a crash in a different task or interrupt
handler more likely.
In this case it was a missing traphandler in the ROM version that crashed once
the assert failed. 
It seemed impossible until I just tried out the obvious: assert(FALSE)   ;-))

regards	Peter


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.