You schedule two separate things to run different playlists on a Hetzner-hosted YouTube livestream: the live events in YouTube, and the media playout jobs on the server. YouTube’s event does not select local MP4 files; your server or encoder must start the intended playlist and send its feed at the right time.
The practical model is one scheduled broadcast per programming block, with a server-side schedule that matches those broadcasts. For events at different times with the same encoder settings, you can usually reuse a YouTube stream resource and bind each event to it. You still need to test the timing and hand-off with your own files before leaving it unattended.
Separate YouTube event scheduling from media playout
A YouTube live broadcast and a YouTube live stream are related resources, but they are not the same thing. The broadcast is the scheduled event or video on your channel: it has an event title, start time and privacy status. The stream represents the incoming audio and video feed from your encoder. YouTube documents the relationship in its guide to broadcasts and streams.
This distinction matters when you have, for example, a morning bhajan programme and an evening instrumental programme. YouTube can have a separate event for each block, but it does not inspect a directory on your Hetzner server and decide which MP4 files to play. A separate playout schedule on that server must select the morning playlist, then the evening playlist, and feed the output to YouTube.
Think of the workflow as two calendars that must agree:
| Schedule | What it controls | Where to manage it |
|---|---|---|
| YouTube broadcast schedule | The event that viewers can find, and its start time and visibility | YouTube Studio or the Live Streaming API |
| Server playout schedule | Which media files play, in what order, and when the encoder sends them | Your server-side scheduler and playout process |
The broadcast is associated with a stream, but that association does not contain a list of local files. Google’s API guide describes how a broadcast moves through testing and live states in its broadcast lifecycle documentation. The useful operational consequence is that a correctly scheduled YouTube event can still show the wrong content, no content or an offline feed if the server job is missing, late or pointed at the wrong playlist.
If you are moving an existing channel from a home computer to cloud hosting, first understand what work moves to the server and what remains in YouTube. This guide to moving an always-on stream from a home PC to a cloud service covers that broader change. The two-schedule model here is what prevents a move to Hetzner from being mistaken for an automatic playlist scheduler.
Create or reuse the YouTube live stream
Before making events, check that the channel is enabled to livestream and that you can create or manage live broadcasts. YouTube’s API documentation identifies account permissions and live-streaming eligibility as prerequisites; a channel that cannot stream will not become ready simply because you have provisioned a server.
A live stream resource describes the incoming feed and its delivery settings, including ingestion type and video configuration. If several events take place at different times and use the same settings, YouTube’s documentation allows a stream to be reused across broadcasts. In practical terms, that can mean one stream resource and its stream key are used by your encoder while you schedule multiple distinct events against it.
Reuse is not compulsory. Separate stream resources may make sense if broadcasts overlap, if shows need different delivery settings, or if separate encoder processes must be isolated. Decide based on how your playout is actually arranged. If your server will run one playlist after another with the same output format, reusing a stream avoids needless reconfiguration. If two programmes are meant to be on air simultaneously, one feed cannot represent both programmes at once.
Treat the stream key as a credential. Store it where only the process that needs to publish can read it; do not paste it into public scripts, logs or screenshots. When you configure the encoder, use the delivery details shown for the specific stream rather than copying an old key or assuming a destination URL is unchanged. A stream key connects an encoder feed; it does not tell YouTube which server playlist should be active.
Schedule distinct live broadcasts
Create a YouTube broadcast for each block that viewers should see as a separate event. A morning devotional set and an evening lofi session may warrant different titles, descriptions, start times and visibility choices. If you are using the Live Streaming API, Google describes the broadcast creation fields and lifecycle in its documentation for the life of a broadcast. In particular, creating an event requires details such as its title, scheduled start time and privacy status.
You can manage scheduled broadcasts through YouTube Studio rather than writing code, which is often a better starting point for a small channel. The API becomes useful when you are automating event creation, but it adds account authorization and resource-management steps. Either route creates the YouTube events only. It does not add files to a server playlist or set a timer on Hetzner.
Use times that can be represented unambiguously by both schedules. Pick a timezone for your planning sheet, record it beside each start and end, and confirm how the server clock and scheduler interpret those values. A schedule that says “7 pm” without a timezone is an invitation to start the correct playlist at the wrong hour after a clock or configuration change.
Leave enough operational space around a changeover to verify the new output. If one event ends and another begins immediately, the previous process may still be stopping as the next event is expected to start. The right margin depends on the media and automation you use, so do not assume that matching start times alone creates a clean transition. For a continuous channel, also decide what viewers should see in any gap: a holding card, a short loop, or a deliberate offline period.
Bind broadcasts to the intended stream
Once you have a broadcast and a stream resource, associate the event with the stream that will carry its video and audio. In YouTube’s Live Streaming API, the liveBroadcasts.bind operation makes that association. The API documentation is explicit that each broadcast is associated with exactly one stream.
For two broadcasts that run at different times and use the same encoder settings, you can bind both to one reusable stream. The server still needs to publish the proper playlist for each event. For example, binding the morning broadcast and evening broadcast to one stream does not make the stream switch media at the event boundary. Your scheduler must stop or change the morning playout and start the evening playout as intended.
Keep a small mapping table as the source of truth for the event-to-stream relationship and the server job that supplies it. It might contain the event title, YouTube broadcast identifier, stream identifier, start time, playlist file and expected encoder process. This is especially useful if you revise a title or recreate an event: the name alone may not identify the resource your automation is meant to use.
If you use YouTube Studio, check the event’s stream selection in the interface and confirm it is the same stream whose delivery settings you put in the encoder. If you use the API, verify the bind result rather than assuming a successful event creation also performed the association. Keep credentials and identifiers out of public documentation, but make the operational mapping easy for the person on duty to find.
Build the Hetzner playlist schedule
On the server, prepare a distinct playlist for each block. Make the order explicit and keep the files in a predictable location. A playlist called morning.txt might list the devotional tracks in sequence; evening.txt might list instrumental recordings. The exact format depends on the playback tool. FFmpeg’s concat demuxer is one possible way to sequence files, but a command that works for one collection is not automatically suitable for another.
Before scheduling anything, test that each file opens and that adjacent files behave as expected. Differences in codecs, frame sizes, frame rates, audio sample rates or time bases can affect whether the process can copy streams directly or must transcode them. Stream-copying can reduce processing work where media is compatible; transcoding can make output more consistent but requires enough capacity for the actual workload. There is no universal command or Hetzner server size that can be recommended without testing your media and output settings.
Choose how the playlist process will run. One approach starts a process for each scheduled block, pointing it at that block’s playlist. Another keeps a process running and changes the media input between blocks. Compare them by how they recover from failure, how they log progress, and what viewers see at a transition. A per-block process is conceptually simple, but its stop and start need to be coordinated. A persistent process may reduce process churn, but switching inputs cleanly depends on the tool and configuration. Neither should be called seamless until you have observed the actual transition.
Use a scheduler and process supervision method supported by the operating system you install. A cron entry, systemd timer or custom controller is an implementation choice, not a feature YouTube or Hetzner automatically provides for playlist selection. Make sure the job has access to media files, the stream key and the correct environment when it runs non-interactively. Test how it behaves after a process exits, the server restarts, or the network drops; do not assume a scheduler will restart a failed encoder unless you have configured and checked that behaviour.
For encoder settings and common output considerations, compare your test results with this FFmpeg settings guide for a continuous YouTube livestream. If you are looping several MP4s rather than assigning different playlists to event windows, this guide to looping multiple MP4 files is more directly focused on that playout problem. Neither article removes the need to validate your own media and installed FFmpeg build.
Match each playlist to its event time
Make a single schedule that pairs every YouTube event with the playlist and server action that should supply it. Include start time, intended event, playlist path, stream resource, and the expected process action. If the blocks have end times, record those too, along with what should happen at the boundary. Avoid maintaining one set of times in a spreadsheet and another by memory in a shell script.
Then implement those actions in the server scheduler. The event schedule says when YouTube should present a broadcast; the server schedule says when playout should begin or change. These should be close enough to deliver the intended feed, but the two are independent systems. A calendar edit in YouTube will not update a Hetzner timer, and changing a playlist file will not revise a YouTube event title or time.
Before each block, make the intended playlist and event easy to identify. Naming files and jobs consistently reduces the chance of sending the evening programme into the morning event. For a channel with Hindi and English episodes, you might name both the broadcast and the corresponding job with the language and programme block, then verify the stream mapping. The same approach works for local news loops, study material or a business information channel.
Think through what happens if timings change. If an event is moved, update both calendars and check the binding again. If a playlist is replaced, confirm that the server job points to the new path and that the new files pass a playback test. If the event is cancelled, decide whether the server should stop publishing, switch to a holding playlist or continue with another scheduled block; do not leave that behaviour implicit.
A cloud-hosted process can remove the need to keep a personal computer on for playout, but it does not remove the need to maintain the media, credentials, event times and failure checks. StreamNeo can remove the specific burden of keeping and supervising a home computer for a file-based continuous broadcast: you upload the video, provide the YouTube stream key, and the service runs the broadcast while your computer is off. It is YouTube-only, so it is not a replacement for a Hetzner workflow when you need your own server-side scheduler to switch among several distinct playlists at event times.
Test event transitions and encoder output
Test with an unlisted or otherwise appropriate test event before relying on the schedule for a public programme. Confirm that the server process starts, reaches the configured YouTube stream, and produces the picture and sound you expect. Check the event state in YouTube and the encoder’s own output or logs; a process that is running is not proof that YouTube is receiving a usable feed.
Run a changeover test with the actual playlists. Confirm that the first process stops or changes input as planned, the next playlist begins, and the associated broadcast is the one you intended. Watch for a blank interval, repeated material, audio discontinuity or an unexpected offline state. YouTube’s broadcast lifecycle includes testing and live states, so use the available testing path to learn what your channel and configuration show before depending on unattended transitions.
If you use RTMP, FFmpeg documents the protocol for sending a real-time input to an RTMP server in its protocol documentation. If you choose HLS instead, do not transplant RTMP assumptions into that setup. YouTube’s HLS setup requirements include segment and playlist constraints, and YouTube notes that HLS has higher latency than RTMP because it is segment-based. Select the ingest method your encoder supports and test the exact output path.
A Hetzner server is only part of the capacity decision. The workload depends on whether the process copies compatible media or transcodes it, the chosen resolution and bitrate, storage access and how many jobs may run at once. Hetzner’s general server documentation does not establish a streaming-specific size recommendation. Measure CPU, memory, disk and network use during a representative test before settling on a plan, and repeat the test if you change the encode path or media.
Finally, check the materials and account before going live. Confirm that you have permission to use every video and audio track in a livestream, and check YouTube’s current eligibility and live-streaming guidance for the channel. Neither the schedule nor the hosting arrangement establishes rights or guarantees that a broadcast will be approved.
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 scheduling a YouTube event choose the MP4 playlist?
No. A YouTube event schedules a broadcast and is associated with an incoming stream; it does not select local files on your Hetzner server. You must configure server-side playout to choose and send the intended playlist.
Can I use one YouTube stream for several scheduled broadcasts?
YouTube documents reusable streams for broadcasts at different times, provided the arrangement suits the stream settings and encoder workflow. Each broadcast still needs its own event details and must be bound to the stream you intend it to use. Overlapping broadcasts or different delivery requirements may call for separate stream resources.
Should I use RTMP or HLS?
It depends on your encoder and the delivery requirements. YouTube documents different HLS requirements and higher segment-based latency than RTMP, so check the current official guidance and test the complete setup rather than treating the protocols as interchangeable.
Which Hetzner server size is enough for several playlists?
There is no size established here as suitable for every channel. Measure the actual workload with your media, resolution, bitrate, number of simultaneous jobs and whether you transcode; change the choice if those conditions change.