For one audio file, add an OBS Media Source and enable Loop. For a playlist of multiple files, add a VLC Video source, choose the tracks and leave Loop Playlist enabled; VLC must be installed for that source to appear.
Those settings make audio repeat inside OBS, but they do not by themselves keep a 24/7 broadcast healthy or give you rights to stream the music. Check the source, scene, audio mix, YouTube connection and music permissions before relying on the channel overnight.
Identify the input protocol
Start by separating the audio playlist from the stream connection. A local audio file selected in OBS is not an HTTP radio station: OBS reads that file as a media source. A playlist made from local tracks is likewise a collection of files, even when you intend to broadcast the result through YouTube Live.
This distinction matters because instructions for reconnecting to a network input apply only to that input’s transport. If a separate source or FFmpeg command reads audio from a URL, identify whether it is HTTP or HTTPS, RTSP, RTP, SRT or something else before applying protocol-specific options. A setting that is documented for HTTP(S) should not be treated as a general “retry all streams” switch.
For the simplest OBS radio playlist, you do not need a network radio URL at all. Use local media you are authorised to broadcast. That removes one network input from the playback chain, though your computer, OBS, internet connection and YouTube output still need attention. If your project includes a video background, the guide to removing black bars from a 24/7 YouTube stream can help with that separate visual issue; it does not change how the audio playlist loops.
If you are troubleshooting an existing HTTP(S) audio feed instead, write down the exact URL scheme and how OBS or FFmpeg opens it. A URL beginning https:// is a useful clue, but a wrapper, playlist file or redirect can make the actual input less obvious. Confirm the final input that the receiving tool opens rather than guessing from the station’s public webpage.
Choose a source for one track or many
For a single file, the built-in Media Source is the direct choice. In the Sources dock, click +, add Media Source, select the audio file and enable Loop. OBS documents support for common local media formats including MP3, AAC, OGG and WAV, and the Loop property controls whether playback starts again when the file ends. Its documented default is off, so check the box rather than assuming the source will repeat.
For several tracks, use VLC Video. Add it from the Sources dock, then use its playlist controls to add the files. Keep Loop Playlist enabled if the list should begin again after its final file. Shuffle Playlist is off by default; leave it off for a predictable sequence, or turn it on if a changing order is part of the programme.
| Need | OBS source | What repeats | Dependency or choice |
|---|---|---|---|
| One audio file | Media Source | The selected file | Enable Loop |
| Multiple files in order | VLC Video | The playlist after its final item | VLC installed; keep Loop Playlist enabled |
| Multiple files in changing order | VLC Video | The playlist, with shuffled selection | VLC installed; choose whether Shuffle Playlist is on |
OBS says VLC must be installed before VLC Video is available. On a 64-bit OBS installation, install 64-bit VLC as well. If the source is missing, check that dependency and restart OBS before rebuilding the scene. The OBS Media Sources documentation describes the source properties and VLC requirement.
A playlist can be visible in the scene and still be inaudible to viewers. Confirm that its source is present and visible in the active scene, its audio meter moves during playback, and the audio is routed into the stream mix. The OBS sources guide explains adding sources and how their order affects what appears in the preview. For a radio channel, the source’s sound matters more than its visual rectangle, but its scene visibility behaviour can still determine whether it keeps playing.
Check FFmpeg version and available options
The HTTP(S) reconnect pattern is relevant only when the media is being opened through an FFmpeg input that supports those options. Do not add FFmpeg flags to an ordinary local-file Media Source and expect them to improve its loop behaviour. Looping a file and recovering a network input are different jobs.
Before changing a command or source configuration, identify which FFmpeg build is actually being used. OBS can bundle or use components differently across installations, and a separate FFmpeg command in a terminal may be a different version from the one involved in your OBS workflow. Check the version reported by the executable that opens the input, then inspect that version’s protocol help or documentation for the relevant HTTP options. Availability and option behaviour can differ between builds.
This check is especially useful when advice provides a command line with options that your application rejects, or when options are silently ignored because they are placed in the wrong input context. Record the command, executable path and version before changing anything. Change one thing at a time, and retain the original settings so you can roll back if the source stops opening.
Do not assume that the latest documentation precisely describes an older bundled build. Conversely, a flag shown in an example found online may not exist in the build you are running. The safe sequence is: confirm the transport, confirm the actual FFmpeg version, inspect available options for that protocol, then test the behaviour with a non-critical source.
Place reconnect options before the input
For FFmpeg command-line use, input options belong before the corresponding -i input they configure. That position tells FFmpeg to apply the options while opening that input. An option written after the input may be parsed as an output option or otherwise fail to affect the network read as intended.
A schematic HTTP(S) example might look like this:
ffmpeg -reconnect 1 -reconnect_streamed 1 -reconnect_delay_max 10 -i "https://example.invalid/radio" ...
This is a placement illustration, not a ready-made setting for every station. The example values are not guaranteed best settings, and the placeholder URL is not a working stream. Check the documentation and help for the FFmpeg build you actually use, then choose retry behaviour based on the source and the interruption you are trying to handle.
If you have more than one input, place the relevant options immediately before the -i for the HTTP(S) input they are meant to affect. Do not assume one set of options automatically applies to every input in a complex command. If the input is opened by OBS rather than a command you control, look for the application’s documented controls instead of pasting command-line syntax into an unrelated settings field.
You can also read about a different failure mode in the FFmpeg encoder overload troubleshooting guide. Reconnecting a source cannot fix an overloaded encoder: one concerns obtaining input data, the other concerns producing the outgoing stream on time.
Understand the reconnect flags
FFmpeg’s HTTP protocol options include controls for reconnecting after particular connection failures. Their names indicate separate parts of the problem; they are not a single promise that a source will always recover.
-reconnect controls whether FFmpeg reconnects when a connection is lost. -reconnect_streamed concerns reconnecting streamed inputs, for which seeking back to a prior position is not generally available. -reconnect_delay_max caps the maximum delay between retry attempts. For precise meanings, accepted values and any other relevant options, use documentation that matches your FFmpeg build and HTTP protocol handler.
Think about the failure you expect. A brief network interruption may allow a retry to succeed. A station URL that has gone offline, changed its access requirements or returned a permanent error will not be repaired by repeating the same request. A cap on the retry delay affects how long the tool waits between attempts; it does not determine whether the source will ever become available again.
There is also a difference between restarting a request and resuming the exact point in an audio programme. A live HTTP stream is not necessarily seekable, so recovery may reconnect to its current live position rather than preserve a buffer of missed material. If continuity is essential, test the source and listener experience rather than inferring it from a flag name.
Tune retry limits for the station
Treat retry settings as a policy for a particular source, not a universal recipe. The example delay cap above is included to show where the option belongs, not to recommend that number. The right balance depends on the provider’s behaviour, whether the source is live or a file download, how quickly you want retries to recur, and what your application does while audio is absent.
For a live station, retrying too aggressively can generate repeated requests without improving the underlying connection. Waiting longer can reduce request churn but leaves a longer silent gap before the next attempt. A longer cap may make sense for a source that has occasional brief outages; it may be poor fit if the provider expects clients to reconnect quickly. These are trade-offs to test against that provider’s terms and technical guidance, not values that can be settled from a generic example.
First define what a listener should hear during failure. If the source is only one layer under spoken announcements, a gap may be noticeable but recoverable. If it is the entire programme, silence is itself an incident. Decide who or what will notice an extended gap, and whether there is a fallback file or manual recovery path. A reconnect option alone does not provide monitoring or a replacement programme.
Keep a small change log: input URL type, FFmpeg version, options, time of test, and what happened after a forced brief interruption. Do not test by disrupting an important public broadcast. Use a private or scheduled test, and observe whether the source reconnects, how much audio is missed, and whether the outgoing stream stays healthy. If you also need to diagnose a YouTube-side disconnect, the guide to common MediaMTX YouTube disconnect causes covers a separate part of that chain.
Test playback, output and rights
For a local playlist, test the complete path before publishing. Start playback in OBS and listen through headphones or another monitoring route. Check that the correct scene is active, the audio meter responds, and the stream mix contains the track. Let a short playlist reach its end and confirm it starts again; if shuffle is enabled, check that the changed order is expected.
Check the source’s visibility setting as well. OBS documents VLC’s default behaviour as stopping when it is not visible and restarting when visible. If you switch between scenes, this can interrupt playback or restart the playlist. Decide whether that behaviour suits your layout and test a scene change before relying on it overnight.
Then test the YouTube connection. You need live streaming enabled on the channel; YouTube says first-time activation can take up to 24 hours. In YouTube Studio, create or select a stream, then use the server URL and stream key in OBS’s stream settings. Follow the Live Control Room prompts and check the stream health messages. YouTube recommends testing with audio and movement similar to the planned broadcast, rather than assuming a silent setup test proves the real programme works.
YouTube’s encoder guidance lists CBR bitrate encoding, AAC or MP3 audio, and a recommended two-second keyframe interval that should not exceed four seconds. These are platform recommendations, not a universal resolution or bitrate recipe: choose output settings that suit your available upload connection and the content. The official encoder stream setup guide and live encoder settings guidance are the places to check current instructions. YouTube says streams under 12 hours are automatically archived; that is not a promise that a broadcast will remain uninterrupted for that duration.
Confirm music rights separately from technical playback. YouTube scans live streams for third-party content, and it may replace a stream with a placeholder, interrupt it or terminate it if such content is identified. Even if you have a licence, the rights holder may need to add your channel to its Content ID allowlist. Check that your permission explicitly covers YouTube livestream use and ask the rights holder about allowlisting where relevant. Buying a track or having permission for another use does not establish that it is authorised for a live channel. See YouTube’s guidance on copyright issues with live streams.
Know which transports this pattern does not cover
The reconnect discussion above is specifically about FFmpeg’s HTTP(S) input options. Do not carry the same flags across to RTSP, RTP, SRT or other protocols without checking the relevant protocol documentation and the FFmpeg build in use. Similar-looking problems can have different reconnect controls, buffering rules and failure semantics.
A local OBS playlist has no HTTP input to reconnect to. If your actual job is to repeat local audio in OBS, use Media Source or VLC Video as appropriate. If your audio comes from an HTTP(S) station feed, verify that the FFmpeg HTTP handler is opening it and test those options in that context. If it is an RTSP camera, an SRT contribution feed or a different transport, find the matching documented options instead of changing a working setup based on a copied HTTP example.
Also distinguish input recovery from the outgoing YouTube connection. The input can be playing while YouTube reports a weak or disconnected broadcast, and YouTube can be receiving video while the playlist has gone silent. Watch both ends: local source audio and the Live Control Room’s stream health. For a machine that should not stay switched on all day, StreamNeo removes the need to leave your own computer running for an uploaded-file broadcast, but it does not change YouTube’s music-rights rules or make an HTTP reconnect option universal.
If your goal is a continuous radio channel rather than a test, write down the intended content schedule, source recovery plan and who will check alerts. OBS can loop media, but a 24/7 channel is a chain of separate components: files, scene behaviour, audio, encoder, internet connection, YouTube ingest and rights. A small test at each boundary makes it easier to identify where a future interruption actually begins.
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
How do I loop a playlist in OBS?
For one file, add a Media Source and enable Loop. For multiple tracks, add a VLC Video source, select the files and leave Loop Playlist enabled. VLC must be installed for VLC Video to appear.
Why is VLC Video missing from my OBS sources?
OBS requires VLC to be installed before the VLC Video source is available. If you use 64-bit OBS, OBS’s documentation says to install 64-bit VLC. Restart OBS after checking the installation.
Do HTTP reconnect flags work with RTSP or SRT?
Do not assume they do. The options discussed here are for HTTP(S) inputs; consult documentation and available options for the actual protocol and FFmpeg build you use.
Does looping a song mean it is safe to stream on YouTube?
No. Looping only controls playback. Confirm that the rights you have cover YouTube livestream use, and ask the rights holder whether your channel needs to be allowlisted for Content ID.