If an internet radio stream goes silent on YouTube, first find out whether the silence begins at the station feed, your computer’s audio path, FFmpeg, or YouTube playback. FFmpeg’s HTTP reconnect options can help it resume reading a radio source after some interruptions, but they do not restart a stopped FFmpeg process or guarantee that YouTube’s separate publishing connection will recover.
The options belong before the -i for the radio URL they configure. Start with a short, observed test rather than adding every retry flag at once; the right response depends on whether the source disconnects, reports EOF, returns an HTTP error, or remains healthy while output stops.
Locate the silence before changing flags
Use the same time window to compare the source, encoder, and YouTube preview. If you can hear the station directly in a separate player while the encoder reports no audio, the fault is probably after the source fetch. If the station is silent in that player too, changing YouTube output settings is unlikely to restore it. This split avoids treating every quiet viewer as evidence of a broken radio URL.
A practical diagnostic is to note four observations: whether the source player has sound, whether FFmpeg is still running, whether its log shows input or output errors, and whether the Live Control Room preview has audio. Record the time of a brief failure. One snapshot may miss an intermittent interruption, so compare during the event rather than relying only on a later replay.
| What you observe | Likely area to inspect next | What reconnect flags can do |
|---|---|---|
| The radio URL will not play in a separate player | Station URL, access, redirect, or source availability | May retry certain transient HTTP failures; cannot correct a bad URL or credentials |
| Source plays, but the encoder has no input activity or audio | FFmpeg input configuration or local routing, depending on how audio is captured | HTTP input options help only when FFmpeg itself reads the radio URL |
| FFmpeg exits | Process or command failure | Cannot revive a process that has stopped |
| Encoder continues sending, but YouTube reports a destination problem | YouTube ingest, key, network, or event configuration | Input reconnect settings do not repair the publishing side |
| Control Room preview has audio, but one viewer hears silence | Viewer device, browser, app, or local playback path | Usually not the first place to change source retry settings |
The distinctions matter when choosing a recovery method. A continuous HTTP source read, the FFmpeg process, the local network, and YouTube ingest are separate layers. For a related example of how input and output errors differ, see FFmpeg reconnect errors in a continuous YouTube stream. That page addresses another use case, but the useful habit is the same: read the error in context instead of assuming the word “reconnect” identifies the failed side.
Check the radio source on its own
Play the exact station URL used by FFmpeg in a separate player, if the station permits direct playback. Confirm that it is a stream URL rather than a web page or a playlist landing page. Some stations publish redirects, require a particular access method, or change endpoints; the title alone does not identify the station’s format or access rules. Do not assume a command tested against one station will work unchanged with another.
If playback fails, note whether the error is repeatable and whether FFmpeg logs an HTTP status or a connection error. An HTTP client error such as an access or authentication failure calls for checking the URL and station requirements, not repeatedly retrying a request the station is rejecting. A temporary server-side response may be retryable, but retries cannot make an unavailable station available. Keep any credentials embedded in a URL private, and avoid pasting them into public logs or support posts.
If the source is a playlist file rather than a direct audio stream, verify what it points to and which URL FFmpeg actually opens. Redirects and changing stream endpoints can make a copied address appear to work in one player and fail in a different command. Use FFmpeg’s verbose log to identify the request and response where possible; do not publish a log containing a private token or stream key.
For an FFmpeg build that reads the radio over HTTP, the following is a starting pattern for an endless source:
ffmpeg \
-reconnect 1 \
-reconnect_at_eof 1 \
-reconnect_streamed 1 \
-reconnect_delay_max 30 \
-i "$RADIO_URL" \
...output options... \
"$YOUTUBE_RTMP_URL/$YOUTUBE_STREAM_KEY"
This is an illustrative command, not a verified recipe for a particular station, format, or FFmpeg build. Replace the placeholders with the radio source and the ingest address and key for the specific YouTube event. Keep the key private: YouTube describes a stream key as the information an encoder uses to send a feed to the correct event. See YouTube’s instructions for managing live stream settings.
FFmpeg documents the HTTP protocol options in its official protocol documentation. Check the options available in the installed build with ffmpeg -h protocol=http; build configuration and version affect what is supported. Protocol options for the input go before the matching -i. If placed after it, they may be interpreted as output options rather than configuring the radio request.
Understand what each retry option covers
-reconnect 1 enables reconnection after a disconnect before EOF. -reconnect_at_eof 1 treats EOF as an error and attempts to reconnect; FFmpeg identifies this as useful for live or endless streams. That is relevant when a radio feed is expected to continue but closes or signals EOF during a temporary interruption. -reconnect_streamed 1 permits reconnect attempts for streamed, non-seekable inputs, which is a common shape for continuous radio audio.
These switches do not make every failure recoverable. They influence FFmpeg’s reading of the HTTP input. If the request is rejected because the URL, access, or authentication is wrong, more retries may simply repeat the same failed request. If the station has ended the broadcast, there may be nothing to reconnect to. Read the log’s timing and error messages alongside the station’s own status rather than interpreting each retry as progress.
Use additional options only when the observed failure matches them and the local build supports them. -reconnect_on_network_error 1 covers TCP or TLS errors during connection establishment. -reconnect_on_http_error 503,5xx selects HTTP responses that should trigger retries; the documentation also permits status classes such as 4xx or 5xx. Avoid retrying all client errors by default, because a malformed request or access problem generally needs correction, not a longer wait.
-respect_retry_after 1 honours a server’s Retry-After header when it is present, which FFmpeg documents as useful with responses such as 429 and 503. It does not mean a server will always provide that header. Option availability and retry behaviour are version-sensitive, so check the local help output and official documentation before relying on a flag in a long-running channel.
The delay limit is an operational choice, not a universal reliability setting. -reconnect_delay_max 30 in the example bounds the maximum delay in seconds between retries; the appropriate bound depends on how long silence is acceptable and how the station behaves. Current FFmpeg documentation also describes retry-count and total-delay limits. Choose limits that let you detect a persistent fault rather than leaving an unattended process in an unclear state indefinitely.
Check the operating-system audio route
The radio source may be healthy while the sound route used by an encoder is not. This check matters when your workflow plays radio in one application and captures system or device audio in another. Confirm that the expected output device is selected, is not muted, and is still connected. If a system update, device change, or remote login altered the default output, the player may continue while the capture source receives silence.
Do not make this check a reason to install a new audio device before isolating the cause. First compare the station in its player with the encoder’s selected source and meter. If FFmpeg reads the HTTP URL directly, desktop speaker routing may not be part of that path at all. In that case, changing operating-system output settings is unlikely to affect the input being read by FFmpeg.
For a capture-based workflow, use a brief test recording or local monitor, if available, to verify what the chosen capture source actually receives. Check application-specific permissions and device selection as well as the system default. A meter that moves proves signal is reaching that point; it does not prove that the right signal is being sent to the encoder or that YouTube receives it.
Inspect the encoder input, process, and meters
Work out whether the encoder is reading the station URL itself or receiving audio from another application. Those are different configurations. If FFmpeg fetches the HTTP stream, look for input connection messages, timestamps, and errors in its log. If another programme supplies audio, check its selected source and the encoder’s capture input instead. Do not assume OBS is in use: an FFmpeg command, another encoder, or a hosted workflow may be involved.
For FFmpeg, determine whether the process is still running when sound disappears. A process that has exited cannot act on input retry flags. A separate service manager or process supervisor can restart a failed process, but that is another recovery layer and needs its own configuration and monitoring. Do not confuse a process restart with an HTTP reconnect; the former reruns the command, while the latter keeps a running command trying to read its source.
Check whether audio packets or meter activity continue after the suspected interruption. If input audio stops but the process remains alive, investigate source logs and the HTTP options. If input continues but output activity stops, inspect the output mapping, codecs, and destination errors. The output command must include an audio stream in a format accepted by the chosen YouTube ingest workflow. If the channel uses a still image, that visual output is a separate part of the command: reconnect flags do not create or repair it.
YouTube’s live encoder settings guidance covers ingest and encoder requirements. Apply those settings to the output path independently of radio input retries. For an audio-led channel with a static visual, check that the output has both the intended audio and a suitable video stream; a source-reconnect option says nothing about either output mapping or whether the visual is present. If you are configuring an audio playlist, the article on FFmpeg audio bitrate for a continuous YouTube stream can help with a related output decision, but it does not replace checking the current event’s settings.
Read YouTube Live Control Room messages
Open the event’s Live Control Room and look at the preview, stream health, and messages at the time of the interruption. A healthy preview with audible sound points away from the radio input and towards the individual viewer’s playback path. A destination warning, missing feed, or interruption while FFmpeg still reads the source suggests a publishing-side issue. YouTube recommends testing before a live event and monitoring stream health and messages while it runs; use its encoder and live streaming guidance as the current reference.
Check the event’s selected stream key and ingest settings if the output is not arriving. YouTube stream keys are destination credentials, not radio-source credentials. Keep them private and verify that the command’s destination corresponds to the intended event. A source-side reconnect does not renew a key, choose the right event, or correct an output address.
Also consider outbound network capacity. YouTube’s streaming tips recommend leaving room between the stream’s total bitrate and available outbound bandwidth, and warn that connectivity disruption can break a stream. This is a publishing-path check, not a reason to alter the radio URL. If the output is video plus audio, account for the total sent bitrate rather than considering audio alone. YouTube’s recommendations are configuration guidance, not a promise that a connection will remain stable.
A useful way to separate the layers is to compare them directly: if FFmpeg’s source read fails, inspect HTTP input and station response; if FFmpeg exits, address process supervision; if it reads successfully but YouTube loses the feed, investigate the output connection, event, key, and available bandwidth. These layers can fail together, but solving one does not automatically solve the others. The article on YouTube stream keys expiring in OBS on Windows is relevant when the issue is specifically a key or encoder setup, rather than a station read failure.
Test the viewer-side playback path
Before editing the command, check whether silence is present in the Control Room preview and in a second viewer device or browser. Confirm that the viewer has not muted the player, selected a different audio output, or lowered the device volume. If the preview has sound but one phone does not, a change to FFmpeg’s HTTP input retries is unlikely to help that listener.
If multiple viewers report silence while the Control Room preview remains audible, compare the same moment across devices and note whether the issue is limited to a particular app, browser, or connection. A replay can help establish whether sound was encoded, although it may not capture every live playback condition. Keep the time and observations; they help distinguish a source gap from a viewer-specific fault without guessing.
Retest one change at a time
Use a controlled test before relying on revised options overnight. Keep the same source, event, and output settings while changing one input retry behaviour. Observe whether the source resumes, whether the FFmpeg process remains running, whether output continues, and what the Control Room reports. If you change the source URL, multiple flags, audio mapping, and destination together, a successful retest will not show which change mattered.
For an endless HTTP feed, a reasonable initial test is the four-option pattern above, provided the local build supports it and the source is actually read over HTTP. If logs show a connection-establishment error, consider the network-error option. If they show a retry-worthy server status, select that status deliberately rather than broadening retries to every response. If the log shows a client error, first verify the request and station access. Retest with the exact station and event intended for production.
Decide how long silence is tolerable and what should happen when retries stop. A bounded delay helps define the wait between attempts; retry count or total-duration limits, where available, define when the command should stop trying. An external monitor or supervisor may be needed for a process that exits, but it should not repeatedly conceal a permanent bad URL or rejected request. Document the last known-good command and keep the key out of that record.
For overnight operation, test more than the start of the stream. Confirm that the source is still being read after an interruption, the encoder is still publishing, and YouTube continues to show a healthy feed. No reconnect option guarantees recovery from a station outage, local network loss, a stopped process, or YouTube ingest failure. For a devotional channel workflow, see how to keep a Gurbani YouTube live stream running overnight for broader continuity checks beyond the HTTP source itself.
When the source, command, and event are ready, choose how you want to keep the channel running based on the failure layer you need to manage.
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 reconnect_at_eof restart an FFmpeg command that has exited?
No. It changes how FFmpeg handles EOF while it is reading the input. If the process has stopped, a separate supervisor or service manager would need to launch it again.
Should I use reconnect_on_http_error 4xx for a radio station?
Not by default. Many client errors indicate that the request, access, or authentication needs correction, so repeating it may not help. Check the station’s response and only configure retries for statuses that can plausibly be temporary.
Will FFmpeg reconnect options fix a YouTube disconnect?
They apply to FFmpeg’s HTTP input when reading the radio source, not the separate publishing connection to YouTube. Check the output log, event key and ingest settings, network, and Live Control Room messages for a destination problem.
Do these flags work with every FFmpeg build and radio URL?
Option support depends on the installed build and version, and station URLs can have different formats or access requirements. Check ffmpeg -h protocol=http and test the exact source and event before depending on a command for a continuous channel.