Shoutcast v1 assumed backup & no Shoutcast listing

[4quality1]

I have two station begin streamed by two different instances of sc_serv v1 on a linux box. One of the stations is listed in the directory, and the other is not. YP seem to mistake one station as a backup for the other. I thought I could get away from the association by changing the ports, but YP seems locked on - now listing three or four backups.

From extensive reading of the forums I see that this is likely a bug in YP and probably not soon to be fixed. A manual fix is required that may revert from time to time.

Can someone please un-associate these streaming ports on ip 199.175.55.69: 8100, 8110, 8120, 8200

Also, if there is anything I can do on my end, please let me know.

Thanks.

In the logs, I see:

<10/16/13@11:57:46> [yp_add] yp.shoutcast.com added me successfully
<10/16/13@12:07:46> [yp_tch] new backup server 199.175.55.69:8100
<10/16/13@12:07:46> [yp_tch] yp.shoutcast.com touched!
<10/16/13@12:17:46> [yp_tch] new backup server 199.175.55.69:8100
<10/16/13@12:17:46> [yp_tch] yp.shoutcast.com touched!
<10/16/13@12:27:47> [yp_tch] new backup server 199.175.55.69:8100
<10/16/13@12:27:47> [yp_tch] yp.shoutcast.com touched!
<10/16/13@12:37:48> [yp_tch] new backup server 199.175.55.69:8100
<10/16/13@12:37:48> [yp_tch] yp.shoutcast.com touched!
<10/16/13@12:47:49> [yp_tch] new backup server 199.175.55.69:8100
<10/16/13@12:47:49> [yp_tch] yp.shoutcast.com touched!

[DrO]

the comment you quoted was true when made though there was a YP fix made almost 2 months ago which resolved the issue as best as possible - it is not a 100% fix (as that is the nature of v1 DNAS based listings) though with the scenario you have (multiple streams from the same IP and different port), it should now stay split (now that i've changed the stationid).

the only way to ensure control over how a stream is listed and clustered / grouped is to use a v2 DNAS (since that provides a way to specify a fixed data point which is not possible with the v1 DNAS and is what causes some of these weird clustering issues).

[4quality1]

Not sure it it matters, but this is the associated URL

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

[DrO]

not really as i'd already got the IP address from your first post. one will use 193532 and the other will use 293532. it'll take ~30mins for the search results on shoutcast.com to reflect the fix.

[4quality1]

First, Thanks!

How does YP associate a v1 stream with a station ID? by IP/Port, stream title, or some combination?

Does this mean that I am locked to these two ports? That is, would YP know what to do if the port numbers changed again? If I setup an AAC stream in addition to, or in place of, the current stream, will YP handle it?

Thanks.

[DrO]

the YP looks at a number of values to determine / maintain the stationid. but if too much changes or it cannot be certain then it can in some cases do as you saw (which was a bug) or it'll just provide a new stationid.

so if you just change the IP address or port then it should maintain it, if you change both at the same time then there's no guarantee. that is one of the scenarios v2 + authhash can cope with as you're not tied to the IP address / port of the stream, just the authhash.

with a different stream format, if everything else is the same, and it's just the format that has changed (bitrate will also be taken into account) then it'll generate a new stationid or if it had already been known (and still is known) to the YP, it then may re-use the prior stationid for that instance of the stream (which is what it's meant to do, just if it clustered incorrectly to begin with then you get into the issue you first had).

basically, most of the time it works if using a v1 DNAS but there are cases (either from you or from us) where it can break that and so the stationid changes. whereas a v2 DNAS when correctly setup will maintain the stationid as long as the listing and the authhash are in your config file(s) and in the YP system.

[4quality1]

Understood. I think I know enough to move forward.

I can confirm that the streams are no longer each others backups, and the listings are correct.

Thanks!