I use a 5 second retry, as my stream provider/CDN, faster than 5s really isn't all that useful. and I stop after 60 tries or something like that (a couple of minutes).
Is you Internet connection dedicated to streaming, or shared with your other home networking (ie streaming video service (ex Netflix, Amazon Prime Video, etc), your home computers, etc). If shared, then you have to account for TCP Reply traffic, web conference or similar traffic, etc, and then make sure your streaming/upload bandwidth doesn't get to a point of contention with your available bandwidth.
and rightnow my streams total 20-25 megabits per second 24/7 365.
That's your problem [
presuming you are on typical residential plan, not a business account with different upload limits]... you have a pipe that is 'virtually' a certain size, and you are trying to send more than that thru it... won't work.. period.
The fix, until you get more upload bandwidth from current ISP is easy... either - lower your stream bandwidth consumption, or get additional bandwidth. that's it.
I have a great router a Sonic wall TZ 400 and and I have pretty much switched everything over to CAT8 wiring now on a Cisco router so the infrastructure inside is very good I'm just at the mercy of YouTube and the Internet provider.
Side notes
- make sure that old TZ400 (which I'm familiar with) is updated, as is the Cisco... especially with the hidden malware zero-day making the news recently {last week} in some Cisco gear [may not apply to you, just don't assume you aren't at risk]
- CAT8 in residential is largely pointless. unless you are running 10gb/s?? and some (most) cheap Amazon Ethernet cables don't actually meet specs .. .so beware, unless you have really capable cable tester (ex Fluke) capable of truly stress testing cable connection and throughput [typically an expensive device].
- background - Cox, and other common typical ISPs have network designed for typical use (which is download/consumption). There is limited bandwidth, and they have to manage allocating that to upload and download streams. So, as 90+% of consumer traffic is download, their networks designed to support that. And cable (coax, DSL, etc) all are shared bandwidth at some point, fairly local to you. When pandemic lockdown hit, and everyone web conferencing from home, that bandwidth consumption model changed almost overnight and way faster than ISPs could shift, so to keep things working, upload limits put in place. [One could argue ISPs should have seen it coming, with Asian pandemics, etc, but hole other argument]
But it would be nice for obs studio to have a little bit of buffering and a little bit of leeway here and there so if the streams internet is not 100% it doesn't just drop it, and if it does that it would start up again when the Internet smoothed out I don't get why it totally just stops everything.
If my guestimate is correct, OBS (or other real-time compositing s/w) isn't going to help. what you'd need is buffering on your server provider side... which is available on pay services.... on free services... not so much. other than maybe some settings to allow higher latency (ie, I'm presuming low-latency isn't a need/requirement in your scenario...) but even that isn't really going to help beyond the seconds range, certainly not into the minutes....
Though... in pondering, would using a pay service like reastream.io, and configuring a buffer on that intermediate service work?? don't know... I'll let you research
