What Twitch writes about the cap.
The Broadcast Guidelines page states the ceiling in three sentences. It is a hard number, not a setting in the dashboard.
The third sentence is the one worth reading twice. Twitch declines to describe what happens next, and points at the encoder instead.
So the reconnection is the streamer's problem, by Twitch's own wording. Nothing on that page promises a broadcast resumes on its own.
What happens when the cap hits.
Four things are observable from outside, and only four. Everything else about Twitch's internals is guesswork, so this guide skips it.
The broadcast ends. The channel goes offline in the directory, and viewers on the page get the offline screen instead of video.
The past broadcast stops where the session stopped. A VOD that was mid-file when the cap hit is cut at that point, not at the end of the content.
Reconnecting starts a new broadcast. The go-live notification fires again, which followers see as a second alert for a channel that never really stopped.
- The stream ends at the cap, wherever the playback happens to be.
- Viewers see the offline screen, and the channel leaves the live directory.
- The past broadcast is cut at the moment of the disconnect.
- A reconnect is a new broadcast, so the go-live notification fires again.
Why reconnecting on failure is not enough.
The obvious plan is to let the cap hit and restart the encoder. It works for one machine streaming a game. It does not work for a channel that replays an archive.
The cut lands mid-VOD. A viewer who arrived twenty minutes ago loses the rest of the file, and the archived copy of that broadcast ends mid-sentence.
Between the cut and the reconnect, the channel is black. A restart that takes thirty seconds is thirty seconds of nothing, at whatever hour it happens.
The channel also leaves the directory during that gap. Being listed while offline is the whole point of running 24/7, and the gap gives it back.
Then there is the chat. If a vote for the next VOD is open when the encoder dies, the bot announces a result for a broadcast that no longer exists.
- A cut lands inside a file, so the VOD is truncated and the viewer loses the ending.
- The screen is black for as long as the restart takes.
- The channel drops out of the live directory during the gap.
- A vote in progress resolves against a stream that has already ended.
Plan the reconnection instead.
The fix is to stop treating the reconnection as a failure. Pick the moment yourself, far below the cap, at a boundary you control.
The boundary is the gap between two files. Playback is a queue, so there is a point every few hours where nothing is mid-frame.
The rule is one comparison, made before starting each item. Recycle now if the session age, plus the next item's duration, plus a margin, would pass the budget.
The budget in VOD247 defaults to 12 hours, well under the 48-hour cap. The margin absorbs the recycle itself and any clock drift.
There is one deliberate exception. If a single item is longer than the whole budget, recycling before it buys nothing, so it plays and the session overshoots.
That exception is a choice: overshooting a soft 12-hour budget is cheap, and cutting a VOD in half is not. The hard cap stays far away either way.
The reference channel zerator_247 was observed running sessions of about 12.7 hours. That is the shape a planned recycle produces.
- Compare before each item: session age + next duration + margin > budget.
- Budget defaults to 12 hours, against a 48-hour Twitch cap.
- Recycle only at a boundary between two files, never mid-file.
- An item longer than the budget plays anyway, and the session overshoots on purpose.
What viewers see.
A planned recycle is a stop and an immediate restart of the same publish session. In practice it costs a few seconds of player buffering.
In practice Twitch treats a fast reconnect as a continuation of the same broadcast. Twitch does not document that behaviour, and its own page says it depends on the encoder.
So the honest way to plan is to assume the reconnect may be visible. Putting it between two VODs means the worst case is a few seconds of black between files.
What the chat bot does.
The vote cycle has to survive the recycle, and the way to make it survive is to key it on the VOD rather than on the connection.
In VOD247 the cycle is keyed on the item on air. Requests open 20 minutes before its end, the poll opens at 10 and closes at 5.
The session underneath can be recycled without touching any of that. The bot never announces a result for a broadcast that ended under it.
Doing it by hand with ffmpeg.
A cron job that restarts OBS every twelve hours does not solve this. It fires on the clock, so it lands mid-file, which is the exact problem being avoided.
What is needed is a restart that knows the playlist. The script has to wait for the current file to finish, then decide, then restart before the next one starts.
The steps below are the minimum. They are written for an ffmpeg publisher, because OBS has no clean way to ask when a media source ends.
Two details cost time when they are missed. Timestamps have to stay continuous across files, and the vote bot has to be told the session changed.
- Track when the current publish session opened, in seconds, and keep it across restarts.
- Probe the next file with ffprobe before playing it, and read its duration.
- Apply the comparison: session age + duration + margin against your budget.
- If it passes, close the RTMP connection and open a new one before starting the file.
- Offset each file timestamps by the cumulative duration already played, so the muxer stays monotonic.
- Tell the chat bot the session changed, and let any open vote keep running on the VOD clock.
- Log every recycle with the session age, so a session that never recycles is visible.
The checklist.
Run this list against whatever is publishing your channel today. Anything unchecked is a cut waiting for an hour when nobody is watching the dashboard.
- Your budget is well under 48 hours, and written down somewhere.
- The restart happens at a file boundary, decided per item, not on a clock.
- The next file duration is known before the decision, not guessed.
- Timestamps are continuous across files, so the player does not stall on a jump.
- A file longer than the budget has a defined behaviour, and it is not a mid-file cut.
- The vote cycle is keyed on the VOD on air, not on the connection.
- Every recycle is logged, with the session age at the moment it fired.