How to reverse engineer sid from 2.0 stream url?

[Kansuke]

Let's say that there is a stream server running with shoutcast 2.0.
It has 8 streams running, where for instance rock.aac is stream number 6.

However, I do not know that. I only know the following URL:

http://192.168.0.1:8000/rock.aac

How can i find out, with knowing only the full stream url, that above url is stream #6 (sid=6)?

Any help is appreciated.

[DrO]

if a custom streampath has been specified then if you're not the owner than you're not really meant to know the sid of the stream and if you are the owner then you should know what you've set to begin with.

though it's simple enough to find by accessing the /stats?sid=X page (where X is the sid) or using the /statistics page that will be in the next release (assuming public stats are enabled). or just looking at the different streams as shown on the root page of the v2 DNAS.

though it then leads to the question of why you're wanting the sid of the stream from the custom streampath to begin with?

-daz

[Kansuke]

Thanks for the quick reply

I disagree that if you're not the stream owner, that you should not know the exact SID.
After all the stats are publically available.

The idea is to get the song information, by polling the /stats?sid=#
That is why there is a need to get the sid from only knowing the full stream URL.

I would have expected something like: /stats?streamlist, that would output:
<SHOUTCASTSERVER>
<STREAMCOUNT>2</STREAMCOUNT>
<ACTIVESTREAMS>1</ACTIVESTREAMS>
<STREAMPATH1>/test.aac</STREAMPATH1>
<STREAMPATH2>/test2.aac</STREAMPATH2>
</SHOUTCASTSERVER>

If a stream owner does not want stats to be available, it can be switched off, right? Then the streamlist should not output too.

Thanks again for any help concerning this.

[DrO]

Originally Posted by Kansuke

I disagree that if you're not the stream owner, that you should not know the exact SID. After all the stats are publically available.

true, but the whole point of the custom streampath is so owners can provide a streamurl which makes more sense for what they want. yes there are probably cases where people want to work it out but that's going to be less so than valid stream clients.

Originally Posted by Kansuke

I would have expected something like: /stats?streamlist, that would output:
<SHOUTCASTSERVER>
<STREAMCOUNT>2</STREAMCOUNT>
<ACTIVESTREAMS>1</ACTIVESTREAMS>
<STREAMPATH1>/test.aac</STREAMPATH1>
<STREAMPATH2>/test2.aac</STREAMPATH2>
</SHOUTCASTSERVER>

the upcoming /statistics page will do that but not in that format - it's just all of the /stats options combined with the streamid in the start of the entry.

Originally Posted by Kansuke

If a stream owner does not want stats to be available, it can be switched off, right? Then the streamlist should not output too.

which is what is already being worked on as part of changes for the next release as this is something requested by our partners. only issue is that too many people don't bother to update their version of the DNAS hence far too many initial 2.0 beta DNAS still being used 18months after it came out and 1.5months after the v2 DNAS came out of beta. so we can add in all of these nice features / controlling options so people like you can if needed get information but if station owners don't upgrade then you're still screwed on getting the information.

or maybe that's why they're still on the initial beta as it provided very little public information, heh.

-daz

[Kansuke]

Originally Posted by DrO

the upcoming /statistics page will do that but not in that format - it's just all of the /stats options combined with the streamid in the start of the entry.

So that means with or w/o the streampath added as a xml value under the streamid?
Because that would solve getting the sid because then it would be linked to the streampath in one statspage.. just wishful thinking here

No offense, but what good is it to have public information, that needs an exact identifier to be able to get to it, which is unknown because there is no direct relation to the streampath. The streampath+stream server url is of course likely to be used as the common stream url.

Another solution would be just to make it possible to have stats?streampath=test.aac.. that would make it more logical and usable.

Right now i would have to instruct my users to add the exact SID to fetch song information, which is well... not really wanted. Just the stream URL should be sufficient.

Again, my thanks for your replies. Trying to do my best to support SC2, but do not see a way to do this at this time.

[DrO]

Originally Posted by Kansuke

So that means with or w/o the streampath added as a xml value under the streamid?
Because that would solve getting the sid because then it would be linked to the streampath in one statspage.. just wishful thinking here

i've attached a preliminary version of what is likely to be in the final version when accessing server/statistics (without any params, etc) which is all of the /stats options for known/configured streams as well as some overall server stats.

Originally Posted by Kansuke

No offense, but what good is it to have public information, that needs an exact identifier to be able to get to it, which is unknown because there is no direct relation to the streampath. The streampath+stream server url is of course likely to be used as the common stream url.

because that's what partners want when hosting separate streams on the same DNAS. the whole method is based around the sid (that's what was in place when i took over things) and that's how it's remained as that's what partners want and in general doesn't affect most people using it i.e. those who need to know the information, not for those curious. am sure you'll keep disagreeing with that, but that's what is provided for functionality for the time being against prior decisions made on how to implement multiple stream handling.

Originally Posted by Kansuke

Another solution would be just to make it possible to have stats?streampath=test.aac.. that would make it more logical and usable.

maybe so but that's then adding in mass of extra processing on things which is likely to cause more grief than benefit. i will make a note and consider it (for any sid?=x access), but that's not something that'll likely happen soon.

Originally Posted by Kansuke

Right now i would have to instruct my users to add the exact SID to fetch song information, which is well... not really wanted. Just the stream URL should be sufficient.

/stats and the older 7.html was never meant for client users to use, it's just an unfortunate effect of being a public page. and i really don't see why they would need to know that unless you're doing hosting for other people? (as it is unclear from your replies still what is the need for such information).

-daz