In OBS, enable Automatically Reconnect under Settings → Advanced, then set a starting Retry Delay and a Maximum Retries count. The delay is not a fixed gap between every attempt: OBS doubles the wait on each retry, so choose settings with that growing interval in mind.
These controls apply to the stream output connection. They do not control playlist playback or guarantee that a playlist will resume after an interruption. Check the output connection and the media source independently, including whether VLC is installed if your source uses VLC Video.
Enable automatic reconnect in OBS
Open Settings in OBS and look in Advanced for Automatically Reconnect or the automatic reconnect controls. Turn the option on, then locate Retry Delay and Maximum Retries. Labels or their precise placement can vary with OBS version and output mode, so use the controls shown in your installed version rather than relying on a screenshot made for another setup.
OBS's overview guide identifies automatic reconnect as an Advanced setting. The output reference describes the retry settings and their behaviour. These are the useful starting points if the controls are not where you expect them.
Enable reconnect before testing, but do not treat the toggle as a fix for the underlying cause. If a router loses its connection, the retry setting determines when OBS tries again; it cannot restore the router's link. If the broadcast has stopped receiving data, OBS's attempts also interact with YouTube's broadcast state. A reconnect setting is one part of recovery, not a complete recovery plan.
Make a note of your current settings before changing them. That gives you a way to return to a known configuration if a test makes the interruption behaviour harder to understand. Change one setting at a time, and record what you observe: whether OBS reports a dropped connection, whether it retries, and whether the media source continues moving.
Choose a starting delay and retry limit
Retry Delay is the initial wait before OBS's retry sequence. Maximum Retries limits how many attempts OBS will make. OBS does not prescribe one best delay or count for every stream, so decide based on the length of interruption you are willing to tolerate and how long you want OBS to keep trying before you intervene.
A shorter starting wait makes the first attempt sooner, but subsequent waits grow. A longer starting wait means more time before OBS makes its first attempt. A higher retry limit permits more attempts, but because the interval expands, it does not translate simply into a fixed total duration. Think in terms of an escalating sequence rather than a timer that repeats at equal intervals.
| Setting choice | What it changes | Useful when | Trade-off |
|---|---|---|---|
| Shorter Retry Delay | Brings the first retry sooner; later waits still double | You want an early attempt after a brief interruption | It does not make later waits fixed or repair a persistent fault |
| Longer Retry Delay | Makes the first retry wait longer | You prefer fewer immediate attempts while a transient condition settles | The first return attempt is delayed |
| Lower Maximum Retries | Limits the number of attempts | You want to notice and investigate sooner after repeated failure | OBS stops retrying sooner |
| Higher Maximum Retries | Allows more attempts | You want OBS to keep attempting recovery longer without immediate attention | The sequence may stretch out as waits double |
The table compares behaviours, not recommended numeric presets. Work from your actual operating needs: a channel watched unattended overnight may warrant leaving OBS more time to keep trying than a test broadcast where you can intervene immediately. That does not mean a high retry count makes a stream resilient by itself. If the network remains unavailable, retries can continue to fail.
For a scheduled YouTube broadcast, also review its Auto-stop setting. The OBS YouTube guide notes that disabling Auto-stop for a scheduled stream can allow reconnecting to that broadcast after an interruption. It also cautions that a broadcast may eventually end after multiple hours without incoming stream data. Check the current OBS YouTube streaming guide and the broadcast's present settings; do not assume the OBS retry count alone keeps the same YouTube broadcast open.
Understand the doubling retry interval
The first Retry Delay is the starting wait. OBS then doubles the retry time on each attempt. If the initial wait were represented as D, the waits would be D, 2D, 4D and so on; that is a description of the pattern, not a recommendation for a particular value. The important point is that later attempts can be much further apart than the first.
This matters when you interpret a long pause. An interval that feels unexpectedly long may be consistent with the configured sequence rather than proof that OBS has stopped trying. Conversely, seeing an early retry does not tell you how soon the following attempt will happen. If you need to know whether OBS is still retrying, check its status and log rather than judging from elapsed time alone.
You can estimate the broad reach of your retry sequence by noting the configured starting delay and maximum attempt count, then laying out the doubling waits. Avoid describing the result as an exact recovery deadline: a successful connection can happen at an attempt, or none may succeed while the cause persists. OBS's documentation defines the retry behaviour, but does not give a universal count or delay for every broadcaster.
For example, if a line is unstable rather than fully disconnected, the retries may coincide with brief periods when the connection returns, or they may fail repeatedly. Changing the delay can change when OBS attempts; it cannot make an unstable path stable. If failures keep recurring, investigate upload capacity, Wi-Fi conditions, other software using the connection and network hardware before simply increasing the retry limit.
Check VLC installation and the playlist source
A playlist is a media input, separate from OBS's output connection. If you have configured a VLC Video source, check that VLC is installed on the computer running OBS. VLC Video is not available just because OBS is installed; the source depends on VLC being present. If VLC is absent, the expected playlist source may not be available or may fail to play as expected.
In OBS, inspect the source itself. Confirm that the intended files are listed, that the paths point to files the computer can access, and that the correct source is visible in the scene being broadcast. A file moved, renamed or stored on an unavailable drive can interrupt playback even while OBS remains connected to YouTube. For a scheduled programme, test the actual scene and playlist rather than assuming that a source configured months ago still points to usable files.
If the source has no visible playback, first check its properties and preview. Do not start by changing Retry Delay: that setting concerns output reconnection, not missing media. Equally, if OBS reports a disconnected output while the playlist visibly advances, installing VLC or editing the playlist will not resolve the network interruption.
A playlist that contains several items also raises a separate question: what should happen when an item ends or the list reaches its end? OBS exposes loop and shuffle controls for VLC playlists, but their availability and current state should be checked in the source properties. The guide to keeping a product-demo loop running overnight with OBS is relevant when you are checking a file-based presentation, while the guide to scheduling looping playlists across channels covers a different scheduling approach.
Review loop and shuffle settings
Inspect Loop Playlist and Shuffle Playlist in the VLC Video source properties. The check matters because source defaults can affect how a list behaves after it reaches the end, but do not treat a default as a promise that the source will recover from a fault. Confirm what is selected in your own OBS version and for that specific source.
Looping and shuffling are different behaviours. Looping is intended to return to the playlist after the list finishes; shuffle changes the order in which items are selected. If you want the same sequence to repeat, check that shuffle is not altering the order you expect. If variety is more important than a predictable sequence, shuffle may be appropriate, but it can make a troubleshooting test harder to reproduce. For diagnosis, use a small, known list and keep its order clear.
Neither setting establishes that YouTube is receiving video, nor does either one reconnect the stream output. A playlist can be set to loop while the output is disconnected. A connected output can also transmit a frozen, blank or otherwise incorrect media source. Use the preview and OBS status as separate observations, then check YouTube's live view if available.
The article on stopping a looping waterfall video from freezing on YouTube Live addresses a media symptom that can look like a connection problem to viewers. It is useful to keep that distinction in mind: a frozen picture is not, by itself, evidence that OBS's retry delay is wrong.
Test playlist behaviour during an interruption
Do a controlled test when you can observe the computer and the channel. Avoid deliberately interrupting an important public broadcast without considering its audience and scheduled broadcast state. A private or otherwise suitable test stream can help you observe the two systems without confusing normal viewers, subject to the options available on your channel.
Before testing, write down the OBS retry delay and maximum retry count, the playlist source configuration, and the loop and shuffle states. Confirm that the source plays normally before any interruption. Then observe output status and playlist behaviour separately. If you test by briefly removing the network connection, you are testing the output's response to that particular interruption; you are not proving that a longer outage or another kind of failure will behave the same way.
After restoring the connection, note whether OBS attempts reconnection and whether YouTube continues or ends the broadcast. Separately note whether the playlist kept advancing, paused, or presented an error. Do not infer one result from the other. The retry sequence can affect the timing of output attempts, while source playback depends on the media and source state.
If the playlist appears to stop, inspect the source and its files after the test. If the output does not return, inspect OBS's connection status and logs, then consider whether YouTube's broadcast has ended or is no longer accepting the same stream. Repeat only after changing one relevant factor. This approach leaves you with evidence about which part failed rather than a guess based on what viewers saw.
Diagnose output and media separately
Treat the system as two paths. The output path carries encoded audio and video from OBS to YouTube over your network. The media path supplies the video and audio OBS is encoding, such as a VLC playlist. A fault on one path does not prove a fault on the other. This simple separation prevents a common waste of time: changing playlist controls when the connection is failing, or changing retry timing when the playlist has lost its files.
For output trouble, look at OBS connection status and dropped-frame indications. OBS's connection troubleshooting guide says dropped frames can indicate an unstable connection or a bitrate beyond what the connection can sustain. It recommends a wired connection where Wi-Fi is unstable and discusses lowering bitrate. Those are troubleshooting directions, not guarantees. A wired link can still have a faulty cable or a problem elsewhere between the computer and the service.
If you consider changing bitrate, use a stable upload measurement and the streaming service's requirements as context. A lower bitrate may make the stream easier for a limited connection to carry, but it can reduce picture quality. OBS also describes dynamic bitrate as a fallback that may help with dropped frames while not fixing the root cause and potentially reducing quality. Do not use it as a substitute for investigating a persistently unstable network.
For media trouble, inspect the source visibility, VLC installation, file paths, and the source's own playback state. Check whether other sources in the scene are functioning. If the output remains connected while only one source freezes or goes blank, concentrate on that source and media file. If all scene content stops reaching YouTube at the same time as OBS reports a connection failure, investigate output as well.
For a broader channel plan, the guide to setting up a 24/7 linear YouTube channel helps put playback continuity in context. If you are new to scheduled prerecorded broadcasts, see whether a new YouTube channel can run a 24/7 prerecorded livestream immediately. Those questions are distinct from OBS retry timing, but matter when planning how a channel should behave after a failure.
If the recurring burden is leaving a particular computer running just to keep a file-based broadcast alive, StreamNeo removes that specific dependency by turning an uploaded video into a YouTube live stream without your computer remaining on. It does not change what OBS reconnect controls mean or remove the need to verify the channel and media before a long run.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does Retry Delay set the time between every OBS attempt?
No. It sets the starting wait, and OBS doubles the retry time on each attempt. Later waits therefore grow rather than repeating at the initial interval.
What is the right Maximum Retries setting for an overnight stream?
There is no universal count in OBS's documentation. Choose how long you want OBS to keep attempting before you investigate, remembering that waits expand as retries proceed and that attempts cannot repair a persistent network or broadcast-state problem.
Does automatic reconnect restart my VLC playlist?
Reconnect controls output attempts, not playlist playback. Check VLC installation, the source and the playlist behaviour independently, and do not assume either looping or a successful output retry restores the other system.
Why might OBS reconnect but the YouTube broadcast still not continue?
The scheduled broadcast's Auto-stop setting and YouTube's broadcast state can affect whether the same broadcast accepts a later connection. The OBS YouTube guide notes that a broadcast may eventually end after multiple hours without incoming data, so check current official guidance and broadcast settings before relying on a recovery plan.