If your YouTube radio stream uses OBS, restoring the broadcast and restoring the playlist are separate jobs. OBS’s built-in VLC Video source can loop a playlist, but its documented settings do not promise that the current item will be remembered after OBS closes and restarts; a community plugin describes that feature, but it does not promise to restore the exact position within the file.
Start by identifying what restarted: a source became visible, OBS restarted, the computer rebooted, or the encoder lost its YouTube connection. Each can leave a different part of the setup needing attention. Reconnect settings cannot restart OBS, repair a station feed or network, or restore the separate YouTube publishing connection.
What playlist recovery can and cannot do
A radio stream has several pieces of state. The playlist has an order, a current file and a playback position. OBS has a running process, scenes and sources. YouTube has an incoming encoder connection and a broadcast state. Seeing the stream return on YouTube does not prove that OBS restored the intended playlist item, and seeing a file play in OBS does not prove that the broadcast is live.
For the built-in VLC Video source, OBS documents playlist playback, loop and shuffle controls, and behaviour when the source becomes visible. It does not say that the current item is saved across a complete OBS restart. The OBS Media Sources guide is therefore a useful description of supported controls, not evidence of restart persistence.
A community resource called Media Playlist Source says it saves the currently playing file so it can play when OBS restarts. That is a source-level feature claim, not a promise that OBS itself launches after a machine reboot, that playback resumes at the exact timestamp, or that YouTube starts publishing automatically. Check the plugin’s current compatibility with your OBS version and operating system, then test it before relying on it for an unattended channel.
Keep the scope modest: you may be able to restore the current file, but the available documentation does not establish full end-to-end recovery. This distinction matters if, for example, a devotional playlist is meant to continue with the next bhajan after a scheduled maintenance restart. Decide whether resuming the same file or simply returning to a valid playlist is acceptable, and verify that behaviour rather than infer it from a successful stream reconnect.
Separate the radio source from YouTube output
In a typical OBS setup, a media source supplies the audio or video, OBS composes the scene and encodes the programme, and YouTube receives the encoder feed. Playlist settings belong to the source. Stream key and server URL belong to publishing. A YouTube broadcast’s start and stop controls govern the broadcast lifecycle. These parts can fail independently.
YouTube’s encoder setup guidance explains using the server URL and stream key to connect an encoder. Those values do not contain the current playlist file or media timestamp. Likewise, YouTube’s live stream settings page covers settings such as auto-start and auto-stop; those options do not make OBS remember a local playlist item.
For a practical diagnosis, ask three questions separately: Is the intended media playing in OBS? Is OBS sending an encoder feed to YouTube? Does Live Control Room show the expected broadcast state? A “yes” to one does not establish the other two. YouTube’s workflow may also involve a separate Go live action for a scheduled stream, so sending video from OBS alone may not complete the public broadcast.
This is why a guide to configuring FFmpeg to reconnect to YouTube Live addresses a different layer from playlist persistence. Encoder reconnection concerns the publishing connection; it cannot choose which local file a playlist source opens. Treat the two problems separately in your recovery plan.
Identify what actually restarted
A scene changing, a source becoming visible, an OBS application restart and a computer reboot are not equivalent events. If a source becomes visible again, the built-in VLC source has a documented visibility behaviour: its default is to stop when not visible and restart when visible. That can explain playback beginning again when you switch scenes, without implying that OBS remembered anything through a full application restart.
OBS documents Loop Playlist as controlling whether the source restarts after it has run out of media files. The built-in VLC source’s documented defaults are loop enabled and shuffle disabled. These settings are about what happens at the end of a playlist, not about recording the current item before the application closes. VLC must also be installed for that source to work.
Write down the event you observed before changing settings. Did the scene go hidden and visible? Did OBS disappear and reopen? Did the computer restart? Did OBS remain open while YouTube reported a disconnect? If you only know that the picture returned, check logs or the host’s restart history where available. Guessing at the cause often leads to changing loop or stream-key settings that do not address the source state.
A small test can clarify the difference. Use a short, non-critical playlist with recognisable files. Hide and show the source, then separately close and reopen OBS. Record which item plays in each case. If you intend to test machine reboot recovery, do so only when a missed broadcast is acceptable and check the operating system’s ability to launch OBS separately; the playlist source documentation does not establish that startup automation.
Choose a source that matches the recovery you need
The built-in VLC Video source may be enough when you need a straightforward ordered or shuffled list, looping, and control over what happens when the scene is hidden. Its documented controls are available within OBS, but do not treat them as a saved current-item checkpoint after the whole application restarts. If the station is a single long file or a fixed loop, decide whether returning to its start is acceptable.
The community Media Playlist Source is worth evaluating when restoring the current file after OBS restarts is important. Its resource page describes saving the currently playing file and provides a choice to play the first or current file when the source restarts. The resource listing gives a minimum OBS version and notes limitations; check the current listing for compatibility and details before installation. A version requirement can change, so do not assume an older tutorial reflects today’s support.
| Recovery question | Built-in VLC Video source | Media Playlist Source community plugin | YouTube Live Control Room |
|---|---|---|---|
| Can it play a playlist? | Yes; VLC-backed playlist controls are documented. | The resource is a media playlist source; check its current documentation for supported formats and behaviour. | No; it controls the YouTube broadcast, not local media playback. |
| Does documentation establish current-file recovery after OBS restarts? | No such promise appears in the cited OBS guide. | The resource says it saves the current file for playback after OBS restarts. | No; stream settings do not store the local playlist item. |
| Does it establish exact position within the file? | No. | No; the resource claim concerns the current file, not a precise timestamp. | No. |
| What should you verify? | VLC installation, loop/shuffle and visibility behaviour. | OBS and operating-system compatibility, limitations and restart behaviour. | Whether the encoder feed and the scheduled or live broadcast are in the expected state. |
The comparison is intentionally narrow. The documentation reviewed does not settle whether either local source continues while a scene is hidden in every configuration, nor does it verify unattended reboot recovery end to end. If hidden-scene playback matters, test the source’s visibility settings in your own scene arrangement. If returning to the exact point in a long recording matters, do not assume that “current file” means “same timestamp”.
Build a starting recovery pattern
A reliable plan is a sequence of checks, not a single magic setting. First decide what should happen after a restart: play the first file, resume the current file if supported, or start a continuous station file. Then choose the source and configure the playlist order, shuffle and loop behaviour accordingly. Keep a copy of the playlist and media files in a location the host can access after restart.
For the built-in VLC source, verify VLC is installed, add the intended files, set loop and shuffle deliberately, and review what the source does when its scene is hidden. If you use the community plugin for current-file recovery, install it only after checking compatibility, then choose the current-file behaviour it offers and run a restart test. Neither approach should be described as guaranteed timestamp recovery on the evidence available.
Next, consider the encoder as a separate stage. Open OBS, confirm the intended source is active and moving, and check that the scene’s audio meter responds. Then verify the encoder is configured for the intended YouTube stream, using the correct server URL and stream key through the normal YouTube/OBS workflow. Avoid putting keys in public notes or screenshots. A correctly playing source is not evidence that publishing is configured or connected.
Finally, check the YouTube side. In Live Control Room, confirm that the incoming feed is present and that the broadcast has the state you intend. If it is scheduled, determine whether an additional Go live action is required for that stream. Auto-start and auto-stop settings may affect broadcast behaviour, but they do not restore the local playlist item. The OBS-on-a-Mac-mini guide covers a host arrangement; regardless of hardware, do not collapse operating-system startup, OBS launch, media recovery and YouTube publishing into one assumption.
Make the test observable. Note the file that was playing before the restart, what opens afterward, whether playback begins at the start or another point, whether OBS is sending, and what Live Control Room reports. Repeat the test for the restart type you actually care about. A successful scene-visibility test says little about a computer reboot, and a successful OBS restart does not test network failure recovery.
Watch for end of playlist and source interruptions
A playlist reaching its final item is different from an HTTP source temporarily failing to return data. Loop Playlist is an end-of-media behaviour: OBS describes it as controlling whether the source restarts when it has run out of media files. If your station feed instead comes from an internet radio URL, the source is a network input, and its interruption behaviour depends on how that input is opened and handled.
This distinction matters for an FFmpeg-based station. Reconnect flags are HTTP input options for the station feed. They can influence how FFmpeg handles particular HTTP input errors or EOF conditions, depending on the option and input protocol. They do not restart the FFmpeg process, repair the station’s feed, fix your network, or restore the separate YouTube publishing connection. They also do not recreate a local playlist position that was never saved.
Do not carry an OBS playlist assumption over to an HTTP radio feed. A feed may end normally, return an error, or become unreachable; those conditions are not necessarily identical to a playlist reaching its last item. Establish which URL and protocol you are opening, inspect FFmpeg’s output for the actual failure, and consult the documentation for the options supported by the FFmpeg version and input protocol you use. The research available for this article does not specify an exact flag set or command, so a universal command line would be misleading.
For a music-video playlist in OBS, source-level looping and item persistence are the relevant controls. For an HTTP station feed in FFmpeg, input reconnection behaviour is relevant. For the outgoing YouTube stream, publishing reconnection is yet another concern. This is also why a continuous OBS playlist walkthrough is not interchangeable with configuring a radio URL as an FFmpeg input.
Handle process, network and publishing failures separately
When OBS has stopped entirely, a source setting cannot bring the application back. Recovery then depends on the computer or host starting the application and the operating system being configured appropriately. The cited source documentation does not verify a complete unattended reboot procedure, so test your own host’s startup behaviour and keep a way to inspect it. If the computer is off or the application did not launch, playlist persistence is moot.
When the application is running but the station feed is unavailable, check the source URL, the provider’s service status if available, local internet access and the error reported by the input. An HTTP reconnect option may help with a supported input-level interruption; it cannot make an unavailable source deliver audio. Repeated retries can also leave the programme without useful audio while the encoder remains connected, so monitor both the source and the output.
When the source plays but YouTube is disconnected, investigate the publishing path: encoder status, stream key/server configuration, network path and the broadcast state in Live Control Room. A playlist plugin cannot restore that connection. Conversely, if the encoder reconnects and a picture returns, check the actual file and playback position rather than assuming source recovery succeeded.
For a dependable station, prepare a simple runbook with the restart type, expected source item, steps to reopen or verify OBS, publishing checks and a fallback action if the source is unavailable. Keep the procedure specific to your setup. For example, a small shop playing a fixed ambience loop may accept restarting at the first file, while a news loop may need an operator to confirm that the latest programme file is on the playlist. A troubleshooting guide to OBS encoder overload can help when encoding load is the symptom, but overload diagnosis still does not answer whether the playlist state was restored.
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 YouTube resume the OBS playlist after a restart?
No. YouTube receives an encoder feed and manages broadcast settings; it does not store the local OBS playlist item or its playback position. Check the source in OBS and the broadcast state in Live Control Room as separate steps.
Does OBS’s built-in VLC source remember the current file after OBS restarts?
The official OBS guide documents playlist, loop, shuffle and visibility controls, but does not promise saving the current item across a full OBS restart. If current-file recovery matters, test a suitable source or the community plugin rather than inferring persistence from the loop setting.
Does the Media Playlist Source plugin resume at the exact timestamp?
Its resource description supports a claim that it saves the currently playing file so it can play after OBS restarts. It does not establish exact in-file timestamp recovery, nor does it establish that OBS launches after a machine reboot. Confirm compatibility and test the behaviour on your own setup.
Will FFmpeg reconnect flags bring the whole stream back?
No. Such flags concern handling of the input feed under supported conditions; they do not restart FFmpeg or restore the separate YouTube publishing connection. Diagnose source, process, network and publishing failures independently.