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 defaul
[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), wh
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.
>
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-sourc
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 des
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
On Sonntag, 2. Dezember 2007, Klaus Schmidinger wrote:
> 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
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 u
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 you
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
Hello,
sometimes, I can't use my xine anymore to connect to vdr, and my log
shows :
[9640] cleaning up schedules data
[9640] next timer event at Tue Jul 24 04:20:00 2007
[9640] executing 'sudo /usr/local/bin/vdrpoweroff.sh 1185243600 224659 222
"CHRONIQUES D'EN HAUT" 0'
[9640] PANIC: watchdog ti
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
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 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 chan
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 pthread_..._timedwait
> functions, but cTimeMs can be changed to use mo
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:
Managed to get the PANIC again, by doing this:
- set a timer to start 1 hour from now
- close vdr
- use date to set the clock 5 min forward (with date)
- reboot
Can someone else reproduce this?
Josce
Jun 9 22:23:10 localhost vdr: [2220] VDR version 1.4.5 started
Jun 9 22:23:10 localhost vdr:
>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.
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
t
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 se
>>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
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 can
On 06/05/07 19:47, PLU Dominique wrote:
> 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
PLU Dominique wrote:
> Is there a way to force vdr to first update system time to transponder time
> as design and after look if something is really scheduled ?
You could use a tool like dvbdate to update the clock before starting VDR.
If you have a permanent Internet connection, or at least some
hi,
Josce Unknown writes:
> 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 s
>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 pr
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 lo
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?
I
Hi,
With vdr 1.4.5 + dvd, dvdselect and subtitles plugins I sometimes get the
following
when vdr tries to set the System time.
May 31 20:23:35 localhost vdr: [3405] switching to channel 1
May 31 20:23:35 localhost vdr: [3405] timer 1 (3 2056-2210 'News') set to
event Thu 31.05.2007 21:00-22:00
29 matches
Mail list logo
