As a different way of doing it, I have a script on our Linux Broadcast machine, that runs on startup. It sets things up that are part of our normal system management (RS232-controlled video switch, for example), and then checks the time and date. If it's Sunday morning before we're scheduled to start, it launches all of those apps: X32 Edit for backup audio control (primary is on a touchscreen Pi), Firefox to monitor the stream, and OBS to produce the stream. Then it checks the time twice a minute while we rehearse. When we're supposed to start streaming, it uses `xdotool` to send the keystrokes that I set up to show the announcement loop, cue up the Welcome video, and start the stream. Then the script finally exits.
(The Macro tab might be a better way to do that now...once OBS is running...but mine was several versions and a couple of learned skills ago, and why change what already works?)
I did the startup externally because the timing features that I saw in OBS at the time were all relative, and I don't trust a relative time to survive a restart, especially if the entire OS has been shut down too.* This script uses the wall clock as an absolute time, and that's it.
* (and intentionally lost power because our USB capture cards require that to fully reset - they lose their minds after a few weeks of constant power, as if a frame counter overflows or something like that - and this motherboard doesn't allow the USB ports to use the switched power...so I have a relay, powered from the switched 12V rail, to interrupt the 5V standby and light an LED instead, and a button to bypass the relay, and the BIOS is set to always turn on after a "power failure")
Ending the stream IS done in OBS: I have an ending scene that is reserved for that purpose alone. Actually several in an automated timed series, which is defined as having been on scene X for Y minutes, then go to scene Z. Eventually, that series gets to a blank scene that I conveniently named "-------------" as a dividing line between the first 8 scenes, which are visible in the grid, and all the rest. That scene is also the trigger to stop the stream.
---
Another HUGE tip, IMO, is to use OBS's setting to automatically start and stop recording along with the stream start and stop. That way, you just keep producing regardless of what goes wrong with the internet, and you have something good to upload later. I've fallen back on that several times.
The key to that though, is to NEVER STOP OBS! Don't do anything to jeopardize that recording, regardless of what you think about the live stream. The problem is probably not with OBS anyway - it's very stable - and it's good about reconnecting when everything else becomes okay again. So there's never a need to reset OBS; keep it running so you at least have a good recording to upload later.
