To connect LibreTime automation to a 24/7 YouTube radio stream, send its scheduled audio playout to Icecast, then use a separate audio-to-video encoder or relay to deliver a YouTube Live broadcast. LibreTime’s documented outputs and YouTube’s encoder ingest instructions describe the two ends; the relay between them is an architectural synthesis, not an officially certified or tested end-to-end bridge.
That distinction matters when you plan support and recovery. Treat LibreTime, Icecast, the relay and YouTube as separate parts of a chain, each with its own settings and failure modes. The following guide maps a cautious route through them without implying that a particular script or product is endorsed.
Review LibreTime’s scheduled playout outputs
Start by confirming what LibreTime is scheduled to play and which output you intend to expose. LibreTime documents Icecast and SHOUTcast outputs; for this design, Icecast is the hand-off point between the radio playout system and the separate YouTube encoder. Consult the LibreTime configuration reference for the current settings and terminology in your installation, as documentation and configuration can change.
In LibreTime, identify the Icecast output and record its host, port, mount, audio format and credentials. The values must match the Icecast server and the listener URL the relay will use. Avoid assuming the stream is reachable just because scheduled shows are visible in the LibreTime interface: confirm that the configured output is actually publishing audio.
LibreTime’s configuration reference describes support for up to three Icecast outputs and audio formats including AAC, MP3, Ogg and Opus. If you need more than two outputs to the same Icecast server, its documentation says to raise the Icecast source limit. Check the current instructions before changing that limit; do not copy a setting from an unrelated installation without understanding what it controls.
Think through the schedule as well as the connection. If your station alternates recorded shows with live input, determine what LibreTime should play when a live source is absent and how that changes the public Icecast output. Your listeners may hear a scheduled fallback correctly while the separate YouTube relay has already lost its source, so the two continuity questions need separate answers.
Before moving on, write down a simple source record: expected show or fallback, the Icecast mount, format and a way to tell whether audio is present. This gives you a baseline when testing the next link. If your wider setup involves rotating content across more than one channel, the considerations in playlist rotation across YouTube channels may help distinguish channel scheduling from the single-channel audio path described here.
Route playout through Icecast
Icecast is the public audio stream in this architecture. LibreTime publishes its output to an Icecast source; a listener, in this case the relay, reads the resulting mount. Keep the source URL, authentication details and mount name together in your operations notes, but do not expose credentials in public documentation or screenshots.
Check the Icecast side using a private listener or a player that can open the mount. Listen across a schedule boundary if possible, including a transition between a scheduled item and any live or fallback source. The purpose is not to certify the whole stream; it is to isolate whether LibreTime is producing continuous, intelligible audio before the YouTube encoder is involved.
If you use fallback mounts to move listeners between sources, regard those as part of the radio chain. LibreTime’s Icecast-related documentation describes fallback concepts, but a working fallback for a listener does not automatically make the relay resilient. Verify the exact mount that the relay reads and what it receives when the primary source changes or disappears.
Audio format is an early compatibility decision. LibreTime’s output options include several formats, while YouTube’s encoder guidance lists AAC or MP3 audio for RTMP/RTMPS ingest. The relay may need to decode and re-encode rather than pass the source through unchanged. Select settings based on compatibility and your available bandwidth, then check sound quality and resource use during a real test rather than assuming all formats are interchangeable.
Add a separate audio-to-video encoder or relay
The relay is the bridge from an audio-only radio stream to YouTube Live. It needs to read the Icecast audio, prepare audio in a format the YouTube ingest path accepts, and provide video if you want a visual presentation. That visual could be a static station image or another appropriate visual source, but the specific implementation depends on the encoder you choose.
The cited LibreTime and YouTube documentation describe Icecast/SHOUTcast output on one side and encoder ingestion on the other. They do not provide or certify one specific LibreTime-to-YouTube bridge, and this guide has not tested an end-to-end configuration. Treat any relay software, script or hosted service you encounter as a separate implementation to evaluate, not as an officially supported LibreTime feature.
Decide where the relay will run. Running it on the LibreTime machine can simplify access to the source, but it also means relay work competes with the automation system for CPU, memory and network capacity. A separate always-on machine or hosted compute can isolate those workloads, but adds another machine to maintain and another network path to monitor. There is no universal best location: compare access to the Icecast mount, restart supervision, maintenance access and recurring cost.
Also decide whether the relay will pass through the existing audio or transcode it. A pass-through path can reduce processing, if the formats are compatible; transcoding can make the destination format explicit but uses processing capacity and requires audio settings that suit the material. A devotional channel with long spoken introductions may need different listening checks from a lofi station with continuous music, even if the technical stream settings are alike.
For long-running use, ask how the relay behaves if its Icecast input stalls, the network drops or the process exits. A restart policy can bring a process back, but it does not prove that it has reconnected to the right mount or that YouTube is receiving a healthy picture and sound. Keep the relay’s logs and a human-readable recovery procedure available to whoever will be responsible overnight.
Enter YouTube Live ingest details in the encoder
In YouTube Studio’s Live Control Room, create or select the stream and copy the server URL and stream key into the encoder. YouTube’s encoder setup guide describes this hand-off. Treat the stream key as a password: keep it private, restrict access to the encoder configuration and regenerate it if it is exposed.
YouTube recommends RTMPS, an encrypted extension of RTMP. Use the secure ingest option when the encoder supports it, and confirm that the selected server URL matches the ingest details YouTube supplies. Do not paste a key into a public script repository or a support post. If more than one person maintains the station, decide how the key will be shared securely and who is authorised to change it.
Match the encoder’s output to current YouTube guidance. Its encoder settings page specifies AAC or MP3 audio for RTMP/RTMPS, constant bitrate encoding, and a recommended two-second keyframe interval that should not exceed four seconds. Choose bitrate and resolution according to YouTube’s current recommendations and the upstream bandwidth you can sustain. A higher target is not useful if the connection cannot deliver it consistently.
For an audio-led channel, video still has to be considered. A still image or restrained visual loop may be enough for your presentation, but confirm that the encoder sends a valid video stream and that the image is appropriate for a public broadcast. If your output includes changing cards or a visual loop, test transitions as well as the audio. The private test guide for a YouTube video loop offers a useful way to think about checking a presentation before a public launch.
Keep the relay’s input and output distinct in your notes: the Icecast URL it reads, the YouTube destination it writes to, and the selected audio and video settings. This makes it easier to diagnose a silent broadcast without changing several parts of the chain at once.
Test the full path before publishing
Test in stages, then test the chain as a whole. First confirm that LibreTime’s scheduled output reaches the expected Icecast mount. Next confirm that the relay can read that mount and produces audio and video. Finally, check that YouTube’s Live Control Room shows a preview with the expected sound and picture. If the preview does not appear, isolate the failing link before changing multiple settings.
YouTube directs creators using an encoder to wait for a preview and use the Live Control Room’s Go live control for a scheduled event. Follow the current instructions for the stream type you create; a scheduled event and a continuous broadcast may expose different controls. YouTube’s live streaming tips also cover channel prerequisites, including verification and the absence of a live-streaming restriction in the preceding 90 days. Check your channel’s current eligibility before you depend on a launch date.
Test more than a short opening. Leave the chain running long enough to cross a playlist transition, a show boundary and any live-source change that is normal for your station. Listen for silence, clipping, abrupt format changes or a return to the wrong programme. Check that the relay continues to read the expected Icecast source rather than merely keeping an encoder window open.
A private or unlisted test can help you review the output without announcing a public launch, but use the visibility and event controls available in the current YouTube workflow. If you want to test the picture and sound separately from the radio automation, a guide to streaming a prerecorded MP4 with OBS without audio crackling can help identify encoder-side listening issues; it does not replace testing the LibreTime-to-Icecast route.
Include a controlled interruption in your test plan where practical. For example, observe what happens if the Icecast source is briefly unavailable, then verify whether the relay reconnects and whether YouTube’s preview recovers. Do not assume a restart is successful simply because the process is running again. Confirm fresh audio and video at the destination.
Plan for 24/7 operation and archive limits
A 24/7 broadcast is longer than YouTube’s documented 12-hour archive threshold. YouTube says streams exceeding 12 hours may not be captured at all; its encoder guidance says streams under 12 hours are automatically archived. Full DVR rewind may also be limited or unavailable on streams longer than 12 hours. Do not promise that one uninterrupted 24/7 transmission will create a complete replay or retain full rewind functionality.
If a durable archive matters, make a local recording part of the plan and check that it is actually being written and has usable audio. YouTube’s archive live streams guidance explains the platform’s current limits. You can consider deliberately ending and splitting broadcasts, but verify the current YouTube workflow and weigh that against the continuity you want for listeners. A stream that is always available and a set of complete replay files are different operational goals.
Think about what “24/7” means for your station. You may want one continuous audience destination, but the underlying relay may still need maintenance windows, key rotation or recovery tests. Plan how you will communicate any planned interruption and how you will resume the correct scheduled audio after maintenance. A schedule that runs unattended does not remove the need to know who can act when something stops.
Monitor playout, relay and stream health
Monitor each boundary rather than relying on one green status indicator. At the source, confirm LibreTime is playing the expected item and publishing to Icecast. At the relay, check that its input remains connected and its output is being sent. At YouTube, review stream health and listen to the actual preview or public output. A healthy Icecast mount cannot prove the relay is encoding properly, and a running encoder cannot prove that YouTube is receiving usable media.
Set up alerts or routine checks that match the way your team works. A small station may have a person checking the channel at opening and after a schedule change; a larger operation may need automated process and network monitoring. In either case, define what counts as a failure: no audio, frozen picture, missing preview, repeated reconnections or a schedule that has not advanced. Record the first response steps so an overnight operator does not have to guess.
Keep recovery responsibilities separate. LibreTime can continue scheduled playout when a live source is absent, and an Icecast fallback can help move listeners between sources. Neither is a failover plan for a separate YouTube relay. Decide whether that relay should restart automatically, what it should reconnect to, and how you will know if automatic recovery did not work. Make a local recording if the archive is important, and periodically confirm that the files can be played back.
If the difficult part is keeping a prerecorded channel broadcasting while your own computer is off, StreamNeo can remove that particular machine-running burden by turning an uploaded video into a YouTube Live stream; it does not replace the LibreTime-to-Icecast-to-relay architecture described here or provide a direct LibreTime integration.
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 connect LibreTime to YouTube Live?
Configure LibreTime to publish scheduled audio to Icecast, then have a separate encoder or relay read that mount and send an audio-and-video stream to YouTube Live. Enter the YouTube server URL and stream key in the encoder, and test the full path in the Live Control Room before publishing. The exact bridge is an implementation choice, not an officially certified LibreTime integration.
How can I stream LibreTime radio 24/7 on YouTube?
Keep LibreTime’s playout and Icecast source running, and supervise the separate relay that carries the audio to YouTube. Test schedule transitions, source interruptions and relay recovery, then monitor all three points: playout, relay and YouTube stream health. Remember that an uninterrupted stream beyond YouTube’s 12-hour archive threshold may not be captured, so record locally if a complete archive matters.
Can LibreTime stream directly to YouTube?
The cited LibreTime documentation describes Icecast and SHOUTcast outputs, while YouTube’s instructions describe supplying an encoder with a server URL and stream key. Those documents do not establish a native direct LibreTime-to-YouTube output. In this architecture, Icecast is the hand-off to a separate encoder or relay.
Does an Icecast fallback protect the YouTube broadcast?
Not by itself. A fallback mount can help listeners within the radio source chain, but the separate relay can still fail or lose its connection to Icecast. Test and monitor relay reconnection independently, and decide who responds if YouTube stops receiving the stream.