Developer API help

[VimFueago]

Getting some weird behaviour, and wondering if I have missed something in the API docs.

I run my query, and in the response, I get station ID, and with this, Base URLs.

To "tune" to the station, I then need to make a web request to get the stream URL in playlist format (either PLS, M3U or XSPF) like so:

String url = "http://yp.shoutcast.com/"+ currentSelectedStation.getBase() + "?id=" + currentSelectedStation.getStatuionID() ;

This works for some stations, but sometimes the PLS file contains the actual stream, and sometimes it takes me to the shoutcast status page for the stream (???)

For example:

I found a station titled "Metal Express Radio"

and got the pls file:

code:
http://yp.shoutcast.com//sbin/tunein-station.pls?id=1376628

The URL in here is not the stream, it links to the stream status page:

code:
http://5.135.154.69:11590

What have I missed here? Thanks.

[LStratmann]

Hello VimFueago,
Is it possibly due to the SHOUTcast version?

Example: Your example had SHOUTcast Server v2.5.5.733/posix(linux x64).

Let's take my radio with the ID 99504922 as an example and see that the correct URL is displayed. (I use SHOUTcast 4 Business)

If we use the station with the ID 1348242 we can see that it contains the correct streamURLs. These use Shoutcast Server v2.6.0.753/posix(linux x64). So as far as I know the latest version.

I hope I could help you a little bit with this.
Luca

[VimFueago]

Your example is what I see for the majority of searches on the radio index. But occasionally In find stations like the one in my example.

is this an error on the shoutcast end? Or is there something I need to do? if I visit the status page, there is a listen link, but shouldn't that be in the PLS file?

Not quite sure if I need to fix something in my app I am developing.

[LStratmann]

I can hear "http://5.135.154.69:11590" through my VLC player without any problems.

[VimFueago]

Yeh, that's weird. I'm sending this stream URL to Chromecast, and it's rejecting it.

It appears, to my newbie eyes, that the server is redirecting to the stream URL if it think it's a mediaplayer connecting, or redirecting to a status page if the server thinks it's a web browser.

[VimFueago]

Anyone? This is causing a large number of my station searches to fail.

Is this forum the only source of developer API support?

[VimFueago]

Interestingly, using the example stream at the start of the thread, the eventual stream is this:

http://5.135.154.69:11590/;

the status page is

http://5.135.154.69:11590

[VimFueago]

But that fix only works on broken PLS stream URLs, it breaks working ones :-(

[LStratmann]

Hello,
Are you sure that you cannot play the URL without /;? It works for me e.g. with iTunes or VLC without any problems.

[VimFueago]

No, it doesn't work its rejected by the player (as I assume it gets the status page at that url). I suspect some players have some client side magic going on to work around it, or the server understands some useragents and delivers stream rather than status page.

[DJ Egg]

If there's no mountpoint/streampath specified (i.e. nothing after the ip:port) then can you not parse the stream url as ip:port/stream ?

i.e. you'd need to add /; or /stream to the end of the url if it's not already specified in the .pls

[VimFueago]

Thanks.

In Java (Android), I have done this, and tested a couple of sites that I had problems with, and a couple that worked, and this appears to have sorted the issue. Will do some more testing.

URL u = new URL( PLSUrl );
if ( u.getPath().isEmpty() )
{
PLSUrl += "/;";
}