An internet outage does not have one fix for a sleep-sounds stream: recovery depends on whether the break is between your source and relay, between the relay and listeners, or on a listener’s own connection. Configure the source to reconnect, keep a local backup ready, and make the player retry after connectivity returns.
There is a hard limit: if a listener has no internet, the server cannot send them fresh audio. Only audio already buffered by the player or a copy available on the listener’s device can play during that period.
Map the route from sound to listener
Think of the stream as three links. First, a generator plays or encodes the sleep audio. That could be a computer running an encoder, an automated playlist, or a cloud-based stream service. Second, a relay receives the source and distributes it to listeners. Third, each listener’s player fetches the stream over their own connection and turns it into sound.
A failure at each point looks different. If the generator loses its route to the relay, the live feed may stop arriving even though the relay is online. If the relay is down or cannot deliver data, the source may still be sending but listeners cannot receive it. If one listener loses connectivity, other listeners can continue listening normally. You need to identify the broken link before changing settings.
For a YouTube channel, distinguish the system producing the live feed from YouTube’s delivery to viewers. A computer or service may keep sending to YouTube while one viewer has a weak connection; restarting the channel’s source would not fix that viewer’s home Wi-Fi. Conversely, a source that has disconnected from YouTube needs source-side recovery, not a browser reload by the viewer.
This distinction also helps if you are deciding whether to run the source on your own computer. A computer-based setup makes the machine and its network part of the first link; the trade-offs are covered in how to keep a YouTube radio stream running when your computer is off. Whichever arrangement you use, write down what is generating the audio, where it sends the feed, and how you will check the listener-facing result.
Find the link that failed
Start with the smallest useful question: is the problem visible to everyone or only one listener? Check the channel’s public playback from a second device or a separate network, and check the source process and relay status. A single listener reporting silence points first towards that listener’s connection or player. Silence for multiple listeners while the source is still active points towards the relay or onward delivery. A stopped source or a source-client error points towards the generator-to-relay link.
Use evidence, not just a thumbnail that still says “Live”. A platform can show that a broadcast session exists without proving that fresh audio is reaching it. Check whether the audio meter or encoder output is moving, whether the source client reports a connected state, and whether a listener can hear new sound rather than a player that has stopped advancing. If your encoder has logs, note the time of a disconnect and whether it reports a new connection attempt.
| What you observe | Likely area to check first | Useful next check |
|---|---|---|
| Source reports a closed or failed connection; listeners lose the stream | Generator to relay | Inspect source-client logs and reconnect behaviour |
| Source appears connected, but several listeners cannot load the stream | Relay or onward delivery | Check relay status and test playback from another network |
| One listener sees a loading or error state while others hear audio | Listener connection or player | Restore that connection, then retry the player |
| Player says live but the sound does not advance | Source, relay or stalled player | Compare another listener and inspect the player’s media state |
These observations narrow the search; they do not prove a cause by themselves. A mobile connection can recover while you are testing, and a browser may retain a partial buffer after the live feed has failed. Record the time, device, player and what changed before restarting anything. That gives you a useful comparison the next time the same failure appears.
If your stream is generated with OBS, transmission settings are one part of the source-to-platform path, but a bitrate adjustment cannot restore a lost internet route. Keep OBS bitrate settings for a 24/7 ambience stream as a reference for a different class of problem: choosing a transmission rate that fits the available connection.
Make the source reconnect
The source must be able to make a new connection after the network or relay returns, and the process that runs the source must remain alive. A reconnect setting is no help if the computer has gone to sleep, the encoder has quit, or an operator has stopped the streaming script. Check power settings, scheduled maintenance and any watchdog or process supervision you already use, then test the full recovery path rather than assuming a checkbox covers it.
The exact settings depend on the client. Liquidsoap’s development documentation for version 2.5.x says its Icecast output retries a failed or closed connection after three seconds by default and continues retrying while the script keeps running. The same documentation lists a five-second default for connection establishment waiting and a 30-second default for read/write waiting. These are documented defaults for that version, not universal values or a guarantee that every source client behaves the same way. Check the documentation for your deployed version before changing a configuration.
Liquidsoap exposes connection, disconnection and error callbacks, which can help you log state changes or choose what happens after an error. If your software offers a retry limit, understand what happens when that limit is reached. The Icecast project’s Ices 2 documentation, for example, describes separate reconnect settings including reconnectdelay, reconnectattempts and retry-initial; those belong to Ices 2, not Liquidsoap. A finite attempt cap can end unattended recovery if it is reached before connectivity returns.
For a practical test, interrupt the source’s network briefly while keeping the source process running. Confirm that the client reports a disconnect, attempts a fresh connection and resumes sending once the route is available. Then inspect what listeners actually hear. Do this in a planned maintenance window, not during a quiet overnight period when you may not be watching. If you rely on a laptop or desktop, test what happens after a restart as well as after a short network interruption.
If the generator is a scheduled video file rather than a radio client, the same separation still applies: the file can be ready while the process transmitting it is disconnected. Keep a note of whether a recovery requires a new source connection, a resumed encoder, or a fresh live session. YouTube’s current Live Control Room guidance is the place to verify how the platform presents and manages a live broadcast; do not infer platform state solely from the source application’s status.
Keep a local fallback source ready
A source can reconnect correctly and still have nothing useful to send if its main sleep-audio file or playlist has become unavailable. Keep a locally accessible ambient loop or prepared backup playlist that can be selected when the primary source fails. Choose audio you have the right to use, and make sure it is present on the machine or system that needs to play it; a backup stored only on a disconnected network drive is not an effective local fallback.
Liquidsoap’s quickstart describes mksafe as making an unavailable source produce silence, and fallback as switching to another always-available source. Silence can be a valid safe state in some broadcasts, but it is usually a poor sleep-sounds contingency if the aim is to keep a quiet sound bed available. A backup file or playlist is a more relevant choice. This is an application of the documented operators, not a claim that any particular configuration is tested for your setup.
| Recovery choice | What it can protect | Main limitation |
|---|---|---|
| Retry the source connection | Source-to-relay link | Needs the source process and route to remain available |
| Switch to a local backup loop | Audio availability at the generator | Does not fix relay failure or listener-side loss of internet |
| Substitute silence | Keeps an output source available | Listeners hear silence rather than sleep audio |
| Keep a copy on the listener’s device | Playback during that listener’s offline period | It is no longer fresh live audio |
A fallback should be short and familiar enough not to jar someone who is trying to sleep. Avoid a sudden loud intro, an advert, or a track with a sharp change in level. If you use a playlist, check that it actually loops and does not reach an empty end state. The OBS replay and playlist settings guide can help if OBS is the component managing your playback order.
A local fallback only helps while the generator can still reach the relay. If the listener has lost their own internet access, switching upstream audio cannot bring the stream through a missing connection. StreamNeo can remove the specific burden of keeping your own computer on to send an uploaded video as a YouTube live stream, but it cannot provide fresh playback to a viewer whose connection to the internet is down.
Detect a stalled browser player
A browser player should distinguish a temporary wait for data from a media resource error and from a total network loss. Native media elements expose events such as stalled, waiting and error: broadly, fetching has stopped, playback is waiting for more data, or the resource has encountered an error. Apple’s HTMLMediaElement documentation and MDN’s media error event reference describe the browser-facing events and state you can use for diagnosis.
If you maintain a custom player, use those events to show a clear status rather than leaving a spinning indicator indefinitely. A player can display “Waiting for connection” while the browser reports that the media is waiting, then offer a retry when connectivity appears to return. Avoid treating one event as proof that the whole stream is down: a short pause can be normal while data arrives, and a player may be waiting because the listener’s connection is weak.
A stalled or error event can trigger a measured recovery path: report the state, wait briefly, check whether the browser is online, then try loading the media resource again. MDN documents HTMLMediaElement.load() as resetting the element and beginning source selection and loading again; it also aborts ongoing operations. That makes it a way to start a fresh load, not a promise that audio will resume automatically in every browser. The player should handle a failed attempt and tell the listener what to do next.
Playback may also need a user action. Browser autoplay restrictions can prevent audio from starting even after media is ready, so show a play control if the automatic request is rejected. If you use Media Source Extensions rather than a simple media URL, your application is responsible for fetching segments and maintaining its media pipeline; you need recovery for failed segment requests as well as the player element. Without knowing your player architecture, a generic code recipe would be misleading.
Retry after the connection returns
For a listener, recovery should begin after their connection is back, not by repeatedly refreshing while the device is still offline. A simple player can wait for connectivity to return, retry loading the source and then request playback when media is ready. An operator can tell listeners to refresh the player once they are back online if the player has no automatic retry logic. Make the instruction specific: reconnect to the internet first, then reload the stream page or press its play button.
For an operator, verify each step in order. Is the source process still running? Has it reconnected to the relay? Is there fresh audio at the relay or platform? Can a separate listener load it? If the source client has stopped rather than merely disconnected, restarting that process may be necessary; if the relay is unreachable, repeatedly restarting the source may not help. This sequence prevents a listener-side symptom from prompting an unnecessary change to the broadcast.
A reload starts media selection and loading again, but it does not necessarily restore the same point in the stream or guarantee a sound output. The player may need a user gesture, and a live stream may simply resume at its current point rather than replaying the interval that was missed. Explain this in listener-facing status text so a person does not mistake a newly playing stream for a recording of the gap.
If the outage is a weak rather than absent connection, segmented delivery may be an architectural option. Liquidsoap can produce HLS files for a web server, and the Liquidsoap book describes HLS and DASH as rolling playlists of segments with adaptive variants that may switch to a lower bitrate as conditions change. That can help when bandwidth degrades, but it adds delivery and player responsibilities and does not fix a completely absent listener connection. Choose it only if you already have a reason to operate segmented delivery; it is not a universal repair switch.
What listeners can hear while offline
If a listener’s internet is completely unavailable, they cannot receive new live audio from a remote server. A buffer may keep playing the part already downloaded, but only for the duration of that buffer; once it is exhausted, playback stops or waits. The relay may be healthy, the source may be sending perfectly, and other people may be listening, but none of that creates a path into an offline device.
For a longer offline period, the robust option is a local copy of suitable audio on the listener’s device, if the listener has a legitimate way to obtain and store it. That copy can play without the live service, but it is not the current live stream. If you publish a sleep-sounds stream for an audience that may have unstable mobile service, say plainly that they can save an appropriate offline track where your rights and distribution setup allow it; do not imply that buffering or server-side fallback removes the need for connectivity.
This boundary is useful when answering support messages. Ask whether the listener can open another site or play other audio on the same connection. If not, suggest checking Wi-Fi or mobile data and trying again once service returns. If other audio works but your player remains stuck, ask them to reload the player or use its retry control, then use their report to investigate whether the issue is local to that device or shared across listeners.
If you are planning a broadcast around power or connectivity interruptions at the source, keep that separate from audience-side offline behaviour. Planning a devotional stream during power cuts in India covers the operator’s continuity problem; it cannot change what a listener’s own disconnected phone can receive.
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 my sleep-sounds stream keep playing if a listener loses all internet?
No. The server cannot deliver fresh audio to a device with no internet route. Playback can continue only while the player has buffered audio or if the listener has an offline copy available locally.
Should I restart the stream as soon as I see a player error?
Not necessarily. First check whether the issue affects one listener or several, and whether the source is still connected to its relay. A browser error may be confined to that player; restarting the source will not repair a listener’s disconnected Wi-Fi.
Does reloading a browser player guarantee that sound starts again?
No. Reloading the media element begins source selection and loading again, but it does not guarantee successful playback in every browser. The player may still need a restored connection, a ready media resource, or a user gesture to start audio.
Is a local fallback the same as offline listening?
No. A local fallback at the generator can keep audio available to a relay when the primary source fails, provided the generator can still reach it. Offline listening means audio is already on the listener’s device or buffered there; upstream fallback cannot cross a broken listener connection.