Udo Richter wrote:
> C.Y.M wrote:
>> Because in the runvdr script, the vdr command is executed by an "eval"
>> which basically waits for the process to die before it continues on.
> This could be avoided by backgrounding VDR, do other stuff, and then
> 'wait' for VDR to terminante. 'wait $PID' will even return the error
> level of VDR.
Yes, I like the idea of backgrounding VDR using "&" and then using 'wait $PID'.
Is that the method you use? I've been trying to find the best way to do this.
Could you give me an example? :)
>> This is how the script makes vdr will restart automatically when it
>> crashes. I'm
>> looking for a way to have vdr execute the command so I dont have to
>> guess with
>> sleep statements.
> So you actually want to start your process some time *after* VDR started
> up, so that VDR has initialized some stuff. So for what are you waiting
> actually? Reading configuration? Loading plugins? Starting pending
> timers? Updating EPG?
For now, I'm just trying to send a MESG via svdrpsend.pl to VDR so it displays a
welcome message after starting up and initializing its plugins. But, I might
also want VDR to send me an email when it restarts. Its hard to time it
properly if I call runvdr with an init.d script and send runvdr in the
background. Since runvdr will load the drivers, call up a startup video, then
wait for vdr to initialize all its plugins before trying to send a welcome
message to the OSD via svdrpsend. The idea of 'wait $PID' sounds good, but
there would still need to be a sleep after starting vdr as a background process
(since plugins must initialize).
vdr mailing list