[vdr] Re: Broken stream detection (again)

[Juri Haberland <juri@koschikode.com>]

[Peter, please fix your client to wrap lines to a length of 76 chars max.
and please try to use a different mail client that keeps the
Reference-Headers in the mail so that the threading information doesn't
get lost]

peter.dittmann@philips.com wrote:

>> 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.

> 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.

So I assume you told VDR to set the system time from a transponder?

> 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 . . .

This might be just that you configured your OS wrong. If you run Linux
you should set the CMOS clock to UTC (formerly known as GMT) and tell
your Linux that the CMOS clock is running in UTC. Often Linux
distributions sync the cmos clock with the current system time on
shutdown. If you configured your system time wrong, there might be a jump
of one or more hours after a reboot, depending on your timezone and
daylight saving.

> 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.

> 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.

It runs for million users out there without a problem, so it must either
be a configuration error on your side or your hardware is badly broken.

Cheers,
Juri



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