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.
