To show the currently playing track on a 24/7 YouTube radio stream, put the track details in the video image sent to YouTube. You need a source that knows the current title and artist, plus an overlay that displays them.
The right setup depends on where your audio plays. OBS can use a browser overlay or native text and image sources fed by a bridge; some hosted playout services offer their own Now Playing element. None of these should be confused with the YouTube broadcast title, which identifies the live event rather than serving as a per-track graphic.
How track information reaches the viewer
Think of this as two linked steps. First, something obtains the current track name and, if available, artist and cover art. Then a graphic places those details into the video composition. If either step is missing, viewers may hear the track but see no reliable label.
The metadata source might be the playback application itself, a maintained list for a fixed sequence, or a playout system that knows which file it is transmitting. A dynamic music player should be paired with a method that reads its actual current state. A fixed sermon or ambience loop may instead use labels prepared in advance, provided the labels stay aligned with the sequence.
This distinction matters on a channel that runs unattended. A title typed into an OBS text source can look correct at launch and become wrong when the next track begins. A working now-playing setup changes the displayed information when playback changes, and has a defined response when the source pauses, stops, or fails to provide metadata.
The overlay is part of the outgoing video, not an annotation YouTube infers from the audio. Viewers see only what your scene or playout composition contains. For background on the broader mechanics of a continuous broadcast, see how recorded sermons can be streamed continuously.
Track labels are not the broadcast title
A YouTube live event has broadcast-level details, including a title and description. Those details identify the live stream as a whole. Changing the visible song label inside the video is a separate task: it requires the changing text or artwork to be included in the video composition.
The YouTube Data API documentation describes fields for live video details such as actual and scheduled start and end times and viewer count. It does not describe those fields as an automatic per-track overlay. You can set an event title such as “Evening Bhajans — Live”, but that does not mean it will become “Song A — Artist B” and then update for each subsequent track. See the YouTube videos resource documentation for the distinction between video-level details and what is actually rendered into the picture.
Keep the two jobs separate. Give the broadcast a stable title that accurately identifies the programme or channel, then use an on-screen label for the current track. This also avoids confusing viewers who arrive midway through a long session: the event title explains what they are watching, while the overlay identifies what they are hearing now.
If you change a scheduled event’s title or description, verify the result in YouTube Studio and in the public watch page. Do not build an overlay workflow around an assumption that event metadata will track the playback queue. For a practical look at handling a stream before you make it public, see how to test a live stream without going public.
Choose a workflow for the playback source
Start by identifying the exact application or service that plays the audio. “It is on YouTube” is not specific enough: YouTube Music in a desktop app, YouTube Music in a browser, a local playlist and a hosted playout service expose different information in different ways.
| Playback source | Possible route | What to verify before relying on it |
|---|---|---|
| YouTube Music desktop | Local API browser overlay, or a community bridge to OBS text and image files | Whether the integration sees the actual playing item, what happens when the app closes, and whether it still works after an update |
| YouTube or YouTube Music in a browser | A browser-oriented Now Playing resource that can use chapters or playlist information | Current browser compatibility, the source of its title data, and whether that source matches your viewing pattern |
| Fixed sequence of files | A maintained track list or prepared labels | Whether the sequence and labels remain in sync after skips, restarts or edits |
| Hosted continuous playout | A built-in Now Playing element, if that service provides one | Whether your chosen service offers the feature, how it reads metadata, its terms, cost and behaviour on missing data |
YTMDesktop2 documents a local API and an OBS browser-source overlay for YouTube Music desktop. The OBS forum resource “Music on stream” describes support for YouTube and YouTube Music and says it can draw titles from chapters or a video-description playlist. A separate community project documents a bridge that writes title and artist to a text file and cover art to an image file. These are different integrations, not interchangeable guarantees.
Hosted playout may reduce the number of local pieces you need to keep running, but do not assume every service includes Now Playing. Check the feature documentation for the service you are considering and confirm whether its overlay uses the metadata for the content actually being played. For a wider comparison of streaming workflows, browser-based streaming software for different show formats can help you think through which source fits your programme.
A bridge documented by a community project is community code, not a tested or supported integration. Treat its instructions as a starting point, review what it asks you to install and grant access to, and test it with your own playback setup. If a maintained application or hosted workflow better matches your tolerance for upkeep, that may be the more practical choice.
Build a browser-source overlay in OBS
A browser-source overlay is often the clearest route when the metadata integration supplies a URL. For example, YTMDesktop2’s documentation explains how to enable its local API, copy an overlay URL and add it to OBS as a Browser Source. It documents several layouts, including full card, compact, text, badge, fullscreen, stack and ticker. Their availability does not mean each layout will suit every screen or channel.
The general setup is straightforward. Enable the integration’s local API or equivalent, copy the overlay URL it provides, then add a Browser Source to the OBS scene that goes to YouTube. Give the source enough width and height for the chosen layout, place it over an area that does not cover important visual content, and preview the scene. Follow the current instructions from the integration rather than guessing at a URL or port.
Check whether the browser source can reach the metadata service for the full duration of your stream. A local overlay may depend on the desktop player and integration continuing to run, even if the OBS scene itself remains open. Rebooting the computer, signing out of the music app or changing a local setting can interrupt the relationship between player and overlay.
Keep the overlay readable on a phone as well as a desktop screen. A compact label might show title and artist on one line; a card might include artwork but occupy more of the picture. Test against both light and dark parts of your background. If your station uses a static devotional image or a slow ambience scene, make sure the label does not obscure the central subject or become hard to see against it.
Before leaving the channel unattended, run through a track transition while previewing the outgoing scene. Confirm that the old title disappears, the new title appears, and the audio and label change at the same point closely enough for your audience. The visual label is only as current as the metadata source behind it.
Use OBS text and image sources with a bridge
A different OBS route uses native text and image sources that read files updated by a small bridge. The documented YouTube Music community project describes writing the title and artist into a text file and cover art into an image file for OBS to display. That can be useful if you want to position title, artist and artwork independently using familiar OBS sources.
The trade-off is that you are connecting more moving parts. The desktop playback app must expose the information; the bridge must keep receiving it; the output files must remain accessible; and OBS must read the right files. The community project’s documentation describes a setup requiring the desktop app and Python. That is a meaningful limit for a channel owner who expects to switch off the computer or does not want to maintain a local software chain.
Set up text and image sources in a test scene first. Point the text source at the file the bridge writes, and the image source at the intended cover-art file, following the project’s current instructions. Avoid copying sample paths without checking them against your own computer. Confirm that OBS can access the files and that the font, dimensions and image fit your scene.
This bridge is community code; do not treat it as tested, guaranteed or officially supported. A change in the player or operating system could affect it. Keep a fallback scene or a clear no-metadata state available, and decide who will notice and correct the problem if the bridge stops updating during an overnight stream.
If the local machine itself is the concern, separate that from the overlay decision. A local computer may keep the player, bridge and OBS running, while a hosted playout workflow may handle continuous playback differently. The right choice depends on whether you value direct control or fewer local tasks, not on a blanket claim that one method always works. See what free versus paid 24/7 streaming can mean in practice when assessing the wider operating trade-offs.
Check updates, artwork and stale data
Do not test only the first track. A useful check covers ordinary transitions, a long title, a title with non-Latin characters if those appear in your catalogue, missing artist information, pause, stop, player restart and the metadata source closing. Observe both the outgoing image and what a viewer sees on the watch page.
Long titles can spill outside a text box or break a card layout. The playout.video help documentation for its Now Playing overlay specifically warns about long titles and handling overflow. Choose a layout that truncates, wraps or scrolls in a way you can read, rather than assuming every track name will fit. Test the longest realistic title you expect to show.
If cover art is displayed, verify that it belongs to the track and updates when the title does. Artwork can be unavailable, mismatched, or left over from the previous item if the metadata path fails. Decide whether to hide the image, show a neutral fallback, or keep a consistent station graphic when there is no usable artwork.
Plan what viewers see when the information is stale. A label that remains on the last track after playback stops can be more misleading than no label. The community bridge documentation notes that it clears text when playback stops but may keep the last track if YouTube Music fully closes. That behaviour is a reason to test process failure explicitly and choose a visible fallback such as hiding the label or displaying “Now playing unavailable”.
For a fixed rotation, compare the label against the sequence after a restart or a manual skip. A chapter list or description playlist can be convenient, but only if the underlying playback follows that order. If a person can change the queue independently, a prewritten list may drift away from the audio. Dynamic playback calls for a source that observes the actual player state.
You can also test the broadcast as an unlisted event before making the channel public. This lets you inspect the composed picture, audio and metadata behaviour without presenting a broken label to your regular audience. Keep the test long enough to see a transition and a failure state, not just a still frame at startup.
Troubleshoot missing or stale track details
When the overlay is blank, isolate the failure by layer. First check whether the player itself shows a current title and artist. Next check whether the metadata integration is running and receiving them. Then check whether OBS can reach the browser URL or read the expected files, and finally whether the source is visible and correctly placed in the scene. This order avoids changing scene styling when the underlying metadata is absent.
If text appears but never changes, verify that the integration is attached to the same player instance that is producing the audio. A browser tab and a desktop app can each play music, and a bridge for one will not necessarily follow the other. For a fixed list, check whether a skip or restart moved playback out of sync with its prepared labels.
If the title changes but artwork does not, troubleshoot the image path and update behaviour separately from the text. A text file may refresh correctly while the image source still points to a cached image or unavailable file. Use the integration’s own current guidance, then confirm a new image appears after an actual track change.
If information becomes stale after the player closes, decide whether that is an acceptable display state. For unattended use, an explicit unavailable label or hidden overlay is generally clearer than leaving the previous song presented as current. Also check whether the source has a documented timeout or clear-on-stop setting; do not assume it exists.
If your music comes from Spotify, do not treat its current-track API as permission to put Spotify recordings into a continuous visual broadcast. Spotify’s documentation for the currently playing track endpoint says Spotify content must not be synchronised with visual media and may not be used for non-interactive broadcasting. Check the current official policy and choose content and playback methods accordingly; an API response is not a rights clearance.
When you are ready to operate the channel rather than just test the graphic, choose a workflow whose failure modes you can monitor. StreamNeo can remove the need to keep your own computer on to run a file-based continuous broadcast, which is useful when local playback and overlay upkeep are the specific overnight burden; it is YouTube-only, and you should confirm that your chosen way of supplying track information fits the service before relying on it.
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 change the live title for every song?
Do not rely on the broadcast title to act as a changing song label. Set the event title for the programme, and put current-track information in the video composition using an overlay or the playout system.
Can I show a track name without OBS?
Some hosted playout services document a built-in Now Playing element, but availability varies by service. Check the current feature documentation and confirm how the service obtains track metadata before choosing it.
What if I have a fixed playlist rather than a music app?
A maintained list, chapters or description playlist may provide labels if playback follows that order. Test skips, edits and restarts, because the label can become inaccurate when the sequence and audio diverge.
Is a community bridge a supported integration?
A community project’s own documentation is not proof that the code is tested or supported for your setup. Review its requirements, try it in a test stream and keep a fallback for missing or stale information.