Retrieve the station’s changing now-playing metadata, then display it in an OBS scene before the picture is sent to YouTube. For an Icecast station, the documented /status-json.xsl endpoint is a useful starting point, but the exact fields depend on how that station is configured.
The text viewers see on the video is an overlay, not the YouTube broadcast title. YouTube’s broadcast title describes the live video; it does not become a changing song label every time the radio station moves to another track.
Separate the broadcast title from the on-screen song text
There are two different pieces of information involved.
The YouTube broadcast title is the name and description attached to the live broadcast. You set it in YouTube Studio or through YouTube’s live-broadcast tools. It might be something such as “24/7 Punjabi Radio and Requests”. It remains the broadcast’s metadata unless you deliberately edit it.
The now-playing label is part of the video image. OBS places it over your background, visualiser, camera feed or loop, and then sends that combined picture to YouTube. A viewer may see “Artist — Song Title” at the bottom of the frame even though the YouTube broadcast title has not changed.
YouTube documents broadcast properties through its liveBroadcasts documentation. That documentation describes the broadcast resource and its associated metadata, not a mechanism for changing an on-screen label in response to a radio station’s track changes.
This distinction matters when you plan the setup. Changing a YouTube title manually is slow and may interrupt the consistency of your channel presentation. It also does not solve the visual problem for viewers who are watching the stream. The practical route is to leave the broadcast title stable and update a source inside the outgoing OBS scene.
You need two linked pieces:
- a reliable source of the station’s current title metadata
- an OBS source that displays the latest value in the scene
The audio stream alone is not necessarily enough. A station may play audio while exposing no public artist or title data. Conversely, a station may publish metadata through a separate endpoint that is not the same URL as the audio stream.
If your channel is devotional or regional-language focused, keep the label large enough to read on a mobile screen and allow for longer titles. The advice in the 24/7 bhakti sangeet playbook is also relevant here: treat the presentation as a service for viewers, not just as a technical feed.
Find the station’s now-playing metadata
Start by identifying how the station publishes its metadata. Ask the station operator, hosting provider or radio platform which streaming system is in use and whether it provides a documented now-playing endpoint. Useful questions include:
- Is the stream served by Icecast, SHOUTcast or another platform?
- What is the public metadata URL for the active stream?
- Does the endpoint return artist and title data, or only a combined string?
- Does the value change when the station changes track?
- Is access public, or does it require authorised credentials?
Do not assume that a station’s web player page is an API. A page designed for people may contain the title in HTML today and move it into a script, embedded player or different service later. Icecast’s server statistics documentation specifically advises against scraping its human-facing web interface and points users towards machine-readable alternatives. Read the Icecast server statistics guidance before building around a page scrape.
An audio URL and a metadata URL can also be different. For example, the audio may be delivered from one path while the status information is available from the station host’s status endpoint. Copying the audio URL into a browser source will not automatically produce a song title.
If the station uses Icecast, try the host with /status-json.xsl appended to it. The host must be the appropriate Icecast server, and the route must be available publicly. Do not treat that path as a universal radio endpoint. It is a concrete Icecast route, not a guarantee that every station supports it.
If the station is not Icecast, request its documented feed instead. Some platforms provide a JSON API, an XML feed, a player-specific endpoint or a control-panel integration. The right choice depends on the station’s software and configuration. A stable documented feed is preferable to extracting text from a page that was designed only for human visitors.
Before you involve OBS, open the candidate endpoint in a browser or an API inspection tool and confirm that it returns current data. Then compare it with what the station is playing. If the endpoint already shows an old title, the problem is upstream of OBS and an overlay cannot correct it.
Read the Icecast status JSON endpoint
For an Icecast station, the documented status JSON route is normally checked on the station host as /status-json.xsl. The response describes sources currently known to the server. Your task is to find the active mount and inspect its metadata rather than copying the first title-like value you see.
The response may contain a source object when there is one source, or a collection of source entries when there are several. The exact JSON shape can vary with the response and Icecast version, so do not hard-code the assumption that the active entry will always be in one particular nesting level. Inspect the returned document and identify the entry whose mount matches the stream your YouTube workflow is using.
A source entry may include a title field, often called title, containing a combined artist and track value. In other configurations, artist and title may be available separately or one of them may be absent. Icecast’s documentation warns that fields are not always present, so your overlay should handle an empty or missing value without displaying a broken error message.
A simple inspection process is:
- Open the Icecast host’s
/status-json.xslroute. - List the source or mount entries returned.
- Match the mount to the station’s active audio stream.
- Read the title-related field for that mount.
- Wait for a known track change and check whether the value changes.
The last step is important. A valid JSON response proves only that the endpoint responds. It does not prove that the station’s automation is updating the metadata. If the station’s playout system never sends a new title, the endpoint can remain technically healthy while showing an old song.
The endpoint can also be unavailable to your browser overlay because of access rules, network restrictions or cross-origin policy. A browser source is still a browser, so it may be prevented from fetching a resource hosted on another origin. A local helper can sometimes read the endpoint and pass only the current title to OBS, but that is a separate component to maintain.
Do not use Icecast’s administrative metadata-update function merely because you found it in the documentation. That interface is for authorised station operators changing mountpoint metadata, not a viewer-facing read method. Protect its credentials and use it only when you control the station and understand the consequences. For a YouTube overlay, you generally need to read the public metadata, not modify it.
Identify the active mount and title field
Many failed overlays are pointed at the right Icecast server but the wrong mount. A server may publish more than one stream, such as a high-quality main feed, a lower-bandwidth feed and a separate language channel. Each source can have its own metadata.
Use the mount name, stream URL and any descriptive fields to establish which entry corresponds to the audio you are presenting on YouTube. If your OBS audio comes from a local player, compare its URL with the mount information in the JSON. If the audio arrives through another route, ask the station operator which mount is intended for public listening.
Then decide how to present the value. A combined field may already read well as Artist - Song. Separate fields may give you more control over punctuation and line breaks. Avoid assuming that every title contains an artist, or that a hyphen always separates the two. Indian-language stations may also return transliterated, native-script or mixed metadata, so test the font and alignment in the actual scene.
A sensible fallback sequence is:
- show artist and title when both are present
- show the available title when artist data is missing
- show a neutral message such as “Now playing information unavailable” when no usable value is returned
- retain the last known value only if you label or design the overlay so viewers are not misled into thinking it is current
Whether you retain the last value is a presentation decision. Clearing the field avoids displaying stale information, but it may leave an awkward empty area. Keeping the previous value looks smoother but can be misleading when the station has stopped updating. For a serious channel, a small “metadata unavailable” state is usually more honest than silently showing an old track.
This is separate from audio reliability. If your stream has silence, clipping or inconsistent loudness, fix that in the audio path rather than hiding it behind the title overlay. The practical checks in audio settings for 24/7 streams cover a different failure, but the principle is the same: test the signal that viewers actually receive.
Render the metadata in an OBS source
There are two main ways to bring the changing value into OBS.
Browser overlay
A browser source can load a small overlay page that periodically requests the station’s JSON, extracts the active mount’s title and prints it in a styled element. This gives you control over font, colour, padding, background, wrapping and fallback text. It is useful when you want the same overlay to work across several scenes.
The page must know the correct endpoint and mount. It also needs permission to fetch the endpoint from the browser context. If the station does not permit cross-origin browser requests, the page may load successfully while the metadata request fails. In that case, a local helper or server-side proxy may be needed.
Be careful with credentials. Do not place private station keys, passwords or administrative URLs in a public browser source. A browser overlay is part of the presentation layer, and anything embedded in a page may be visible to anyone who can inspect it. For public station metadata, use the public read route supplied by the operator.
Set a refresh interval that is appropriate for the station rather than repeatedly requesting the endpoint without thought. The metadata may change only when a track changes, and the station may have its own limits or expectations. Handle network errors, invalid JSON and missing fields so the overlay continues showing a readable state.
Local helper and OBS text source
A local helper can poll the metadata endpoint, select the correct title and write the result to a text file. OBS then reads that file through a text source. This adds a process to monitor, but it avoids some browser cross-origin restrictions and keeps the formatting inside OBS.
The helper should write complete values safely. A partial write can cause OBS to read an empty or half-finished title. It should also distinguish between a successful response with no title and a failed request. Logging the last successful update time is useful when you are diagnosing a station that has stopped publishing metadata.
A text source is straightforward to position and style, and it can be duplicated across scenes. The trade-off is maintenance: the helper must run whenever the broadcast runs, and its file path must remain available to the OBS account. If the computer restarts overnight, the helper and OBS must both be included in the recovery plan.
Supported metadata plugins
A plugin can be convenient when the radio audio is already being played through a supported local media source. The OBS Project Forums listing for OBS Tuna describes support for sources such as VLC and MPD, along with other media-control or browser-player integrations. Its listing states an OBS 28.0.0 minimum and Windows/Linux support, as listed on the OBS Project Forums in September 2026. Confirm current compatibility before installing it.
That support does not establish that Tuna can read every arbitrary radio server URL or every Icecast JSON response. If the station’s audio is not being played through one of the plugin’s supported sources, the browser-overlay or local-helper route may fit better. Choose the source based on the metadata path you have confirmed, not simply on the fact that a plugin displays song information.
Test title updates in the scene
Build and test the overlay before you commit to an overnight broadcast. Add the browser or text source to the same scene that will be sent to YouTube, then check it at the output size you expect viewers to see.
First, test the visual state with a known title. Check that the text is not hidden behind another source, clipped at the edge or too small against the background. If the station returns long titles, test wrapping and truncation. A title that looks fine in the OBS preview can become difficult to read when it occupies only a small part of a mobile screen.
Next, confirm that the active mount is the one supplying the audio. Play or observe the station during a track boundary and watch both the endpoint and the OBS source. Do not claim the integration works merely because the initial title appeared. The important test is whether a later value reaches the scene without manual editing.
Test the failure states as well. Temporarily make the endpoint unavailable, remove the title field in a test response or use a station period when metadata is absent. The overlay should remain legible and should not expose a raw error, JSON document or technical URL to viewers.
Use YouTube’s private or unlisted workflow when you need to inspect the outgoing picture without making the test a public programme. Confirm that the title is visible in the actual encoded stream, not only in the local OBS canvas. If you are using a long loop, the guidance on testing a 24/7 setup with a burn-in is useful for planning longer checks, although a metadata overlay still needs a deliberate track-change test.
Finally, check what happens after a restart. Reopen OBS, reload the browser source or start the helper again, and confirm that the current title appears rather than an old cached value. A setup that works only until the first overnight restart is not ready for an always-on channel.
Troubleshoot stale or missing metadata
If the label never appears, begin at the endpoint rather than changing fonts in OBS. Open the endpoint directly and establish whether it returns a response, the expected mount and a usable title. If it does not, contact the station operator or host for the correct documented feed.
If the endpoint works in a browser but not in a browser source, investigate cross-origin access, HTTPS and network reachability. A local helper may be a more suitable route when the station does not allow direct browser requests. Do not work around missing authorisation by exposing private credentials in an overlay page.
If the label appears once and then becomes stale, compare three timestamps: the station’s actual track change, the endpoint’s returned value and the overlay’s last update. A stale endpoint points to the station’s playout or metadata updater. A changing endpoint but stale overlay points to the polling, parsing or caching layer. A changing overlay that viewers do not see points to the scene, output or YouTube path.
If the wrong song is shown, check the mount selection. Multiple source entries, relay streams and fallback mounts can make the first returned source the wrong one. Match the entry to the audio that is actually being sent to YouTube.
If the title contains unexpected characters, inspect the response encoding and the font used by OBS. Do not strip all punctuation or convert every value to plain ASCII without checking the language. A fallback font may display boxes or alter the readability of native scripts.
If the station exposes no metadata at all, there is no honest overlay value to retrieve. You can display a fixed station label, remove the now-playing area or ask the operator to publish a supported feed. Do not invent titles from the audio, scrape an unstable player page and present the result as a dependable integration.
Also separate metadata recovery from stream recovery. A reconnect may restore audio while leaving the overlay helper stopped, or the overlay may continue updating while the audio source has failed. Include both parts in your restart plan. If the whole broadcast must recover after a disconnect, the automatic YouTube live restart guide addresses that broader operational problem.
Choose the route that fits your overnight setup
A browser overlay is usually the most flexible route when the station has a public JSON endpoint and permits browser access. It keeps the title logic in one page and makes visual changes easy. Its weak points are cross-origin restrictions, browser caching and the need to handle malformed or missing responses.
A local helper with an OBS text source is better when you need to control the request outside the browser or when the endpoint cannot be fetched directly by a page. It gives you clearer logging and fallback behaviour, but it adds another process that must start, stay running and recover after a restart.
A plugin is worth considering when the audio already passes through a supported local player. It can reduce custom work, but its compatibility is bounded by the sources and integrations documented for that plugin. It is not a universal bridge from any radio URL to any Icecast metadata response.
For a computer-based setup, keep the station endpoint, mount name, fallback behaviour and restart steps in a short runbook. For an always-on channel, removing the computer from the overnight path can remove one class of failure, but it does not make missing station metadata magically available. StreamNeo is useful when your prepared video needs to keep running to YouTube without your computer switched on; the radio metadata still needs a public, supported source and a display method that has been tested for your station.
If your main content is a visual loop rather than a live radio player, decide whether the audio and metadata should come from the same source. A title from one station paired with audio from another creates confusing output. Review the watch-page and chapters guidance for a 24/7 loop as part of the wider presentation plan, then verify that the visible label describes the audio viewers actually hear.
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 change the broadcast title for every song?
Not as the normal on-screen now-playing mechanism. The YouTube broadcast title is metadata for the live broadcast, while a changing song label must be rendered in the video scene before it reaches YouTube.
Does every radio station support /status-json.xsl?
No. That route is a documented Icecast status JSON route, not a universal endpoint for all radio platforms. Confirm the station’s backend and request its documented metadata feed if it does not use Icecast.
Why does my endpoint show a title but OBS shows nothing?
The browser source may be blocked from fetching the endpoint because of cross-origin rules, or the overlay may be reading the wrong JSON field or mount. Check the endpoint, mount selection and browser-source errors, then consider a local helper that writes the title to an OBS text source.
Can I use the station’s administrative metadata URL?
Only if you are the authorised station operator and need to update the mount metadata. For a YouTube overlay, you normally need a public read endpoint, and private administrative credentials should not be placed in a browser source.