Station ID/Clustering

[MegaRock]

Been having this problem for some time and finally had time to do some testing but this is what I have. The auth-hash and config files are identical across all servers except for port changes and relay server address.

All streams start at a main distro server that I use because of low hops and latency and is on the cloud so it can be moved quickly if a problem arises at that location/datacenter. This shows the regular station ID... let's call it 87010. So far so good.

From this point three servers connect to this server. All but one show the proper station ID. One particular server has picked up a random station ID that will not go away. When I click the listen link on this server I get that server only in the playlist file.

When I hit any of the other servers I get the proper ID and all the servers including the one with the wrong ID in the playlist file so I assume all clustering is working right here.

Ironically I set up a secondary server on the same box having the issue. Set the port standard at 8000. Connected it THROUGH the server with the bad ID...and it gets the proper ID and all the servers.

About the only thing I can think of at this point is something at the YP end has that one particular server and port stuck in something?

http://stream1.megarockradio.net:8240 is the freak.

[djSpinnerCee]

i'm wondering if your issue is an artifact of the old v1 system of creating clusters -- remmber in those days the yp was the engine that drove cluster creation to the extent that a v1 dnas only reported its ip, port, and station name -- the yp would then provide a station id -- then later, the yp would create a cluster using i guess the common station name, and maybe other common dnas infos to create a cluster of a station -- this was a best guess, and probably why the authhash (and the rmo) was needed to authenticate a station owner.

to your issue -- it used to take time for a cluster to fully form -- but it was still based on ip-port combinations -- they would also remain after relays were down because the yp engine was not very robust -- i still believe that your rogue dnas is stuck with a remembered lone id that is being overriden by an authhash that allows it to become apart of your other dnas cluster, but prevents it from accepting the common id associated with the authhash shared by your other dnas servers.

why this happens is a mystery to me, but i do see it clearly.

you may have to down the rogue server until it times out of the yp, or change its ip and/or port to see if it would allow it to become "new" to the yp (i do remember the last time we visited this, those options were not really easy or possible)