[vdr] Re: Broken stream detection (again)

[peter.dittmann@philips.com]

> peter.dittmann@philips.com wrote:
>> I've just experimented this morning a bit with the broken stream exit
>> in recorder.c. As indicated erlier I've seen in my logs that broken
>> stream detection and emergency exit contains a bullshit system time.
>> It seems to be about 70min in the future. VDR is correcting this on
>> the next time setting. Anyhow the wrong system time fools the broken
>> stream detection (timeout is always true). So a single problems on
>> reception is here causing an immediate emergency exits. I've had
>> problems in the past (Suse 7.1) with lirc complaining about reverse
>> jumps of system time (IEEE: your clock jumped backward). It seemsed
>> not VDR is causing this but a scrappy hardware timer of the board
>> maybe in conjunction with some flaws in the kernel.

> The question here is:

> How do you set your system clock? Do you use the VDR feature to set the
> time? Do you use rdate or ntpdate?

> Normally, the system clock *does not* jump. It's always a user process
> that forces a jump, e.g. rdate updateing the clock.
> This is considered bad as it may break different things, like drivers or
> daemons (as you noticed). Best practice is to use rdate/ntpdate only once
> at system boot time and then run ntpd to get a smoothly adjusted clock.

> Cheers,
> Juri


I neighter use rdate or ntpdate.
It's just VDR which may correct the system time (I don't know if Klaus uses rdate/ntpdate or just an API call).
Anyway I don't expect VDR to add 70min to the system time just for fun.
I have no log entry that VDR was setting it to the scrappy time but you always see it's VDR setting the time back to were it belong.
So the big question is who's crewing up the system time in first place?
The installation is a freshly installed Suse 8.1. Except VDR nowbody else should be set up to do updates to system time.
No external services are running. So there is absolutely no source for system time updates other than VDR.

I've in the past experienced strange events with system time. One of those was the LIRC problem with system time jumping backwards.
This gave me the creeps and finally cause me to invest 50EUR into an IRMAN so I got rid of this system time dependency.

I've also noticed a shifted CMOS clock on my system when I rebooted after several days/weeks of the system being up and running.
The time was always set to a future time, mostly several hours or days in future.
This happened with VDR setting system time and without.
Therefore my assumption of a scrappy board with the help of the kernel . . .

In the current case the CMOS clock was untouched.
I will try to do some experiments with disabling VDR setting the time, but I rather fear this has nothing to do with VDR.

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.
Maybe all this is triggered by the system time having glitches.

If you take time looking over the kernel files for timer, you realize a lot of constrains and fixes for different hardware (CPU types). Maybe not everything is working cleanly on all the boards.
I remember even finding some warnings about not monotonic time events in those kernel files.
Maybe we have to live with small glitches in the system time and need some extra protection in VDR against this ;-)).

kind regards      Peter








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