Im actually kinda bummed but if you are running v2.2.1 dont expect to have more than 300-400 tune ins without the DNAS crashing. Apparently its a well known issue with the 2.2.1 DNAS.

How to get around this?

I installed 2 more instances of DNAS. Set the main stream at 300 and set all the others as relays and they are at 300 limit.

you have to setup your PLS file properly. with the relays inside it so that when someone goes to listen to your stream via PLS file it will connect them to the next available stream that has an opening.

The cons of this.

If people only have your direct URL they wont be able to connect if your main stream is at capacity.

Why dont I roll back to an earlier version?
1. more and new issues will happen
2. I need the DJ port functionality for my broadcasters to just press connect and not have to worry about turning the auto dj on and off.

Hope this helps someone out.

Cheers.

A few corrections to the above...

If you have the DNAS correctly grouped (same authhash used) and they are publically listed, then if one gets to capacity, it will pass on listeners to other DNAS within the group until the listener gets a valid DNAS (assuming that there is one which has free capacity).

And you should always be using DNS entries for the DNAS (configured via destip which i hope the Centova software supports setting) as that makes life far easier if you need to add / change servers around instead of going with IP specific urls (which have not been the recommended way to do things for years now). It also makes things far better for the listeners - which all to often seems to be forgotten about by a lot of stations.

And technically, you could use the v1.x DNAS with the now deprecated v2 sc_trans if that is so wanted - it still allows you to have the autodj functionality. Though, it doesn't help when neither of those pieces of software have any official support now.

if all 3 DNAS are known to the SHOUTcast YP then if one is at capacity, they will be aware of the other 2 DNAS and will attempt to push listeners to them if the DNAS which is requested by the listener is not available.

it's not the true load balancing which should be present in the DNAS (since this is just helping to handle things being at capacity), but it generally works ok depending on how you're providing the playlist / Directory access to the DNAS i.e. if you dynamically create the playlist you provide, you could use it to help psuedo-load-balance things (i've known a number of stations do just that with generally good results).

when i said about DNS, i mean that anything the DNAS provides is configured to use bob.server.com:<port>/<stream> instead of 1.2.3.4:<port>/<stream> so you're then not IP based which is a pain to deal with if the IP of the server(s) have to change at a later date i.e. it makes it easier for listeners to be kept if you have to move to another host and so on.