Udo Richter wrote:
C.Y.M wrote:
Because in the runvdr script, the vdr command is executed by an "eval" statement 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).
Best Regards.