This build is our new update and introduces new features as listed in the “Changes” section below, as well as addressing bugs reported in the previous build. It is recommended to update to this build as soon as possible over any previous DNAS builds being used due to the stability, security and other compatibility improvements it provides.

SHOUTcast DNAS v2.5.5 is our most stable release to date and we highly recommend all users to upgrade.

This release is now available for the following platforms:

Windows 32-bit (Windows 2000 and up)

Windows 64-bit (Windows XP64 and up)

Linux

Linux 64-bit

This release is currently not available for the following platforms:

BSD (8.x)

Raspbian (Raspberry Pi - works on RPi A/A+/B/B+ and RPi2 with the same compile!)

Mac OS X (Intel)

We hope to have builds for Mac, BSD & RasPi available ASAP.
For now, you will need to keep using v2.4.7 instead. Sorry.

Downloads

You can download the updated version of the DNAS via the main download page: http://www.shoutcast.com/BroadcastNow
Note that registration is now required.
For already-registered users, the download link can be found in your RMO.

EDIT 10 Sep 2017
The Windows builds are currently unavailable due to a couple of reported bugs.
We hope to have these bugs fixed asap.
In the meantime, the available Windows builds have been reverted to v2.5.1

If this is a new install then make sure to read through the information in 'Readme_DNAS_Server.html' and the related documentation as well as considering using the setup mode which should make it easier to get started over all prior 2.x builds (and 1.x based releases).

Finally, all current copies of the documentation are included with the installer / archive and is the recommended point of reference for this release. The information found online at http://wiki.shoutcast.com/wiki/SHOUTcast_Broadcaster for the DNAS server might still be out-of-date in places....

Reporting Issues

If you do come across an issue with the DNAS, then please post in this thread with as much information as possible about what you're doing at the time, the system you are using and anything else which will make it easier to understand what is or isn't going on with your install.

Posts relating to authhash management issues will be ignored as this is not the thread for posting such issues. The correct thread is here.

The RMO might still refer to 2.5.1 (and will be updated shortly), but the download links are for 2.5.5

EDIT: The RMO now also refers to 2.5.5, and the DNAS internal updater has also been updated to report/download 2.5.5

EDIT: 10 Sep 2017
The Windows builds are currently unavailable due to a couple of reported bugs.
We hope to have these bugs fixed asap.
In the meantime, the available Windows builds have been reverted to v2.5.1

Source DNS lookup is incorrect, regardless of RFC 1918; either public or private IP addresses as source show the same behavior:

Stream Source: xxx.xxx.xxx.xxx.vultr.com (192.168.121.131)

That hostname is actually the address where the SC admin panel was invoked, not the connected source.

DNAS is upgraded to its latest, build was downloaded automagically to my CentOS 7 x64 VPS.

I've seen it in previous builds, though. It seems to me that there was going to be an added line showing the connected admin IP/hostname, but for some reason that variable ended up in the "source". Cosmetic, but inaccurate.

Well, I went ahead and loaded 733.... and this is untenable. And DSP 2.3.5 is no better with it.

I experiencing the same thing as with the last update, the connection to source is resetting on every single song-change... and even more maddening, it only happens when there are people connected to the stream.

(NOTE: I've been using DSP 2.3.3 because the later ones can't handle playing various bitrate streams.... so anything less than 44 is sped up. We have a wide variety of audio in our library and the station 'shtick' is all that audio in one playlist, shuffled and played on random.)

Today early morning we just updated on of our production servers with the v2.5.5.733/posix(linux x64) Version. No disconnects and no other issues so far with 128kbit mp3 and 64kbit aac+. We use SAM Broadcaster in production and for testing purpose Liquidsoap as transcoders. Client tests done on most common browsers (html5) on Window, Linux and MAC. Player tests on SONOS, VLC, Winamp (what else) and other strangers.

There are problems with both Build 732 and 733 on Windows XP.
When I install, on starting SC2, the error message "not compatible with Normaliz.dll in your system (C:\windows\system32)".
However when I revert back to Build 724 there are no issues, everything works as it should.
So...something to do with these 2 new builds is causing the problem with Normaliz.

Sometimes BUTT connects and broadcasting. Broadcast for 1-2 hours and again this error appears.

Are they using the most recent version of BUTT? With a previous revision (build 724, I think) I had to email the creator who acknowledged, after testing, that there was an issue. He promptly updated the software.

Unless this is a new issue, I'd make sure users are using the latest and greatest version of B.U.T.T.

While browsing the forums I found a post from somewhere about how the DNAS still doesn't support SSL/TLS. I decided to give it a go with an https virtual host reverse proxy with Apache2.4 for Windows.

After researching the configuration for it I got everything working marvelously! I can access the DNAS admin pages over https just like I can any other SSL enabled site (with a valid certificate) AND I can STREAM OVER IT AS WELL! Very nice. When I checked the DNAS log I found that the DNAS is also X-Forwarded-For aware and shows the remote IP and not the proxy IP in the log with "(xff)" appended to it! Very very very very nice and a job (mostly) well done, kudos!

Only problem is, IP bans on X-Forwarded-For clients don't work at all. I believe that is a critical flaw and to rely on the proxy server to handle the potentially same bans as in the DNAS is counter intuitive and problematic for simple users or simple setups.

[/EDIT]
I just noticed that the status page is also showing only one unique listener for multiple xff clients from different IP address patched through the same proxy server or another proxy server (on a different front-facing port) connecting from the same IP.

For security reasons I would like to propose that the DNAS server can be configured to only accept and parse X-Forwarded-For headers from specified/allowed sources, would look something like AllowedForwardingForServers=127.0.0.1,192.168.1.100,10.0.0.100. The allowed proxy servers then could be secured to not pass X-Forwarded-For headers from malformed clients to spoof listener counts or from getting around IP bans.

After update from 2.5.1 Build 724 to 2.5.5 Build 733, we experienced an issue with the setting fixedbuffersize (1048576) wich previously worked fine. After some amount of time, the listener had to wait at least 20 seconds for the stream to start playing. After we changed to adaptive buffer, there were other kind of issues such as skips and pauses while listening to the stream (adaptivebuffersize was 15).
The only thing why we've updated is the issue with build 724 where the stream sometimes fails to start relay. However, this is better than not be able to listen to the stream (wait for a long time for it to start).

I have about 340 instances of SHOUTcast v2. My server has 8 GB of RAM. Only SHOUTcast v2 servers work there. The longer SHOUTcast v2 servers are running, the less RAM available. At SHOUTcast v1, I've never noticed the problem of excessive RAM usage.

Example: first week after run 340 SHOUTcast v2 servers RAM usage is about 1 GB, after two months RAM usage is about 7 GB and it's still growing.

dnas v2.5.5.733 win32 - when used as a relay everything is perfect unless i try to disconnect the relay from the source stream via admin interface. in the log, the stream will disconnect, but will immediately reconnect. tried disconnecting from source dnas (via kick). tried kick all relays... unconfiguring and doing a forced reconfig will stop the relay, but not the best solution since it will kill all streams, relay or not.

not really intended behavior - on every version before 2.5.5, "stop relay" from the admin interface on the relaying stream will not cause a reconnect, and the relay will not reconnect until you "start relay" again.

intended reconnect will occur if i kick the relay from the source dnas.

i see this on winxp and win10 - the winxp dnas is running as a service, the win10 dnas is running in a command prompt.