Reputation: 85
URL Reference: http://m.gooplusplus.com/?radio
Audio URL (public): http://live.str3am.com:2010/#.mp3
HTML5 Player Source Code: http://www.terrillthompson.com/music/aap/
The public Aural Moon MP3 radio stream is easily played on my referenced Radio Jukebox site when using Android tablets or smartphones or when using Windows or Linux media programs like VLC.
The station does not play in any Linux or Windows browser from the reference web site.
Spoofing the navigator.userAgent
string to pretend to be an Android browser had no effect.
Radio Station is (P1). Any suggested fix?
UPDATE Relevant excerpt of Terrill Thompson's source code:
this.audio.addEventListener('error', function() {
var errorCode, networkState, errorMsg;
document.title = 'Error';
errorCode = $this.audio.error.code;
networkState = $this.audio.networkState;
if (errorCode == 1) {
errorMsg = 'Waiting'; //actually, aborted I think
} else if (errorCode == 2) {
errorMsg = 'Network error';
} else if (errorCode == 3) {
errorMsg = 'Media decoding error';
} else if (errorCode == 4) { //4 = media source not supported
if (networkState == 4) {
errorMsg = 'Firefox 3.x File Load Error! ';
} else { //if it's not Firefox 3.x, then it must really be a media source problem
errorMsg = 'Error reading media source';
}
} else {
errorMsg = 'Unknown error: ' + errorCode;
}
document.title = errorMsg;
}, false);
Upvotes: 0
Views: 799
Reputation: 163478
The stream you are linking to is running a SHOUTcast server. There are two common problems with SHOUTcast streams. The one you ran into is that SHOUTcast sends the web admin/status interface to all clients with Mozilla
in their User-Agent
string. Therefore, when you try to stream with most browsers, instead of audio data you get a web page.
You can get around this problem by telling the server to override your user-agent string by appending a semicolon ;
to the end of the URL:
http://live.str3am.com:2010/;
The server then sees your user-agent string as MPEG OVERRIDE
, giving you the stream.
The second problem that you will inevitably run into is that SHOUTcast servers do not send a proper HTTP response on their status line. Instead of:
HTTP/1.0 200 OK
SHOUTcast servers send:
ICY 200 OK
Most browsers will accept this, but this is increasingly becoming not the case. Firefox notoriously broke compatibility with these broken headers awhile back, but has since resolved the issue (likely temporarily). I suspect this is the issue you have with Internet Explorer 11, since the test stream I gave you (which is pure HTTP) works fine.
Finally, I should point out that your appendage of #.mp3
shouldn't do anything. It certainly doesn't have anything to do with the server sending you content, and browsers don't care about what the "file name extension" is... they only care about the Content-Type
response header. If that is working for you, there is likely some crazy hack in place in what you are using to play streams, and I would be vary wary of using it.
Upvotes: 1