Troubleshooting Shoutcast streams

Owned by Support Triage
Last updated: Nov 17, 2023
4 min read

Shoutcast (formerly SHOUTcast) is a service for streaming media over the Internet to media players that uses its own cross-platform proprietary software. Shoutcast is used for streaming digital audio content, primarily in MP3 or High-Efficiency Advanced Audio Coding (HE-AAC/AAC) formats. The most common use of Shoutcast is for creating or listening to Internet audio broadcasts; however, the platform can also support video streams. The software is available to use for free or as a paid cloud service with additional professional features.

A large number of stations use Shoutcast as a platform for streaming and this platform has been observed to occasionally cause problems for listening to a station’s stream via Android devices.

Take the example of Salisbury Radio in the UK that had the following stream URLs set up in Radioplayer Cloud:

If we paste the above URLs into Chrome or Firefox as a quick check to see if we can listen to the stream via a browser, we get taken to a status page for Shoutcast as follows:

And the Shoutcast Stream Status page helpfully provides the following URLs for the streams via a Listen button:

But when we try to check those streams using VLC, we still get errors - in this case, it appears that the .pls file is pointing to a defunct stream that is not going to play:

The .pls file can be unpacked to show the following:

[playlist] NumberOfEntries=1 File1=http://securestreams6.autopo.st:8001/stream Title1=Salisbury radio Length1=-1 Version=2

However the stream to which the .pls file is pointing is dead:

And the same for the other stream example:

[playlist] NumberOfEntries=1 File1=http://securestreams6.autopo.st:8003/stream Title1=Salisbury Radio Length1=-1 Version=2

Salisbury Radio reported to Radioplayer that their station could not be heard in the mobile app on Android. This was checked out and verified as can be seen here:

The solution to this problem was to separate the Android streams from the iOS streams and place a suffix on the end of each Android stream to indicate to the Android app that these URLs are two audio streams to be played:

And, indeed, the format of these URLs now tells the Chrome and Firefox browsers that these are playable audio streams:

Why does this happen? Shoutcast determines what to serve - either a status page or stream - based on the User-Agent request header. This header indicates what client is trying to connect to the server. When connecting with a browser, the User-Agent might look something like this:

Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2228.0 Safari/537.36

But if we connect with VLC, the User-Agent request header might look like this:

NSPlayer/7.10.0.3059

The User-Agent for the Radioplayer app on iOS is this:

iOS: Radioplayer/7.7.3.93 ios/16.3.1 AVPlayer/5.0.0 (Swift) Radioplayer Worldwide Ltd

 And the User-Agent for the app on Android is this:

Android; Radioplayer/7.7.3.93 android/13 ExoPlayer/2.18.1 Mozilla/5.0 (Linux; Android 13; IN2023 Build/RKQ1.211119.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/119.0.6045.67 Mobile Safari/537.36 Radioplayer Worldwide Ltd

Shoutcast doesn't have a list of all the browsers. Instead, it looks for only one keyword: Mozilla. This is found in most browsers' User-Agent strings, for historical reasons. If Mozilla is in the User-Agent request header, then Shoutcast sends the admin page. For all the others, Shoutcast will send a stream - therefore the listeners on iOS can access these Shoutcast streams and users on Android will probably get an error message.

This can create problems. Most notably, it means you cannot listen to the stream in a browser. If you load that stream on a web page, the User-Agent string will contain Mozilla, and the Shoutcast server will send the admin page, causing an error with the player. And if you access a Shoutcast stream via the Radioplayer app on Android then you are likely to get an error message, as above.

However, there is a workaround for this. If in the request path you add a semicolon ;, Shoutcast will ignore the actual User-Agent and will replace it with MPEG OVERRIDE - and this causes the server to send the actual radio stream (instead of the Status page).

Because of this, it is common to see a semicolon ; in the path for Shoutcast streams. And because anything after the ; is ignored, the broadcaster can place anything there to decorate the stream with something meaningful such as the codec of the stream served, for example, ;stream.mp3 and ;stream.aac.

The main thing is that a Shoutcast server will ignore everything after the semicolon - so you can put whatever you want after it - and serve up the audio stream instead of the server Status page.