Hello,
i will use the Shoutcast v1 with the SC Trans v2.

I cannt select this autodj when i use shoutcast 1.

Why?

Please Add this.

Thank You

Hi,


You'll have to install another autoDJ software (ices-cc recommended), one that Centova Cast supports to work in configuration with Icecast and Shoutcast v1.

Instructions for adding additional software are available here:
http://www.centova.com/doc/cast/installation_manual/07_adding_additional_software

not that it matters with the demise of sc_trans as such, but sc_trans can be used to connect to a v1.x DNAS (which it's setup to use the v1.x protocol by default so it can connect to a v1.x DNAS more easily).

You are, of course, entirely correct DrO that sc_trans2 can source a Shoutcast v1 server. This just hasn't been implemented in Centova Cast

It's possible that Steve hoped people would migrate away from Shoutcast v1 and didn't want to invest more time on enabling features in Centova Cast for it.

I for one have little trust in SHOUTcast v2 because of this mp3 key issue (and they are still not for sale anywhere), it seems they (Radionomy) could just shut all SHOUTcast v2 streams down whenever they like, they have already made the YP issue a nightmare in past months.
At least with SHOUTcast v1 there is nothing they can do to stop the music, I do remember I had SHOUTcast v1 with sc_trans working in the old Centova v2 but the playlists would not work.... I wonder if that could be corrected?
SHOUTcast v2 does run good, clients love all the features, but the YP Hash is a pain and seems to just go down for many for no reason, then the clients blame us and are angry because they have to keep recreating the YP hash, that along with all the questions about the future of SHOUTcast makes me look at both SHOUTcast v1 and Icecast a lot more.... the 2 that are guaranteed not to go down

A good example was yesterdays YP issues where directory returned 480 error

http://forums.winamp.com/showthread.php?t=377285

I spent yesterday almost whole day to explain some of my customers that this is not our issue but YP directory :/

Maybe I'm exaggerating but sometimes I think that Radionomy wants to close us down to get more customer for their "free" services....

I for one have little trust in SHOUTcast v2 because of this mp3 key issue (and they are still not for sale anywhere), it seems they (Radionomy) could just shut all SHOUTcast v2 streams down whenever they like, they have already made the YP issue a nightmare in past months.

the MP3 key issue is only specific to sc_trans and is all down to AOL and lawyers getting involved with products. since all MP3 encoding is meant to be correctly licensed and most of the encoders out there don't do that whereas sc_trans got forced to have to pay something. and as i've posted on the official forums, it's unlikely we'll see sc_trans come back anytime soon (and it's not like there aren't alternative options anyway - yes i know that doesn't help your customers, but it's just how things are for the time being).

however, there is _nothing_ i repeat _nothing_ in sc_trans which phones home or does anything to verify the license key (so you can run it offline or in restricted access setups). so there is nothing that could be done to take down stream as you're implying.

SHOUTcast v2 does run good, clients love all the features, but the YP Hash is a pain and seems to just go down for many for no reason, then the clients blame us and are angry because they have to keep recreating the YP hash

there is no reason to keep having to keep recreating authhashes and it should not be happening at all, unless it's not being preserved in the config files used to control the DNAS with - as that's the only place where they are stored on the local machine running the DNAS.

A good example was yesterdays YP issues where directory returned 480 error

http://forums.winamp.com/showthread.php?t=377285

I spent yesterday almost whole day to explain some of my customers that this is not our issue but YP directory :/

Maybe I'm exaggerating but sometimes I think that Radionomy wants to close us down to get more customer for their "free" services....

what happened yesterday was required back-end work to deal with future scaling requirements and was a needed change. yes it caused some issues but if using a current v2 DNAS, it's only being listed that was affected (same as with the v1.x DNAS) and listeners werel still be able to connect to the stream(s). yes it's not ideal that there's been issues but it's all part of being pro-active after having time to review things after the very quick migration of the platform in February away from AOL - or we could just not bother and wait until things fail (as that was done at times previously and how everyone complained!).

That's what I don't  understand DrO, I assumed that when I bought the mp3 key, my name and key was entered in some database somewhere. How does sc_trans know my name and key are valid, if I switch just  one digit of my name or key it does not work. the software was written before I bought the key so it can't be stored within that. It's not stored on my server I know that and that is why it bothers me a little, someone has control of that database/info -- the only thing I can think of is a bunch of keys were generated before they went up for salei

the details were at most stored in the Digital River store, which stored the key against the purchase details so it could be retrieved at a later date.

however sc_trans _never_ hit that for checking things or anything else as the validation of the details is done purely in sc_trans and treats it as valid if the details validate correctly according to the code it internally uses. it was done like that since there was never a guarantee that someone using sc_trans would have it open to the internet to be able to validate (and i suspect it was deemed more work than necessary - since it was added before my time) and so it just does a local validation without a server check).

finally, there are no pre-generated keys in sc_trans or anything else like that (which i think is what you're getting at by your last sentence) and is why if you re-use someone else's details or even a generic key, there is no way to track it (as i've tried to hint at numerous times as much as i could under the old regime but kept not being understood). and since it's effectively a discontinued product, it probably doesn't matter to much now if people just re-use the unlock keys from someone else since no one can track things and no one is collecting money to pay the licensing companies anyway (which is where it was going) and is just the same as what ices and others don't do.

Thanks for that info DrO, that's good to know I feel a little better about it now

The YP Hash has still  been a huge pain, it's hard to explain to new clients, and new SHOUTcast users why it  sometimes fails to create, or sometimes just stops working for whatever reason and will make it so nobody can even listen untill they fix it or switch to private server.

I have created a video to assist them but many still have problems, mainly they use in valid characters in the description field.. it's just a lot to do for some, I just recommend they do not even use it and leave it disabled... if they want listeners they can list in TuneIn or iTunes. This is one thing SHOUTcast 1 did well -- it was either listed in the director or it wasn't

The YP Hash has still  been a huge pain, it's hard to explain to new clients, and new SHOUTcast users why it  sometimes fails to create, or sometimes just stops working for whatever reason and will make it so nobody can even listen untill they fix it or switch to private server.

if it fails to create with the current v2.2.1 DNAS, it won't block listener connections. that was only something with the v2.0 builds and was done with the best of intentions i.e. to make it obvious something wasn't right, but as you note, it caused more issues. hence v2.2.x being made more v1.x like.

I have created a video to assist them but many still have problems, mainly they use in valid characters in the description field.. it's just a lot to do for some, I just recommend they do not even use it and leave it disabled... if they want listeners they can list in TuneIn or iTunes. This is one thing SHOUTcast 1 did well -- it was either listed in the director or it wasn't

where possible the v2.2.x DNAS will auto-create it, but so many streams are not correctly setup or have junk put in their source software for titles, etc that the DNAS will not attempt to make an authhash if it means that if listed listeners would not be able to easily find it or it'd cause issues (e.g. 'my station name' is a generic station name that is intentionally blocked).

yes v1.x is simpler in that manner, but when having to wade through the crap it puts in the system (bad genres - which get mapped to 'misc', wrongly encoded title update and a whole slew of other issues), something which blocks that i think is better. sure it'll annoy some people but the whole thing with being listed is to give listeners the best experience to find you and if a station cannot care about such things, then it's probably better they aren't listed / broadcasting.



and the whole point of the authhash is to act as a fixed piece of data about the stream(s) so they will be reliably listed (once the authhash is created) and that they can maintain a static station id (which is not possible with the v1.x DNAS) and that means you don't have to keep updating the station links if the IP of the DNAS changes (which is why we advocate people using DNS names for the stream servers which the v2.2.x DNAS far better supports than what the v1.x DNAS could do). and it also means that you don't have to necessarily rely on the information for the stream being correctly done in the source software as it can be managed via the DNAS instead and i don't see how that's anymore different than signing up to tunein or other services to get listed.

as fundamentally it is there to help resolve the issues present in the v1.x system and i know people don't like it, but the v2.x system resolves the core issues with how the v1.x system works (preventing against incorrect clustering and simplifying the YP implementation for v2.x listings) allows for doing all of the location / country filtering which people demand from the API we provide but with a large number of people still using v1.x DNAS, it's just not worth enabling that API feature, despite it doing what is being demanded.

and yes there are somethings which could be done better with the authhash implementation from the start (though authhash disappearing from confilg files has to be due to an external issue or from the v2.0 release), but there's not much else i can think off and for what it does to improve the SHOUTcast platform capabilities vs the downsides, they are just not comparable. and i know people will still keep using the v1.x DNAS, but no one supports that version of the DNAS anymore (anything from Radionomy will be v2.x based and AOL long gave up on the v1.x DNAS) and it's not like it's not already possible to relatively easily hack into a v1.x DNAS which with all of the things like heartbleed and open security vulnerabilities against the v1.x DNAS, i'm shocked people refuse to update a 7-8 year old version (and there are people out there still using v1.8.x builds of the DNAS!).