Multiple Legacy Servers with one Shoutcast V2 proccess
 

I can only get 64bit servers lately, so Im forced to use shoutcast V2.

But all of my clients are forced to use legacy mode/V1, due to their streaming software, site players, outaded radio directories that will never updated or become compatible with V2.

So im forced to use legacy mode. But I have like 10 radios to host, and I would like to do it through only one instance of the shoutcast server, for memory effieciency, management ease, etc. Is this possible with legacy mode on shoutcast V2?

i'm not quite following what you mean by legacy/v1 mode - so i'm going to have to assume you mean the mode of the sources connecting and not meaning you're running the v2 DNAS with yp2=0 (which will be removed in the next release whenever it happens).


if people aren't using compatible source software then there's little which can be done with the current v2 DNAS - as it's only the source connecting to the DNAS which is the limitation on the v2 DNAS supporting multiple source connections.


the 2 options from a development view point is a) allow for a legacy port to be defined and accessed for streams above #1 (which is all a v1 source will connect on currently) and / or b) look to do something like is done with sc_trans where an identifier of some sort is provided by the v1 source when it connects and the v2 DNAS then uses that to determine the stream it is trying to connect on (but that'd basically complicate the stream handling from what i remember of the code to try to multiplex something that isn't designed for it - hence why the v2 protocol was done).

of the 2 options, option A would be the simplest to do though that then uses up a load more ports per DNAS server for external source connections i.e. you'd need portbase, portbase + 1, all of the defined 'legacy stream ports' which in your case would be 11 ports (8000, 8001, 8002-8010 if going sequentially for all streams).

-daz

yp2=0 is what i refer to as legacy mode. I was really hopping that your solution A would be something I could do, since Im having a big problem with my supplied 64bit VPSes.

ok, i'm not sure why you've done that as doing yp2=0 should only be done if experiencing a specific issue with the v2 DNAS and it interacting with the official YP servers. as yes that option will make the v2 DNAS behave like a v1 DNAS but you instantly loose the support to provide multiple streams as you're wanting to do.

as such that option has nothing to do with client protocol support since the v2 DNAS will always provide a v1 compatible client stream if a v1 client connects (it's behaviour is to always provide a v1 compatible client stream if there is any doubt on what the client supports).


as for the options now that it wasn't what i thought you mean, option A would still be something that is being considered if only to aid in better supporting legacy sources to the DNAS.


as from re-reading what you've posted, it seems like you're under the impression that the v2 DNAS will only provide a v2 stream, which is not true as the v2 DNAS does whatever it can to provide the stream in the best protocol version for the client. i don't quite get how / why people keep thinking that (and would love to know where it is that people keep getting told that so something can be done to fix it).

-daz

I have people using Simplecast 2, and other outdated software to stream and some buggy flash players, that only work when yp2=0 is enabled. At least i think so.

with the older source software, option A is basically the solution.

with clients it could be any number of things though it usually stems from the in-stream title updates in v1 mode (though there is going to be the means to add a parameter to the stream which will prevent the title from being sent to the client which improved compatibility with all of the flash players i'd tried when i coded the change).

though it's all a moot point when there's no new build available to get at the features, and adding option A will delay the release (but it's something that keeps coming up so is probably better to delay the release further for something like that).

-daz

Thats what Im saying. But seems the solution isnt implemented, right? :(

I dont carte for title updates etc at all.

correct. it was an oversight with the initial implementations of the v2 DNAS but i don't think it was expected that there would be so much of an issue with 3rd parties not updating their source software to support the v2 protocol (as multiple stream support could easily drive software updates and sales). hence why it is something that needs to be implemented into the v2 DNAS before a new update is released.

you should do (and despite the above seem to) since as i said above it has the potential to mess with flash players (since most don't cope too well with non-frames in the stream i.e. it causes it to stop / skip).

-daz

You cant imagine how much trouble all this "not updating" has caused to me.

Anyway thanks for the help, seems I ll have to go with multiple instances, but making a proper init.d script for multiple instances will be a pain :(

i am more than aware of the issues that people are having due to there not being a newer v2 DNAS release (as some of the lovely abuse contact i've had from some people). but as i've explained in other replies, my hands are tied on a release being made.

and a new DNAS wouldn't have helped with what you want to achieve anyway since it still requires me to get time allocated to code the multiple legacy stream port support.


i am also more than aware that releasing a new v2 DNAS build which is not stable and also not providing the correct level of performance which is expected is not going to help anyone either.

-daz

Im not actually complaining about Shoutcast, but about all the people, applications, and sites involved in the streaming web radios ecosystem. At least here in greece, they simply refuse to update anything, resulting in the problems and situations mentioned. Anyway thanks again for the quick replies and help.

not that it'll help you at the moment, but i've put the handling in place now (needs some more testing) so it'll allow what is described at that bottom of http://forums.winamp.com/showpost.ph...12&postcount=7 to work (which i believe matches with what is wanted as long as the ports can be bound and accessed).

-daz

I use 64bit OS and have no issues using the DNAS/win32 v1.9.8 or V2.0 - Did you ever get this figured out?

have you actually read the posts as what you've asked has been answered.