For a recorded station ID, the simplest OBS approach is a Media Source that you trigger when needed. For scheduled changes between radio programmes, YouTube Studio alone is not enough: the content has to be switched by OBS or a playout system that controls the feed.
A manual clip trigger and a timed programme handoff are different jobs. This guide starts with the station ID workflow, then explains how to plan and test scheduled switching without assuming that OBS will manage it unattended by itself.
What a station ID needs to do
A station ID is a short announcement or audio mark that tells listeners what they are hearing: the station name, programme, location, or perhaps the next item in the schedule. On a continuous stream, it can identify a change of programme without ending the YouTube broadcast. It may also be paired with a title card, but the audio needs to be intelligible over the programme bed.
First decide whether the ID is meant to be manually triggered or played on a schedule. A presenter or operator can press a control at a planned moment; that is a manual action, even if the moment is written on a clock or in a running order. Scheduled playout means a configured system takes the action at a defined time or condition. Do not treat one as a substitute for the other.
The YouTube event and the material being sent to viewers are separate parts of the setup. YouTube Studio helps you schedule and promote the viewer-facing live event. Your encoder or playout arrangement determines which audio and video reaches that event. YouTube’s encoder setup guidance describes connecting an encoder with the stream URL and key and then sending a feed; it does not make the encoder change radio programmes for you. The YouTube Live Streaming API documentation likewise distinguishes the broadcast event from the stream carrying the media.
For one continuous channel, you can keep the same live event open while changing the programme in OBS. If each show should be a separately scheduled and discoverable event, that is a different publishing decision. Choose the event format for your audience and workflow; do not expect event scheduling to choose the content source.
Prepare a supported audio clip
Export the ID in a format OBS can read, such as WAV or MP3, and keep the clip somewhere stable on the computer running OBS. Avoid a removable drive or a temporary downloads folder that might be moved or disconnected. Use a clear filename such as station-id-evening.mp3, rather than a name that will be hard to recognise in the source list.
Listen to the rendered file from beginning to end before adding it. Check the station name, pronunciation, background music, start and end, and whether the first syllable is cut off. If it is a spoken identification, leave enough breathing room around the words; an abrupt edit can sound like a fault even when the file plays correctly.
Think about the programme underneath it. If the ID is intended to sit over music, the music may need to be lowered while the voice plays. If it is meant to replace the programme briefly, it needs a clean transition back to the programme. Those are mixing and timing choices, not something the Media Source decides automatically.
For a stream already built around multiple scenes and sources, it can help to organise and label the OBS project before adding more controls. The guide to configuring an OBS scene collection for a recorded channel covers the broader scene organisation problem. A single station ID does not require a full scene collection redesign, but a tidy source list makes the right clip easier to trigger under pressure.
Add the clip as an OBS Media Source
In the scene that is currently going to air, add a Media Source and point it to the prepared audio file. Give the source a descriptive name so it is easy to distinguish from programme audio or other announcements. If you want a visual card during the ID, add that separately and decide whether it should appear with the audio; the audio source itself does not create a graphic.
OBS routing matters more than the source’s name. A Media Source can play inside a scene, but it only helps viewers if its audio is included in the programme mix that OBS sends to YouTube. Check the source’s audio activity in OBS while the clip plays, and check the corresponding output meter. If your project uses scene-specific audio, a mixer bus, or monitoring devices, confirm that the clip is routed through the same outgoing audio path as the regular programme.
This is the practical check that catches a common silent failure: the clip meter moves, yet the live audience does not hear it because it is routed to a different output or excluded from the active scene. Listen to the OBS output or a private/unlisted rehearsal feed, rather than relying only on the local source meter. A local monitor can also be misleading if it is delayed or configured differently from the stream mix.
If you already use OBS to play longer recorded programmes, keep the station ID’s role distinct from the programme source. The article on streaming a folder of videos continuously with FFmpeg covers a different playout pattern; an FFmpeg-based feed will not expose an OBS Media Source unless OBS is in the actual content path or an appropriate control connection is configured.
Set playback to restart when activated
Open the Media Source properties and enable the option to restart playback when the source becomes active. With that setting, activating the source begins the clip from its start, rather than resuming part-way through from a previous play. OBS labels and available controls can vary across versions, so verify the option in the installed build rather than relying on a screenshot for another version.
If the clip should only play once, leave looping disabled. Looping can be useful for a sustained bed or repeated audio, but it is usually wrong for a spoken station identification: a clip that keeps repeating can interrupt the programme and sound like a stuck control. After the clip ends, decide whether it should disappear, remain inactive, or be triggered again only by an operator.
You can test the restart behaviour without going live. Activate the source, let it play part-way, deactivate it, then activate it again and confirm it starts at the beginning. Also check what happens when you switch scenes away and back. That rehearsal does not prove an unattended schedule will work; it only verifies the behaviour of this source in the current scene setup.
Trigger and monitor the announcement
For a manual ID, use a predictable operator action. You might activate the source in the OBS scene, switch to a scene that contains the ID, or use an existing control surface configured for that action. Before the show, make sure the chosen action is visible and does not also alter unrelated sources. If another person operates the channel, agree on a cue and a way to confirm that the clip has actually started.
Do not call a manual cue automatic simply because the source is configured to restart. Restart-on-activation determines how the clip behaves after it is activated; it does not decide when to activate it. Nor does pressing a button guarantee that the live output contains the audio. Keep an operator able to hear or inspect the outgoing feed, especially during the first uses.
If an ID needs to play at a fixed time every day, you are moving into scheduled playout. OBS can be automated, but the schedule has to be configured in a compatible automation layer and associated with the correct scene, source, or media action. OBS has built-in WebSocket support for external control; its remote control guide recommends enabling authentication and protecting the password if you expose that control path. Treat remote control credentials like other account secrets.
StreamNeo is relevant when the pain is keeping a prerecorded channel running from a computer that would otherwise need to stay on: it runs an uploaded video as a YouTube stream, but it is not a radio scheduling console and it is YouTube-only. It does not remove the need to configure and verify your station’s programme transitions in the system that produces its feed.
Plan scheduled playout separately
For timed programme changes in an OBS-based station, one documented route is the Advanced Scene Switcher plugin. Its macros combine conditions and actions; the plugin listing describes date/time conditions and actions such as switching scenes or controlling media. The plugin’s official OBS resource page gives its current compatibility details, so check the listing against the OBS version installed before adding it. The listing currently states an OBS Studio minimum of 31.1.1; this is a version requirement, not a guarantee that every project or source will behave as intended.
A common arrangement is one scene per programme. Each scene can contain the appropriate audio source, title, and visual treatment, so it is easier to inspect what the next programme will look and sound like. A macro can then select the intended scene at the planned time. Another arrangement keeps one shared scene and changes the media source inside it. That may preserve a consistent visual layout, but you must configure and test the specific source action in your project.
An existing radio playout system may be the better place to manage the schedule if it already supplies the live feed reliably and can control the required output. There is no universal integration that can be assumed for every station system. Establish exactly which application owns the programme clock, which output it changes, and whether OBS is receiving that output or making the switch itself.
Whichever layer owns the schedule, write down the handoff behaviour. Decide whether the outgoing programme fades, stops cleanly, or continues under a station ID; decide what happens if the next file is missing; and decide whether a late operator action could conflict with the timed switch. The automation’s action must correspond to what viewers should hear and see, not merely to a source name that looks plausible in a macro list.
YouTube Studio remains useful for the event itself: title, visibility, planned start, and stream settings. It is not a playlist scheduler for content coming from an encoder. For a continuous feed, the key operational question is whether OBS or the playout system remains running with its schedule active. A cloud-service checklist for prerecorded YouTube streams can help you think through the separate issue of keeping a computer-dependent stream running, but it does not replace radio-specific playout configuration.
Test levels and timing in the live feed
Build a rehearsal around the actual transition, not just the source in isolation. Start the outgoing programme, trigger or schedule the ID, then switch to the next programme. Listen for missing words, doubled audio, an unexpected silence, and a level jump when the new source enters. Check both the local OBS mix and what YouTube receives, because the outgoing feed is the reference that matters to viewers.
Use YouTube’s Live Control Room to inspect the stream and confirm that the intended broadcast is receiving the intended encoder feed. Rehearse the time zone and the exact scheduled time, especially if the computer, automation plugin, and station running order may use different settings. Test the whole sequence more than once under realistic conditions, including what happens after an OBS restart if that is part of your normal operation.
For a station ID mixed over music, aim for speech that is clear without making the programme disappear. For an ID that replaces the programme, check that the underlying source does not continue audibly by accident. There is no single level value that fits every recording, microphone, music bed, and output chain, so compare by listening at a normal playback level rather than inventing a universal meter target.
Before depending on unattended switching, confirm that the automation is enabled, that its time condition is interpreted as intended, and that the action selects the right scene or media control. Leave a practical way to observe the feed and intervene. A successful rehearsal is useful evidence about your configuration, but it is not a promise that a manually triggered clip or an unattended schedule cannot fail later.
If the stream is already live, avoid experimenting with untested scene changes in front of viewers. Prepare a duplicate scene or a rehearsal event, make a note of the current live scene, and have a simple recovery action ready. When a change produces silence or the wrong programme, switching back to the known-good scene is usually more helpful than making several unrelated adjustments while the broadcast continues.
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
Can YouTube switch my livestream playlist at a set time?
YouTube Studio schedules the viewer-facing live event; it does not select which programme an encoder sends at a particular time. Configure the switching in OBS or in a playout system that controls the outgoing feed, then verify the result in Live Control Room.
Does restart-on-activation schedule a station ID?
No. It tells the Media Source to start from the beginning when it becomes active. An operator or a separate automation system must activate it, and you still need to check that the source is routed to the stream’s audio mix.
Should I use separate OBS scenes for each radio programme?
Separate scenes make programme-specific audio and visual arrangements easier to inspect and switch. A single scene with media changes can suit a shared layout, but the correct method depends on your project and must be rehearsed with the real sources.
Can I rely on a manually triggered clip for unattended playback?
No. A manual trigger requires someone or something to issue it, and a successful local playback does not prove the live feed received it. For scheduled unattended playout, configure and test the automation in the layer that controls the content, and keep a way to monitor the outgoing feed.