If you mean a playlist of media files in OBS, use a VLC Video source and check its loop and visibility settings. If you mean the YouTube watch-page playlist, OBS cannot control that queue; first restore the encoder connection and check the broadcast in YouTube Live Control Room.
These are separate jobs: OBS can reconnect its outgoing stream without restoring the media source to the same item or timestamp. Conversely, a VLC playlist can keep playing locally while YouTube is no longer receiving a feed. Check each state on its own rather than treating “playlist stopped” as one fault.
First, identify which playlist you mean
People use “playlist” for two different things in this setup. One is a sequence of files loaded into an OBS source. The other is a queue or playlist on a YouTube watch page. The first is controlled by OBS source settings; the second is part of the viewer-facing YouTube experience. The reviewed documentation does not establish that a YouTube watch-page queue resumes in a particular way after an encoder reconnect.
If you added several audio or video files to OBS and want them to play in sequence, inspect the source list in your scene. OBS documents the VLC Video source as supporting playlists. If you only added one file, you may instead be using a Media Source, which has its own looping and restart controls. The distinction matters because the same checkbox will not govern both kinds of source.
If you mean a YouTube page playlist, do not change VLC settings expecting them to repair it. Your practical task is to restore the OBS output to the intended live event, then inspect what viewers see. A reconnect does not promise that the YouTube queue, OBS source, or viewer position returns to an exact previous point. For a related explanation of source looping and broadcast continuity, see why a podcast YouTube Live stream may not loop.
Keep an OBS media playlist playing
For multiple local media files, add a VLC Video source to the scene and place the intended files in its playlist. OBS states that VLC must be installed for this source to work, and that 64-bit OBS requires 64-bit VLC. If the source is missing or fails to load files, confirm the installation and matching architecture before investigating stream settings. The OBS Media Sources guide describes the available source controls.
In the VLC source properties, check Loop Playlist if the sequence should start again after the last file. OBS documents this option as enabled by default, but inspect the actual setting rather than relying on a default that may have been changed. Looping means the list can repeat after its final item; it does not mean OBS will preserve its exact position after the source or application is restarted.
A single-file Media Source is different. Its loop control repeats that file, while Restart playback when source becomes active concerns what happens when the source becomes active again. Those controls are about local media playback, not the connection to YouTube. Do not assume that enabling restart-on-activation makes a multi-file VLC playlist resume at the previous position after a disconnect.
Test the source before starting a long stream. Add a short, harmless test sequence or use known files, confirm that the order is correct, and let the final item finish to see whether looping behaves as intended. Then switch away from the scene and back, because visibility behaviour may affect playback. Note the current item and approximate position before a test reconnect, but treat any resulting resume position as something to verify, not a feature that is guaranteed.
For channels that rotate recorded material rather than playing one continuous file, the practical considerations are similar to using multiple recorded videos in an educational YouTube stream. That question is about organising recorded segments, not about YouTube repairing an OBS source when its connection drops.
Set VLC source visibility behaviour
A source can be hidden when you change scenes, or covered by another source. In VLC Video properties, Visibility Behaviour determines what happens while the source is not visible. OBS documents options to continue playback, pause it, or stop it. Choose based on the scene workflow you want, not simply because one option sounds safer.
If the playlist should continue through a scene change, select the continue behaviour. That can be useful when the audio should not restart just because you move to a holding slide or a different visual. If you want a hidden source to stop advancing, choose the relevant pause or stop behaviour instead. The trade-off is straightforward: continuing preserves progress while hidden, while pausing or stopping changes what is playing by the time the source becomes visible again.
This setting can explain a symptom that looks like a reconnect issue. For example, if you switch to a standby scene after OBS loses connection and then return to the media scene, the VLC source may have continued, paused, or stopped according to its visibility choice. The encoder reconnect status cannot tell you which happened. Check the source preview and its properties separately.
Do not confuse source visibility with a black screen or dropped feed. Visibility behaviour only describes what the source does when it is not visible in the OBS scene. It does not control whether OBS is connected to YouTube, whether YouTube has ended the event, or how a viewer's watch-page queue behaves. OBS's Sources Guide helps distinguish sources and their role in a scene.
Enable OBS automatic reconnect
If OBS stops sending data because the connection drops, enable its automatic reconnect option in the advanced settings. This tells OBS to attempt to reconnect its output. It does not control the VLC playlist, and the YouTube documentation reviewed does not define OBS's reconnect timing or guarantee that an attempt will succeed. Keep the distinction clear: this setting addresses the outgoing encoder connection, not the media position.
Use the reconnect controls available in your installed OBS version, and avoid relying on an assumed timeout or success rate. The research-backed guidance here does not specify a universal reconnect interval. Network conditions, local machine state, and the event's status all affect what happens. If you are troubleshooting an actual overnight failure, record what OBS reports and whether the source is still playing rather than changing several settings at once.
A stream key identifies where the encoder sends its feed. YouTube says custom stream keys can be reused, so if you are reconnecting to the same event, confirm that OBS has the intended key and that the corresponding event is selected. See YouTube's official Manage live stream settings guidance for the stream key and broadcast controls. A key is not a control for playlist looping or source recovery.
For a setup that depends on one computer remaining available all night, also consider what happens if OBS itself closes or the computer restarts; automatic reconnect is not a substitute for a running encoder. The useful question is not merely “is reconnect enabled?” but “after a disconnect, is OBS still open, is the correct output selected, and does YouTube still have the event I intend to feed?”
Check the YouTube broadcast connection
In YouTube Live Control Room, check the intended broadcast and its status after OBS reconnects. YouTube's Auto-start and Auto-stop settings affect whether encoder actions can start or stop the broadcast. Read their behaviour for the event you are using before enabling them: a stopped encoder and an ended broadcast are not the same state. If the aim is to reconnect to the same event, do not manually end that broadcast as part of the recovery process.
Check that the event remains the one OBS should feed, and confirm the stream key association. If you use a reusable custom key, make sure the key in OBS matches the one selected for the event. The stream key helps route the encoder feed; it does not determine the playback position of the OBS source. If the YouTube event has ended, reconnecting OBS alone should not be treated as proof that the same broadcast has resumed.
After the encoder reports connected, inspect YouTube's incoming stream or broadcast status as well. OBS can show an output connection while the YouTube event is not in the state you expected; the reverse situation can also create confusion during recovery. Confirm that the live event is receiving the feed, then check what the viewer-facing page shows. This verifies two separate stages: OBS is sending, and YouTube is presenting the intended broadcast.
YouTube DVR is another feature that is easy to misread here. DVR lets viewers pause, rewind, and resume live playback; it is a viewer control, not an OBS playlist setting or encoder reconnect mechanism. YouTube notes that DVR may be limited or unavailable on very long streams, including streams longer than 12 hours. Consult YouTube's DVR guidance if viewer playback is the issue, but do not expect DVR to restart a local VLC source.
Compare the two recovery paths
Use the setting that belongs to the state you need to restore. A media source can keep playing even when the outgoing broadcast is disconnected, and a broadcast can reconnect while the media source is paused or sitting on a different item. The table separates the controls and their limits.
| What you mean by “playlist” or problem | Where to check | What the setting controls | What it does not establish |
|---|---|---|---|
| OBS playlist of local files | VLC Video properties | Looping the sequence and playback while hidden | Exact item or timestamp after a disconnect |
| Single local media file | Media Source properties | File looping and behaviour when the source becomes active | Whether OBS is connected to YouTube |
| OBS stopped sending to YouTube | OBS advanced settings | Automatic attempts to reconnect OBS output | That reconnect will succeed or restore source position |
| YouTube event or viewer page | Live Control Room and watch page | Event state, encoder routing, and viewer presentation | How a local OBS playlist behaves |
This separation also helps avoid unnecessary changes. If YouTube shows no incoming feed, troubleshoot OBS output, network access, stream key, and event selection before altering media loop settings. If the feed is present but the scene has stopped advancing, inspect the VLC source and visibility behaviour. For a longer comparison of an OBS loop workflow and a cloud-operated one, see how to move a YouTube loop stream from OBS to a cloud service.
Test source playback and reconnection separately
Make two small tests rather than staging a single complicated failure. First test source playback with OBS output disconnected or in a private test workflow appropriate to your channel. Confirm file order, looping, and what happens as you hide and reveal the VLC source. Write down whether the source continues, pauses, or stops; this gives you a baseline independent of YouTube.
Then test reconnect with the source already playing normally. Verify the OBS automatic reconnect setting, the correct event and stream key, and the YouTube event's Auto-start and Auto-stop behaviour. Simulate a brief connection loss only when you can do so without disrupting an important public broadcast. After OBS returns, check both the output status and YouTube's incoming feed, then inspect the media source's current item and position. Do not infer one from the other.
If you cannot safely interrupt the live channel for a test, use a separate event and a short playlist rather than experimenting during a devotional service, local news loop, or scheduled lesson. Keep notes on the OBS version, source type, selected visibility behaviour, and what each screen reported. Those details make a later diagnosis reproducible; changing several settings together makes it difficult to tell which one mattered.
For a stream that must continue while your own computer is switched off, StreamNeo removes the specific burden of keeping OBS running locally: you upload the video, provide the YouTube stream key, and the broadcast runs without leaving your machine on. It remains important to distinguish that operating arrangement from YouTube's own event controls and from any promise about a viewer's playlist position.
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
Will OBS automatic reconnect resume the same VLC playlist item?
Not necessarily. Reconnect governs OBS's attempt to restore its outgoing connection, while VLC source settings govern media playback. The official guidance reviewed does not promise restoration to an exact item or timestamp, so inspect the source after reconnecting.
Does Loop Playlist control a playlist on the YouTube watch page?
No. OBS's VLC Video Loop Playlist applies to the media list in that OBS source. It does not control a YouTube watch-page playlist or guarantee uninterrupted YouTube broadcasting.
Should I enable YouTube Auto-stop?
That depends on whether you want encoder actions to stop the broadcast. YouTube documents Auto-stop as part of the broadcast controls, so check the current Live Control Room guidance and the event's settings before using it. If your goal is to reconnect to the same event, avoid manually ending it during recovery.
Is YouTube DVR a way to keep the OBS playlist going?
No. DVR affects viewer playback, letting a viewer pause, rewind, and resume a live stream where available. It does not control OBS's local media source or repair the encoder connection.