Radio Player Not Working? Fixes for Streams, Now-Playing and Autoplay

A website player that won't play, or plays without showing what's on, is almost always one of a handful of problems. Most of them sit between your stream server and the browser, not in the player itself, and each one has a recognisable symptom.

Start by pasting your stream URL into the tester below. It tells you whether the URL returns audio, in what format, whether it is HTTPS, and whether it found now-playing information. Then find your symptom in the table and jump to the section.

Symptom, cause, fix

The stream won't play

The URL is a web page, not a stream

The most common mistake. Stream hosts give you several URLs: a public "listen" page, a playlist file (.pls or .m3u), a status page, and the actual audio stream. Only the last one plays in a website player.

Check what a URL returns with curl, which is on every Mac and Linux machine and on Windows 10 and later:

curl -I https://stream.example.com/live

Look at the Content-Type line. audio/mpeg (MP3), audio/aac or audio/aacp (AAC) and application/vnd.apple.mpegurl or application/x-mpegURL (HLS) are audio. text/html is a web page. audio/x-scpls or audio/x-mpegurl is a playlist file: download it, open it in a text editor, and use the stream URL written inside.

Some stream servers don't answer HEAD requests (-I) properly. If you get an error, fetch just the headers of a normal request and stop after five seconds:

curl -s -D - -o /dev/null -m 5 https://stream.example.com/live

The time-out message at the end is expected; the headers above it are what you want.

An http:// stream on an https:// site

If your website is on HTTPS (it should be) and your stream URL starts with http://, the browser treats the stream as mixed content. MDN's description of the rule: "<audio>/<video>/<img> HTTP requests on HTTPS pages are auto-upgraded to HTTPS (blocked if host is an IP address)^[1]".

So the browser quietly tries the HTTPS version of your stream URL. If your stream server has no HTTPS listener on that address, or the URL uses an IP address instead of a domain name, the stream fails. You can't fix this from the website. Ask your stream host for an HTTPS stream URL; most hosts provide one, sometimes on a different port or hostname.

Quick check: change http:// to https:// in your stream URL and run the curl -I command above. If it fails, your host needs to give you the HTTPS address.

The codec isn't supported

MP3 and AAC play in all current major browsers on desktop and mobile. Other formats, such as Ogg Vorbis, Opus or FLAC streams, are not played by every browser, and Apple's browsers are the usual exception. If your stream plays in one browser and not another, check the Content-Type and, if it isn't MP3 or AAC, ask your host or encoder to add an MP3 or AAC mount.

No song title or artist

Audio playing with no title means the player can't get your now-playing data. That data does not come from the audio itself in most setups; it comes from a status endpoint on your stream server or host, which the player (or the platform behind it) reads every few seconds. Where it lives depends on your host:

You can check each one yourself. For Icecast, open your server's address with /status-json.xsl on the end, and look for a title field for your mount:

curl -s https://stream.example.com/status-json.xsl

To check whether titles are being sent inside the stream, ask for ICY metadata and look for an icy-metaint header:

curl -s -H "Icy-MetaData: 1" -D - -o /dev/null -m 5 https://stream.example.com/live | grep -i icy

No icy-metaint and an empty status title usually means your encoder (BUTT, Mixxx, your playout software) isn't sending track titles. Turn on metadata or "send song titles" in the encoder settings.

A browser-only player has an extra hurdle: many stream servers don't send the CORS headers a browser needs to read their status pages from another website, so the request is blocked even though the data is there. That's why most players fetch now-playing data through their own server.

On RadioSiteMaker, the player detects the common hosts (Icecast, SHOUTcast, AzuraCast, Radio.co, RadioKing, Live365, laut.fm, Centova Cast, Caster.fm, RadioHost and others) and reads their status endpoints server-side, falling back to the ICY titles inside the stream. If your host isn't detected, or you want a specific feed used, paste the address into Settings → Now Playing URL in your dashboard and press the test button next to your stream settings. If that URL fails, the site falls back to reading titles from the stream and tells you so.

The player won't autoplay

This is not a fault. Chrome's autoplay policy: Muted autoplay always allowed; with sound only after user interaction, MEI threshold (desktop), or installed PWA^[6]. Safari and Firefox apply similar rules. A radio stream is audio with sound, so it starts when the listener presses play.

No website can bypass this, and players that appear to autoplay are either muted or benefiting from the visitor having interacted with the site before. Design around it: one large, obvious play button above the fold, on every page.

Audio stops when changing page

On a normal website, clicking a link loads a new page, and the browser throws away the old one, including its audio player. Embedded players and widgets live inside the page, so they stop too. That includes your stream host's embed and our own free now-playing widget.

The fix is a player that sits outside the page content: the site loads new pages into the existing document without a full reload, so the player keeps going. Doing this yourself on WordPress depends on theme and plugin support; building it from scratch is a real project. RadioSiteMaker station sites work this way out of the box. More options are in how to add a live player to your website.

HLS streams that only play in Safari

Safari plays HLS (.m3u8) natively. Chrome, Firefox and Edge on desktop need a JavaScript library such as hls.js to play it, and that library downloads the playlist and audio segments with ordinary web requests. Those requests are subject to CORS: the HLS host must answer with an Access-Control-Allow-Origin header that allows your website.

Check it:

curl -s -D - -o /dev/null -H "Origin: https://www.yourstation.com" https://hls.example.com/live/playlist.m3u8 | grep -i access-control

No access-control-allow-origin line means the host blocks browser playback from other sites; ask them to enable CORS, or use their MP3/AAC stream instead. RadioSiteMaker's player loads hls.js automatically for HLS streams, but it can't get around a host that blocks cross-origin requests.

Playback stops in the background on mobile

A website plays audio inside the phone's browser, and the phone's operating system decides how long a background browser keeps running. Being plain about what a website can't guarantee:

• Playback may continue with the screen locked or while using another app, but the system can pause or stop the browser at any time, for example to save battery, in low-power mode, or when memory is short.
• A phone call, another app playing audio or a notification sound can interrupt it, and the browser may not resume on its own.
• Lock-screen and control-centre controls for a website depend on the browser; don't promise them to listeners.

If background listening matters to a big part of your audience, a dedicated app is the more dependable route. See getting a mobile app for your radio station and the trade-offs in mobile app vs website.

Frequently Asked Questions

Why does my stream play in VLC but not on my website?

VLC plays almost any format, over plain HTTP, from a playlist file or an IP address. A browser on an HTTPS website is stricter: it needs the direct stream URL, over HTTPS, in a format it supports (MP3, AAC or, with hls.js outside Safari, HLS). Run the URL through the stream tester to see which of those is missing.

My stream URL has a port number like :8000. Is that a problem?

Not by itself. The problem is usually that the port only serves plain HTTP. Ask your host whether there is an HTTPS address for the same stream; it may use a different port such as 8443 or a different hostname.

Where do I find my stream's real URL?

In your stream host's dashboard, usually under "stream URL", "mount point" or "direct link". If you only have a .pls or .m3u link, download the file and open it in a text editor; the stream URL is inside. Check the result with curl -I and look for an audio content type.

Why do song titles show on my host's player but not mine?

Your host's player reads its own status API from its own domain, so it doesn't hit the CORS restriction your website does. Read the status endpoint through a server, use a platform that does, or check whether your host offers a public, CORS-enabled now-playing API.

Can I make my player start automatically when the page loads?

Not with sound. Browsers only allow audio to start after the visitor has interacted with the page, and no website setting can override that. Make the play button prominent instead.