Haha thanks! I like your stream by the way.

Unfortunately I don't know much (basically anything) about Linux/Mac services, so I won't be much help for the specifics.

One thing I can say is that it probably involves this:
KillSignal=TERM

In the NodeJS library I referenced, that is the same kill-signal it had been sending to the ffmpeg process to end it (which was causing the issue).

So, you'd need to find some way to have the "stop service" command send the "gracious exit" input I mentioned ("q\r\n"), rather than the "TERM" (ie. "SIGTERM") kill-signal.

It's possible the "sudo systemctl stop StreamToYouTube" approach you're using doesn't support this, meaning you'd need to find an alternative way of sending the "gracious quit" message. (though maybe it does support it, I don't know ^_^)

No, the fix I made was in the NodeJS library that was launching (and non-graciously killing) the ffmpeg process.


This is the file I changed: https://[censored]/agsh/rtsp-ffmpeg/blob/master/lib/rtsp-ffmpeg.js


So for your case, I would look to the source code of whatever program is "killing" the ffmpeg process. If nothing (in your program) is explicitly killing the subprocess, then I guess you'll need to add a "cleanup" function that graciously ends the subprocess prior to your program overall being terminated.

I had the same issue as the posters above, and found a solution here: https://superuser.com/a/1562786/231129

Regarding the 30 second pause: It seems it differs by model. Some cameras (my C2 and alex's RLC 410 and 420) appear to have an "auto cleanup" of streams after a wait of about 30 seconds (after stream termination from the computer end), whereas for others (the cameras Steven Kan and bigger_law have), it appears there isn't such a function (thus requiring a camera reboot).

Anyway, check and see if the solution I linked to works for you. (I'm guessing it will solve at least some of other people's cases)