Radio Metadata Not Showing? How to Fix Now-Playing on Any Platform

How Radio Metadata Actually Works

Before you can fix a metadata problem, you need to understand the chain. When a track starts playing on your automation software, metadata travels through four layers before it appears in your listener's player: the automation software sends it to the encoder, the encoder passes it to the streaming server, the streaming server embeds it in the stream or serves it via an API endpoint, and the web player or app reads it from there.

A break at any single layer means metadata stops at that point. The symptoms look the same from the listener's perspective — the now-playing display is wrong, blank, or frozen — but the fix is completely different depending on which layer failed. Diagnosing the exact layer first saves hours of guessing.

Layer 1: Automation Software (RadioBOSS, RadioDJ, AzuraCast)

The automation software is responsible for reading the track's ID3 tags (or file metadata) and passing the title and artist to the encoder. Most metadata problems that appear as "showing the wrong song" or "frozen on one title" originate here.

Check your track ID3 tags. Open the problematic track in a tag editor (Mp3tag is free and excellent). Look at the Artist and Title fields — if they're empty, the automation software has nothing to send. If the tags contain unusual characters (non-Latin scripts, special symbols), they may cause encoding issues downstream.

RadioBOSS: Go to Settings → Encoder → Metadata. Make sure "Send Now-Playing" is enabled and the format string uses %artist% - %title%. If metadata is being sent but not received by the server, check the "Metadata encoding" setting — it should match what your Icecast server is configured to accept (typically UTF-8).

RadioDJ: In Encoder Settings, verify the "Send metadata on track change" checkbox is enabled. RadioDJ reads metadata from the database record, not directly from the file at play time — so if you edited a file's tags after importing it, you need to re-import or refresh the track in RadioDJ's library for the new tags to take effect.

Layer 2: The Encoder Connection

The encoder (whether it's built into your automation software or a standalone tool like BUTT or Oddcast) is responsible for sending the audio and the metadata update to the streaming server. Metadata is sent as a separate HTTP PUT request to the server, distinct from the audio stream itself. If this request fails — due to a wrong password, a firewall blocking the admin port, or a protocol mismatch — the audio stream keeps playing but metadata never updates.

For Icecast, the encoder uses the source client protocol to send metadata updates. Verify the encoder's server address, port, mount point, and source password exactly match your Icecast configuration. Even a single character difference will cause silent metadata failure while the audio works fine.

For Shoutcast, the encoder must match the DNAS version (v1 vs v2). A common mistake is using a v1-compatible encoder (like an older version of BUTT) against a Shoutcast DNAS v2 server — audio works but metadata uses the wrong protocol format and is rejected.

Layer 3: Streaming Server (Icecast/Shoutcast)

Even if your automation software and encoder are sending metadata correctly, the streaming server can strip or mangle it. In Icecast, the most common server-side metadata issue is a misconfigured charset setting causing non-ASCII characters to appear garbled.

Check your Icecast config (/etc/icecast2/icecast.xml) for the charset setting:

<icy-charset>UTF-8</icy-charset>

If this is set to Latin1 (the old default) and your source is sending UTF-8, international characters will be corrupted. Set both the server charset and your encoder's metadata charset to UTF-8 for maximum compatibility.

Also check whether your Icecast mount point has metadata updates enabled. If you're using a custom mount configuration, ensure there's no <hidden>1</hidden> tag or metadata filtering in place. Review the Icecast error log (/var/log/icecast2/error.log) for any rejected metadata PUT requests.

Layer 4: The Web Player

If the streaming server's own status page shows correct metadata but your web player doesn't, the problem is in how the player fetches and displays now-playing data. Most modern web players don't read ICY metadata directly from the stream — they poll a JSON or XML endpoint on the server at a set interval (typically every 10–30 seconds).

Check what endpoint your player is polling. For Icecast, the JSON endpoint is http://yourserver:8000/status-json.xsl. For AzuraCast, it's https://yourstation.com/api/nowplaying/station_id. Open this URL directly in a browser — if it returns correct data, the problem is in the player's JavaScript. If it returns wrong or stale data, the problem is server-side.

Common player-side causes: the poll interval is too long (player shows a song that ended 30 seconds ago), the player is caching the API response aggressively, or the CORS headers on the API endpoint are blocking cross-origin requests from your player's domain. For CORS issues, add the appropriate headers in your Nginx or Apache proxy config.

Fixing Character Encoding Problems

If metadata shows as garbled characters (e.g., Café Latino instead of Café Latino), you have a charset mismatch somewhere in the chain. The text is being encoded in UTF-8 but interpreted as Latin1, or vice versa.

Fix the encoding chain end to end: set your automation software's metadata encoding to UTF-8, set your encoder's metadata charset to UTF-8, set your Icecast mount's icy-charset to UTF-8, and make sure your web player displays the API response as UTF-8. Any single inconsistency in this chain will cause garbling.

For RadioBOSS specifically: Settings → Encoder → Advanced → "Metadata charset" → change to UTF-8. For BUTT: in the Stream settings → Icecast/SHOUTcast → "UTF-8" checkbox — make sure it's checked.

AzuraCast-Specific Metadata Fixes

AzuraCast has its own metadata pipeline that bypasses some of the traditional ICY metadata path. It uses Liquidsoap to update metadata and exposes now-playing data through its own API. Here are the most common AzuraCast-specific metadata issues:

Metadata stuck on the wrong track: This usually means Liquidsoap is caching the old metadata. Go to the station panel → Restart Broadcasting. This restarts the Liquidsoap process and forces a fresh metadata refresh from the current track.

API returning stale data: AzuraCast caches its now-playing API responses. If you're querying /api/nowplaying/1 and it's stale, check the station's "API caching" setting under Administration → System Settings. Reduce the cache TTL or flush it from the admin panel.

Custom metadata for jingles showing wrong info: AzuraCast reads metadata from the file's ID3 tags. If your jingle files have the artist/title tags set to something you don't want displayed, edit the tags in the AzuraCast Media Manager (click the file → Edit) and override the display title without modifying the actual file.

Quick Diagnosis Checklist

Use this checklist to isolate the broken layer in under 5 minutes:

1. Check the streaming server's built-in status page directly. Does it show the correct song? If yes, the problem is in your player, not upstream.

2. Check the streaming server log for metadata PUT requests. Are they being received and accepted? If rejected, the encoder's credentials or protocol are wrong.

3. Check the automation software's "now playing" display. Does it show the correct song internally? If it shows wrong info, the track's tags are bad or the software's database is stale.

4. Check the encoder's connection status. Is it connected and showing "metadata sent" confirmation? If not, the encoder-to-server connection has a problem.

5. Check the web player's network requests (browser developer tools → Network tab). Is it polling the correct endpoint? What is the raw API response? This tells you whether the problem is in the data or in the player's display logic.