To run a 24/7 YouTube music stream on Ubuntu, keep FFmpeg in the foreground and let systemd start it at boot and restart it after an unexpected exit. YouTube receives an encoded live feed; the playlist or media source that supplies tracks is a separate part of the setup, and changing that source does not always change a feed already in progress.
This guide covers both jobs: keeping a prerecorded feed running and finding out whether you can update its music queue without interrupting it. You will need a YouTube live stream and a media file or playlist you have the rights to use. No particular player or service is guaranteed to support live queue changes.
Understand what YouTube receives
Your Ubuntu machine reads media and sends an encoded signal to YouTube's ingest address. FFmpeg is the encoder in this example. YouTube Studio creates or schedules the live stream and provides the destination details; FFmpeg connects using the stream key. Viewers see the resulting live broadcast, not the playlist file on your Ubuntu machine.
That distinction matters when you want to add a song. The incoming feed may be one continuous output from FFmpeg, while a separate playlist file, player, or service decides which track is played next. YouTube receives the output, but it does not necessarily have access to the source queue or control over it. There is no universal YouTube Studio procedure for editing the song queue of every live encoder feed.
Before you configure Ubuntu, check YouTube's live-streaming eligibility guidance. The channel must meet YouTube's requirements, including verification and no live-streaming restrictions in the previous 90 days. First-time enablement can take up to 24 hours, so do not leave this step until the evening you plan to go live.
In YouTube Studio, create or schedule the stream and keep the stream key private. It is a credential, like a password: someone who obtains it may be able to send a feed to your stream. YouTube explains the encoder setup and stream-key process. Copy the ingest URL and key securely, and reset the key in Studio if you believe it has been exposed.
Find the playlist's media source
Write down the path from track to viewer before troubleshooting. A simple arrangement is a single file that FFmpeg loops. Another might use a playlist file that FFmpeg reads, while a separate player or streaming application manages the queue. In each case, identify the component that chooses the next track, not just the process that sends video and audio to YouTube.
If you launch FFmpeg directly with a single input such as loop.mp4, the source is that file and the command line controls how it repeats. If you use a playlist, find the playlist file and the program that reads or updates it. If a web dashboard or desktop app controls playback, that application may own the queue even though a command-line encoder carries its output to YouTube.
This is also the point to decide whether the arrangement is appropriate for a 24/7 channel. A local Ubuntu computer means you maintain the machine, power and internet connection. A rented Linux host shifts hardware upkeep but still leaves you responsible for the operating system, media and process. A managed service can avoid leaving your own computer on, but you should confirm that its workflow supports your intended source and queue changes. Compare the practical responsibilities rather than assuming any option removes every failure mode.
If your goal is specifically to keep a prerecorded file broadcasting without OBS, the overview on streaming ambient music without OBS may help you think through the source and output roles. For a server-based FFmpeg path, see the guide to sending an FFmpeg playlist from a VPS over RTMPS. The details differ by input and host, so do not transplant a command without checking its paths and format.
Check whether it supports live queue updates
Look in the media source's own documentation or controls for terms such as queue, playlist reload, watch folder, refresh, next track, or rescan. Then establish what the feature actually does: does it insert a new track after the current one, replace the remaining queue, or take effect only when playback restarts? A button called “update” is not enough evidence that an active broadcast will continue without interruption.
Check how the source reads the playlist. Some tools may read a file once when they start; editing that file afterwards may have no effect until the source reopens it. Others may watch a directory or expose queue controls while running. If the software has a supported live update function, test it with a short stream before relying on it overnight.
If there is no documented live queue control, treat the queue as fixed for the session. You can prepare a revised playlist for the next start, or plan a controlled transition if the source requires a restart. Do not assume that editing a file beneath a running process will be noticed, and do not assume YouTube Studio can alter the source queue simply because it displays the live preview.
Rights checks belong in the same preparation. You need the necessary rights for the music in a live broadcast; availability on a website or a personal subscription does not by itself establish streaming rights. YouTube's live-stream terms require creators to hold the necessary rights, and its systems may interrupt or terminate a live stream when they identify third-party content. Read YouTube's guidance on copyright issues with live streams and check the rights for each track and territory relevant to your use.
Update the queue without stopping the feed
If the source documents queue updates during playback, follow its procedure rather than modifying FFmpeg or the systemd unit. Confirm whether an update affects the current track or only the next selection. Keep a known-good queue copy so you can restore it if the change produces an unreadable path or unsupported file.
A sensible test is to start with a short, rights-cleared queue on a private or otherwise appropriate test broadcast, then add one item using the documented update method. Observe the source player's current and next tracks, and separately check the YouTube preview and a viewer device. This distinguishes a queue update that appears in the source from audio that has actually reached the live feed.
When the source offers no live update feature, avoid improvised file replacement while it is reading the playlist. The process may have already loaded the old contents, or it may encounter a partially written file. Prepare the replacement elsewhere, validate the paths and media, then use the source's documented reload or restart procedure at a planned time. If the stream must continue uninterrupted, test whether your specific source supports a safe handover; do not promise that it will.
For a feed assembled from separate files, a queue feature can be more useful than an infinite loop of one combined file. It also adds another moving part: the queue manager, media paths and encoder output must all remain healthy. The right arrangement depends on how often you change tracks and whether a brief interruption is acceptable. For advice on capacity, the upload-speed checklist for prerecorded streaming in India is relevant; allow room for other household or business traffic as well.
Run FFmpeg under systemd
For a straightforward loop, keep FFmpeg attached to systemd rather than detaching it into the background. The -stream_loop -1 input option asks FFmpeg to loop an input indefinitely. It does not create a queue editor, and a process restart may begin the file from the beginning unless your own input and command implement resume behaviour. Check the FFmpeg documentation for the option syntax and confirm that your installed build can read the chosen media.
Use a dedicated, unprivileged service account and a directory that contains the media. Install FFmpeg using the package source suitable for your Ubuntu release. Test the exact input and output manually before adding systemd; this helps separate a media or YouTube connection problem from a service configuration problem.
A unit can follow this general shape. Treat it as a starting point, not a copy-paste-ready stream: paths, codecs, output settings and the credential handoff must match your setup.
# /etc/systemd/system/youtube-music.service
[Unit]
Description=YouTube music stream
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=stream
WorkingDirectory=/srv/youtube-music
ExecStart=/usr/local/bin/start-youtube-music
Restart=on-failure
RestartSec=15
[Install]
WantedBy=multi-user.target
The wrapper named in ExecStart should be an executable that starts FFmpeg in the foreground. Do not assume systemd expands environment variables in ExecStart as a shell would. A wrapper can read a protected environment file and use exec to replace itself with FFmpeg, so systemd tracks the actual encoder process. Have an administrator validate the wrapper and its quoting before using it with a real stream key.
Keep credentials out of a public script or article. If you use an environment file, restrict access to it, for example by making it root-owned with mode 0600, and check who can read any wrapper or service configuration. Avoid displaying the key in terminal output or logs. You can also rotate it in YouTube Studio if it is compromised.
Once the unit is in place, reload systemd and enable the service at boot:
sudo systemctl daemon-reload
sudo systemctl enable --now youtube-music.service
systemctl status youtube-music.service
journalctl -u youtube-music.service -f
The status and journal show whether the process is running and what it reports. A running process is not proof that YouTube is receiving a healthy stream. systemd supervises the process; it does not validate your music rights, repair invalid media, make a weak connection stable, or confirm a healthy YouTube ingest.
Avoid restarting the encoder unnecessarily
A restart is not a queue update. If FFmpeg is reading one file, restarting it to add a track may simply make it read that same file again. If it is reading a playlist, a restart might load new contents, but it may also cut the live feed and reset playback. First check which process owns playback and whether that process provides a supported reload operation.
Systemd's Restart=on-failure is useful when the main process exits unsuccessfully. RestartSec=15 inserts a pause before a retry in this example; it is a practical starting value, not a guarantee of recovery. The Ubuntu systemd service documentation describes restart behaviour and start-rate limiting. If a service fails repeatedly in a short period, systemd can stop retrying until the start limit is cleared or the cause is addressed.
That is why an extremely short retry loop is not a substitute for diagnosis. A bad input file, wrong key, rejected output settings or network outage will still be bad on the next attempt. Check systemctl status and the journal, fix the underlying issue, and then start the service again when appropriate. A restart policy cannot guarantee YouTube ingest remains healthy through a sustained outage.
For an occasional queue change, favour a documented source-side refresh over bouncing the encoder, if the source supports it. If you must restart, schedule the interruption and verify that the service returns to active state and YouTube sees the new feed. If your playlist can be changed without altering the encoder process, make that change through the playlist owner and confirm the new selection there first.
Verify the new track reaches the stream
Check both ends. In the YouTube Live Control Room, inspect the preview and stream health; on a separate viewer device, listen for the new track after the expected transition. The source application's display may show a new queue item before the encoder has played it, and the Control Room preview may lag behind the source. Keep those observations separate when diagnosing a delay.
YouTube recommends testing with representative audio and motion, monitoring stream health and keeping upload bandwidth headroom. Its encoder guidance also lists supported protocols and media settings. For 1080p30 H.264 video, it lists 5 Mbps as a minimum and 14 Mbps as recommended; these are platform recommendations, not assurances about your machine or connection. See YouTube's encoder settings guidance. Leave about 20% upload headroom beyond the stream bitrate, as YouTube recommends, and test while other normal network use is happening.
When the stream is unhealthy, divide the diagnosis into layers. First, is the systemd service active, and does the journal show FFmpeg errors? Next, can the host reach the ingest endpoint and sustain its upload? Then, does Studio report stream health and show the expected preview? Finally, does the audio play on a viewer device? This sequence helps you avoid restarting a healthy encoder because of a source queue issue, or blaming the queue for an upload failure.
If the track is still old, revisit the queue owner: did it reload, did the new item have a valid path, and is playback actually advancing? If the track is new at the source but absent from the stream, investigate the handoff between source and encoder. If the encoder is sending but Studio reports a problem, check output settings, key and connection. A test stream using representative media is safer than discovering a format or rights issue during a long broadcast.
For channels that use licensed background music alongside still imagery, the article on YouTube's treatment of screensaver streams with licensed music gives useful context. It does not replace checking your own licence or YouTube's current rules. Keep records of your permissions and be prepared for platform-side checks even when you believe the track is cleared.
If you would rather not leave an Ubuntu computer responsible for restarting a stream after a local power or network interruption, StreamNeo removes that particular burden: you upload the video and provide the YouTube stream key, then the broadcast can continue with your computer switched off. It is YouTube-only, and it does not remove the need to choose media you have rights to use or verify the live result.
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 YouTube Studio let me edit any live music queue?
No. Studio creates and monitors the live stream, but the queue may be controlled by a separate player, playlist file or service. Check that source's documentation for live queue updates; there is no universal YouTube procedure that applies to every setup.
Will systemd keep my stream live if the internet drops?
Systemd can restart a process after it exits, according to the unit's restart policy. It cannot restore a failed network connection or guarantee healthy YouTube ingest. Check the service logs and Studio's stream health rather than treating an active unit as proof that viewers receive the stream.
Does looping one file let me add a song while it is playing?
Not by itself. -stream_loop -1 repeats the input, but it does not expose a live queue. To add tracks, use a source that documents queue updates or prepare a new playlist and plan a tested transition.
Can I use any music I can play on my Ubuntu machine?
No. You need the necessary rights for the music in your live broadcast. YouTube may identify third-party material and interrupt or terminate a stream, so check the current official terms and the permissions for each track.