Quote:
Originally posted by djSpinnerCee
Ok -- wow, I misread that one --
|
Hee! It's okay.
Quote:
Originally posted by djSpinnerCee
What you may have to do is kick each relay so they can re-connect to get the curent stream title from the source -- this is because the stram title was never intended to be used as a show title [DJ name] -- so it is only read by the relay ONCE when it first connects to its host DNAS, it is not updated like the track title [see: MetaInterval=].
|
That would make a lot of sense, actually.
Quote:
Originally posted by djSpinnerCee
This is also important with respect to how the source DNAS and relays report to the YP -- when the main DNAS gets a new source, it will re-report the new station name to the YP -- however, since the relays still have their same source (they are not kicked upon source disconect[?]), they will contiunue to report and display the old station name but updated titles.
|
I imagine having the relays drop the source every now and then would also help prevent server-side buffering errors like the ones we seem to get every once and a while. Fantastic!
Quote:
Originally posted by djSpinnerCee
The cluster layout is important because -- in your case, the main DNAS should be only for the relays, not listeners, and should be configured to kick all listeners when the source drops. Then support all listeners on the relays, configured to not kick listeners upon source disconnect.
|
Brilliant! Why hadn't we thought of this before?
Quote:
Originally posted by djSpinnerCee
The station name/stream title is what identifies a station as "unique" [I use that word very loosely] to the YP, changing it for different shows will cause the YP to think each show is a different station(snip)
|
After considering this and discussing things with our other Admins (we hadn't payed any attention to the shoutcast site before this, to be honest- our listener base comes from elsewhere), we've decided to force the Stream title to read LT3M, which makes more sense in the long run.
DjSpinnerCee, you have been endlessly helpful, and I can't thank you enough! ...next on the list is finding a better way of configuring a failover stream... SC_trans is nice and all, but it's not smooth enough when automated for my tastes.
Thanks again for all of your help!