From Newsgroup: comp.os.linux.misc

As I mentioned in an earlier thread, I was making
an RTSP ip-cam recorder using Python and ffmpeg.

Was evoking ffmpeg as an independent, non-blocking,
thing using the "&" at the end of the os.system()
line (a LONG line btw, ffmpeg needs LOTS of params).

The prob was that ffmpeg didn't always terminate
exactly after "-t <secs>". The pgm would try to
start a new one while the old one was still
doing stuff. "-t" seems to be a 'preferred'
period, not super-hard.

Tried detecting over-time ffmpeg instances
and killing them by various methods. Sometimes
they die, sometimes they DON'T ... escape
various "kill" commands for awhile somehow.

The more I tried to cleverly fix this, the
bigger and more complex the code and the
less reliable it became.

So, today, went to a BLOCKING evocation of ffmpeg.
It runs for as long as it runs and then drops
through so a couple other useful things can be
done before re-evoking it.

THIS seems to work OK.

Now ffmpeg CAN hang. It's a huge collection of
utilities that, mostly, work together. Using
it on networked sources makes malfunction
more likely.

So, still remaining, write a little watchdog.
I do need this to work so a little extra daemon
is worth it. The app writes a bit to a log file
every ffmpeg cycle. So - check how old the log
file is and, if beyond a limit, kill the app.
Systemd will start it fresh in a few seconds.

The new app is much shorter/simpler. Not AS much
fine control as the non-blocking one but I can
work around that.

DID keep the posted 'AmRunning()' function, fed
sys.argv[0]. If the count is more than one then
the duplicate pgm run is prevented.

--- Synchronet 3.21b-Linux NewsLink 1.2