Ville Skyttä wrote:
On Sunday 02 December 2007, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
I'll make it a 5 ms limit then, to allow default kernels to
On 06/09/07 21:40, Petri Hintukainen wrote:
On Sat, 2007-06-09 at 12:28 +0200, Udo Richter wrote:
And, from the original post:
May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38
2007 (1180632218)
May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007
I demand that Klaus Schmidinger may or may not have written...
[snip]
While testing this, I found that on my system the monotonic clock only has
a resolution of 4000250 ns (about 4 ms), which in your original patch would
have caused VDR not to use the monotonic clock.
That suggests that your
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
[snip]
While testing this, I found that on my system the monotonic clock only has
a resolution of 4000250 ns (about 4 ms), which in your original patch would
have caused VDR not to use the
I demand that Klaus Schmidinger may or may not have written...
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
[snip]
While testing this, I found that on my system the monotonic clock only
has a resolution of 4000250 ns (about 4 ms), which
On 02/12/2007, Darren Salt [EMAIL PROTECTED] wrote:
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an
arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100,
128, 250, 256, 1000 and 1024.)
zen-sources which are a really good option for multimedia desktop
On 12/02/07 16:09, Grégoire FAVRE wrote:
On 02/12/2007, Darren Salt [EMAIL PROTECTED] wrote:
Valid HZ options are 100, 250, 300 and 1000, unless overridden by an
arch-specific Kconfig file. (AFAICS, only mips does this, offering 48, 100,
128, 250, 256, 1000 and 1024.)
zen-sources which
On Sunday 02 December 2007, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
I'll make it a 5 ms limit then, to allow default kernels to work.
Valid HZ
[EMAIL PROTECTED](Klaus Schmidinger) 02.12.07 14:47
On 12/02/07 14:34, Darren Salt wrote:
I demand that Klaus Schmidinger may or may not have written...
[snip]
While testing this, I found that on my system the monotonic clock
only has a resolution of 4000250 ns (about 4 ms), which in your
On Sun, 2007-06-10 at 12:31 +0200, Clemens Kirchgatterer wrote:
Petri Hintukainen [EMAIL PROTECTED] wrote:
If clock is turned 2 minutes back in middle of this, the code will
wait 120100 ms instead of 100ms ... Might cause some quite weird
problems. I belive there's no way to change
Petri Hintukainen wrote:
It might be even some plugin. All timeouts (cTimeMs, cCondVar,
cCondWait) use current wall clock time to set the timeout.
Thats not even all: There are 140 references to time(NULL) in VDR, and
most of them are used for timeouts between a few seconds and some hours.
On Sun, 2007-06-10 at 14:59 +0200, Udo Richter wrote:
Petri Hintukainen wrote:
It might be even some plugin. All timeouts (cTimeMs, cCondVar,
cCondWait) use current wall clock time to set the timeout.
Thats not even all: There are 140 references to time(NULL) in VDR, and
most of them
Josce Unknown schrieb:
Well if the PC clock was correct all the time I would probably not have
to use the set time function :)
Yes, but typically PC HW clock does not drift so much. You could use
hwclock --systohc (and possibly --utc or --localtime) after letting
the vdr to set the system
Josce Unknown wrote:
I am sure this would fix the problem. However, is this really the way it
should work?
The clock is four minutes off, let's PANIC?
VDR still defaults to start recordings three minutes before scheduled
time, right? I wouldn't want to rely my recordings on a clock that is
VDR still defaults to start recordings three minutes before scheduled time,
right? I wouldn't want to rely my recordings on a clock that is that bad.
That's why I have set it to start ten minutes earlier :)
The worst I had was on a 286, running 40s off per day. Good thing that this
is over.
On Sat, 2007-06-09 at 12:28 +0200, Udo Richter wrote:
And, from the original post:
May 31 20:23:38 localhost vdr: [3413] System Time = Thu May 31 20:23:38
2007 (1180632218)
May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007
(1180631977)
May 31 20:21:01
Well if the PC clock was correct all the time I would probably not have
to use the set time function :)
Yes, but typically PC HW clock does not drift so much. You could use
hwclock --systohc (and possibly --utc or --localtime) after letting
the vdr to set the system clock.
I am sure this would
Hi
Currently, no, the TZ is set to GMT , the solution is to change it but it will
not resolve entierly the problem, when I shutdown the system, the clock of
another computer miss many days or year, meaning bios battery is dead and as
long this battery is not standard (std=cr2032 or equiv) I
Unknown Unknown wrote:
May 31 20:23:38 localhost vdr: [3413] Local Time = Thu May 31 20:19:37 2007
(1180631977)
May 31 20:21:01 localhost vdr: [3405] PANIC: watchdog timer expired -
exiting!
Could vdr turn off the watchdog before it sets the system time, if that is
the problem?
IMHO
Hi
By the way, I have another question about clock and vdr, I have put vdr
setting to synchronise time with a specific channel and setup vdr to start on
this channel.
Unfortunately , when vdr start, the system is never on time, at least there is
two hours minus. The main problem is that vdr
However, there are some other clock-dependent things in VDR that are not
designed to handle larger clock jumps. Usually, clock jumps should be
just a few seconds, and only after starting VDR.
You should investigate what causes the clock to jump 4 minutes. If your
PC clock is THAT bad, its
21 matches
Mail list logo
