Oh! I must have read that wrong. Sorry! 2 minutes should be way more than enough, at least for your local machine.
I was wondering too, as I posted that, if the receiving end either:
- Rejected it for a similar reason (maybe it takes longer to wrap up a stream on that end?), or
- Considered it to be a continuation of the previous stream, and so provided the wrong feedback, which caused OBS to drop it. With a legitimate network glitch, OBS *expects* the feedback to be from the previous stream and so it gracefully restarts. But that's not what you're doing. OBS is now running a *new* stream, but the server thinks it just saw a network glitch in the old stream and continues to provide that feedback. Because the old feedback doesn't match the new attempt, OBS drops it.
But I rejected those ideas because the 2-second dead time (as I thought) seemed more pressing.
I don't want to speak too soon but I think you were on to something here... Particularly on your first point.
I have now had two, fully successful, back-to-back rotations of both the start and stop macros. Although as I mentioned earlier, I did add Caffeine and a jiggler, I'm still not convinced that a stale, sleep, or idle state was the problem.
However, I did notice some different behavior based on your suggestion to start streaming after a stopped state trigger... I set the wait interval to 2 minutes and it always takes longer than two minutes. About 4, more or less. So along with your suggestion above, I think I figured out why.
On all my tests, I simply throw up a feed for a few minutes, let the macro stop it, wait the two minutes and then the start macro fires off. Works every time I'm sitting at the computer but, not because the computer is not idle. It works because the video that I'm stopping is only, at most, 15 minutes long, for testing!!!
As you can imagine, a video that is 8 hours long is going to have to do substantially more parsing of buffers and "wrapping up" before OBS is satisfied that the stream has actually ended. This is, of course, assuming that OBS is waiting for this response (which I am not sure of but it definitely sounds reasonable). I've arrived at this conclusion because why would the START macro, which is set for two minutes, fire off in 4? The only thing that makes sense to me is that the STOP macro fires but the "stop state" isn't actually "true" until about 2 minutes after. Aaaaaand...2+2=4, as they say...literally. Makes sense to me anyway.
Anyhow, so far so good. I'll check back in in a few days to confirm all is well.
Thank you again AaronD!! I appreciate all of your time, effort and patience!
One other thing. The reason it wasn't working before and why I think there was no error, is because "technically" we were still streaming when the "start streaming" macro fired off... Would be nice if there was a log entry that said so, but hey, what would we need the obs project forums for, right?? HAHAHA!!!
github.com
