Re: [vdr] New shutdown procedure not working as expected

2007-08-10 Thread Stone
On 8/10/07, Udo Richter <[EMAIL PROTECTED]> wrote: > > Stone wrote: > > I noticed my vdr-1.5.6 did an emergency shutdown when I had poor signal > > reception during a recording, which in itself is a fine thing to do... > > but my "runvdr" script didn't seem to catch the bad exit code (exit 1) > > w

Re: [vdr] New shutdown procedure not working as expected

2007-08-10 Thread Udo Richter
Stone wrote: > I noticed my vdr-1.5.6 did an emergency shutdown when I had poor signal > reception during a recording, which in itself is a fine thing to do... > but my "runvdr" script didn't seem to catch the bad exit code (exit 1) > when vdr did that, so VDR never restarted. > > Does this ha

Re: [vdr] New shutdown procedure not working as expected

2007-08-09 Thread Stone
On 8/9/07, Udo Richter <[EMAIL PROTECTED]> wrote: > > Petri Helin wrote: > > Udo Richter wrote: > >> I *think* that these are kill signals received by the child process. > >> Which is strange, as the child does an exit immediately. (Unless you're > >> somewhere between 1.5.1 and 1.5.3 - this change

Re: [vdr] New shutdown procedure not working as expected

2007-08-09 Thread Udo Richter
Petri Helin wrote: > Udo Richter wrote: >> I *think* that these are kill signals received by the child process. >> Which is strange, as the child does an exit immediately. (Unless you're >> somewhere between 1.5.1 and 1.5.3 - this changed in 1.5.4) >> >> 6 is SIGABRT, 11 is SIGSEGV and 9 is SIGKI

Re: [vdr] New shutdown procedure not working as expected

2007-08-09 Thread Petri Helin
Udo Richter wrote: > Petri Helin wrote: >> Udo Richter wrote: >>> In any case, try dumping the return value to syslog, I would really like >>> to know what additional flag is set on the return value. >>> >> I got 6, 9 and 11 when I did some debugging earlier. > > I *think* that these are kill sig

Re: [vdr] New shutdown procedure not working as expected

2007-08-09 Thread Udo Richter
Petri Helin wrote: > Udo Richter wrote: >> In any case, try dumping the return value to syslog, I would really like >> to know what additional flag is set on the return value. >> > > I got 6, 9 and 11 when I did some debugging earlier. I *think* that these are kill signals received by the child

Re: [vdr] New shutdown procedure not working as expected

2007-08-08 Thread Petri Helin
Udo Richter wrote: > > In any case, try dumping the return value to syslog, I would really like > to know what additional flag is set on the return value. > I got 6, 9 and 11 when I did some debugging earlier. -Petri ___ vdr mailing list vdr@linuxt

Re: [vdr] New shutdown procedure not working as expected

2007-08-08 Thread Udo Richter
Petri Helin wrote: > It seems to me that VDR still fails writing the NextWakeupTime every now > and then, even after I made the change described earlier. Do you have > suggestions on how to shutdown properly in order to get the > NextWakeupTime written to setup.conf? I run VDR as a daemon and sh

Re: [vdr] New shutdown procedure not working as expected

2007-08-07 Thread Petri Helin
Udo Richter wrote: > Petri Helin wrote: >> I traced the problem to the SystemExec call in >> cShutdownHandler::CallShutdownCommand where Setup.NextWakeupTime is >> updated only if the SystemExec call returns 0. i changed it to accept >> all values greater or equal to 0 and now Setup.NextWakeupTi

Re: [vdr] New shutdown procedure not working as expected

2007-08-01 Thread Udo Richter
Petri Helin wrote: > I traced the problem to the SystemExec call in > cShutdownHandler::CallShutdownCommand where Setup.NextWakeupTime is > updated only if the SystemExec call returns 0. i changed it to accept > all values greater or equal to 0 and now Setup.NextWakeupTime gets > updated proper

[vdr] New shutdown procedure not working as expected

2007-08-01 Thread Petri Helin
Hi, It seems that the new shutdown procedure introduced for versions 1.5.x is (at least for me) not working as expected. The problem is that it does not recognize correctly whether VDR was started manually or not. In fact it thinks every time that it has been started manually. I traced the pro