SHOUTcast DNAS 2.4.2 (Build 167) 30th October 2014

[DrO]

This build is our new update and introduces new features as listed in the “Changes” section below, as well as addresses bugs reported in the previous build. It is recommended where possible to update to this build over any previous 2.x builds due to the stability and other compatibility improvements it provides.

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
• BSD (8.x)
• Raspbian (Raspberry Pi)
• Mac OS X (Intel)

Downloads

You can download the updated version of the DNAS from the main download page here for all of the supported versions.


Changes

Build 167 (30th October 2014):

• Fixed issues with not finding cacert.pem in the same location as the DNAS program file which was preventing YP connectivity working (2.4.1 build 164 specific)
• Fixed broken relative config file handling not working correctly with init scripts and 3rd party control panels (2.4.1 build 165 specific)
• Changed some of the log and admin page output to better show the actual filepath being used for log and configuration files (helpful for determining path loading issues)
• Changed handling incase the cacert.pem file cannot be found to be more forgiving for the time being (futher changes will follow in later builds)
• Removed 'Error writing to console' log messages when screenlog=1 (default) and the shell the DNAS was started in is closed whilst the DNAS is still running e.g. due to OS defined timeouts - always use screenlog=0 if running the DNAS and you do not need it sending log output to the console

Getting Started

If you already have a running instance of the 2.x DNAS then there should not be any issues with replacing your current version with this new version.

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 only relates to the build 29 release (this will be updated by the end of October-ish).


Reporting Issues

If you do come across an issue with the DNAS, then please do 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.


Known Issues

The following are known issues with the current 2.x DNAS release that are not currently fixed / fully confirmed as needing to be fixed (i.e. intended behaviour):

1. The configuration builder has not been fully updated for this release i.e. not all new options are available. This will be resolved in a later update and does not affect most configuration aspects if this mode is used.
2. Under sustained high numbers (1000's) of concurrent client connections, the DNAS server may in rare scenarios crash / segfault. This is primarily due to the networking methods currently used not scaling as well to the 1000s of concurrent client connections as desired compared to the need for more portable code between the platform builds. This requires completion of a networking stack re-write (no eta) and should not generally happen under most expected usage (most stations never break a few 100 concurrent listeners let alone 1000s at the same time).
3. The change of 'disableicy' from 0 to 1 may cause some clients not to show the current title anymore. Setting disableicy=0 will allow the prior behaviour at the expense of breaking default compatibility with Flash and HTML5 audio players. See http://forums.shoutcast.com/showpost...08&postcount=7 for more on what you can do currently and what will be done in the 2.4.0 build.
4. Some Centova setups experience a crash when the logs are rotated. For some using the Linux 32-bit version helps as the issue has only been seen with the Linux 64-bit release. This is due to incorrectly handling invalid log / w3c files and if you have any 0-byte files in your log folder, this issue is now fixed as of the 2.4.0 DNAS release.
5. When attempting to update / remove an authhash, some installs will experience a 462 error (which is due to an issue with the integration of libcurl into the DNAS). Contact support with the authhash and the details you require to be changed. Additionally this may cause a failure to be listed or you will see generic 400 error messages.
6. In some setups, disconnecting a source may cause the DNAS to crash - the probable cause of this has been identified but a fix still needs to be implemented.
7. The advert and metrics code (when enabled) is new so there may be some minor issues so keep a look out for updated DNAS versions!
8. In some setups, the YP connectivity may either fail to start or will randomly fail after an unspecified time. This is an implementation issue related to changing over to libcurl in 2.2.2. A fix will hopefully be available for the 2.4.1 update.
9. The banning actions may not work correctly in some cases (primarily dependent upon details provided by the listener connection details).

Discussion about the previous version of the server including changelogs can be found in the following threads

• GM (Build 164 / 165)
• GM (Build 147)
• GM (Build 123)
• GM (Build 109)
• GM (Build 107)
• GM (Build 29)
• RC2 (Build 28)
• RC (Build 27)
• Beta (Build 18 + 19)
• Beta (Build 17)
• Beta (Build 13 + 14)
• Beta (Build 10)
• Beta (Build 7)

[DrO]

*new version bump*
note: the main site is showing 2.4 as the version but the download is 2.4.2 (will be fixed)

this build resolves the issues which affected both of the 2.4.1 builds, including loading via init scripts and 3rd party control panels (which has been confirmed as ok prior to releasing with Centova).

[ram130]

So I talked with my host and they say they ran the update script but still 147. They say it pulls whatever is on Centova servers. So I'm stuck waiting with no eta on when they'll update their side. Centova can be a pain at times.

[bschelst]

the Linux 32 bit version contains 64 bit binaries...:


sc_serv: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, BuildID[sha1]=0x1a33bb5b81dc5b6214063497c453744c230dc8f1, stripped

[EastonRoyce]

Yes, Sir. This is true.

[EastonRoyce]

Hi ram130,

Even though Centovacast doesn't always update Shoutcast2 at the same time, you can download the binaries from shoutcast.com, stop your stream, replace the binaries with the ones you downloaded from shoutcast.com and then start your stream again.

Be sure to back up your existing binaries first, in case something goes wrong ;-)

I always backup sc_trans2 and sc_serv2 before running any Centova updates. Good thing I did this time, as bashelst has noted, the update from Centova pulls down a 64bit version of the sc_serv binary, that didn't work for me on on my 32bit Centovacast server. I suspect Centova just grabbed and 32bit and 64bit binaries from shoutcast.com without checking...

[WizardX]

Smylink removed, new version installed, error gone
It seems all working well.

[Limman]

Big thanks for FreeBSD version! On my FreeBSD 9.1 amd64 works fine.

[DrO]

well that's good it seems to run ok, just a shame there's no trace of it in our listings...

[DrO]

there was a caching issue with the official linux 32-bit link providing the earlier incorrect copy despite the correct version having been uploaded. it should now be working correctly - the downloaded archive size should be 2,898,219 bytes.

as for Centova updates, there is information on their forum on how to force a manual update of the DNAS. additionally updating to Centova 3.1.1 will also correct what it is going to attempt to download (as we've changed our download links - though that won't help the badly cached linux 32-bit version) which would explain why it's not pulling down the new versions.

[bschelst]

solved indeed:
sc_serv: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, BuildID[sha1]=0xb6d8ed0c0443c4ba732871858340032c1bf28997, stripped

[DrO]

a new Mac build has been uploaded and is marked as build 168 - this is purely to resolve issues with the Mac build not finding files correctly relative to the DNAS program file. no other changes have been made and all other builds are not affected by this issue.

[McLemmi]

Hello,

since updating to Build 167, we have from time to time restarts of our streams. The log files give no clear entry. The stream starts then just new and it does not come to the interupt of listeners.

But if restart not will work, we receive serious problems.

We are using DNAS 2.4.2 Build 167, Centova 3.1.1

Shoutcast simply crashing without leaving any log message behind about it. Centova is looking as well.

Maybe a Bug? I cant find something in forum about it.

Thanks in advance

[DrO]

sorry but i'm really struggling to understand your message. when is it crashing ? what are you doing to make it crash (that is not at all clear from your message). unless you're trying to describe point #6 from the known issues (http://forums.winamp.com/showthread.php?t=373139#known)

[MRGrp]

Hello everybody,

Same case as McLemmi, Linux 64bit server running Centova Cast 3.1.1 and we also upgraded yesterday to the latest version of DNAS 2.4.2 b.167 (coming from the year 2011 DNAS version).
We have 7 radio stations of our group are currently "trying" to broadcast. I say "try" because since we installed the latest version of DNAS some stations are restarting even every 30 minutes.
Centova Cast is dispatching the alert email informing us about it: "This message is to inform you that your streaming server went down in the past few minutes, but has been restarted successfully".
In fact, sometime it doesn't even restart successfully!

Some of the 7 radio stations are suffering more restarts (even every 30 minutes), and some "just" a couple in the last 12 hours.

Also banning IPs seems not to be effective. The IPs are being banned and kicked out, but allowed to connect again right after.

Finally, for few hours (then this error red line stopped appearing) also the below error lines were appearing repeatedly in the logs of ll the radio stations:
"2014-11-12 08:51:59 ERROR [YP] Stream #2 connection attempt failed. YP2 error code is 493 [Internal error - unable to acquire data source]
2014-11-12 08:52:00 ERROR [YP] Stream #1 connection attempt failed. YP2 error code is 493 [Internal error - unable to acquire data source]
2014-11-12 08:52:02 ERROR [YP] Stream #3 connection attempt failed. YP2 error code is 493 [Internal error - unable to acquire data source]
2014-11-12 08:52:02 ERROR [YP] Stream #4 connection attempt failed. YP2 error code is 493 [Internal error - unable to acquire data source]".

Seeing the severity of the issue, we will now roll back to the old version dated 2011, which we were using until yesterday.

Hopefully rolling back won't be an issue???

Thank you and have a good day.

Best Regards

EDIT:
In order to provide more complete info, please find below the first lines of the Log, when WE restart from Centova Cast any of the streams:

=============
2014-11-13 10:01:12 WARN [CONFIG] Invalid item on line 22 of ../xxradioxx/etc/server.conf -> `yp1debug'
2014-11-13 10:01:12 WARN [CONFIG] Deprecated statement found on line 88 of ../xxradioxx/etc/server.conf -> change autodumpsourcetime_1=30 to autodumptime_1=30
2014-11-13 10:01:12 WARN [CONFIG] Invalid item on line 102 of ../xxradioxx/etc/server.conf -> `yp2'
2014-11-13 10:01:12 WARN [CONFIG] Invalid item on line 164 of ../xxradioxx/etc/server.conf -> `specialfiletmpdir'
2014-11-13 10:01:12 INFO
2014-11-13 10:01:12 INFO [MAIN] SHOUTcast DNAS/posix(linux x64) v2.4.2.167 (Oct 30 2014)
2014-11-13 10:01:12 INFO [MAIN] PID: 15810
2014-11-13 10:01:12 INFO [MAIN] Saving log output to `/usr/local/centovacast/var/vhosts/xxradioxx/var/log/error.log'
2014-11-13 10:01:12 INFO [MAIN] Automatic log rotation interval: 1 day
2014-11-13 10:01:12 INFO [MAIN] Loaded config from `/usr/local/centovacast/var/vhosts/xxradioxx/etc/server.conf'
2014-11-13 10:01:12 INFO [MAIN] Calculated CPU count is 4 -> using all available CPUs
2014-11-13 10:01:12 INFO [MAIN] Limited to 10240 file descriptors [relates to ulimit -n]
2014-11-13 10:01:12 INFO [MAIN] Starting 4 network threads
2014-11-13 10:01:12 INFO [BAN] Banned 9 IP's from global ban file
2014-11-13 10:01:12 INFO [MICROSERVER] Listening for source and client connections on port 8800
2014-11-13 10:01:12 INFO [MICROSERVER] Listening for legacy source connections on port 8801
2014-11-13 10:01:12 INFO [MICROSERVER] Listening for legacy source connections on port 8019
2014-11-13 10:01:12 INFO [MICROSERVER] Listening for legacy source connections on port 8020
2014-11-13 10:01:12 INFO [MICROSERVER] Listening for legacy source connections on port 8021
2014-11-13 10:01:12 INFO [MICROSERVER] Flash policy file server not enabled

[ram130]

No issues here. Build is smooth.

[MRGrp]

Hello Ramon,

It can be useful to know more details about your installation, as it looks like the DNAS update behaves differently, depending from the platform, OS, panel, etc.

Thank you.

[ram130]

All I know is that I'm on a 64bit system. I pay for hosting. I got two months. I use the latest Centovacast. I had an issue with a mount not showing listeners in Centovacast. I removed and add them back, rebooted and that cleared it up. Maybe you can try that.

[MRGrp]

Hello,

I believe that your mount wasn't showing the listeners because of no communication between Centova Cast and the server.... This happen sometime because you change the password fromCentova Cast without restarting the server.
After restarting the new password is enforced and listeners were again visible in Centova Cast.

...but this is issue you mentioned is something else, not related with the current DNAS issue and thread.

Regards

[McLemmi]

Same problem and logs as MRGrp.

Thanks MRGrp for the better explanation. Maybe its the bug No.6 as DrO said.

[MRGrp]

...in the meantime I confirm that our 7 radio stations keep going offline continuously. Many times they do not restart, they simply go offline.

Centova Team doesn't know how to assist us.

We really hope to get some assistance (and a solution) from DrO and the SHOUTcast team as soon as possible. The radio stations are listed in iTunes and Windows directories, and downtime can just result in being Delisted.

Best Regards.

[DrO]

the 493 errors are irrespective of the DNAS version being used and is a yp side issue which we've been trying to resolve for the last week.

so its an actual DNAS crash that happens? the log just prior to the DNAS crashing would be handy to have.

also in both cases are multiple 1.x sources being used for the streams ? as I see in the initial log provided the legacy source options are being used.

[McLemmi]

if it will helpfull i can give you access to our server or if you dont want this i can send you the complete logfiles. Because the problems seems the same.

Originally Posted by MRGrp

...in the meantime I confirm that our 7 radio stations keep going offline continuously. Many times they do not restart, they simply go offline.

Centova Team doesn't know how to assist us.

We really hope to get some assistance (and a solution) from DrO and the SHOUTcast team as soon as possible. The radio stations are listed in iTunes and Windows directories, and downtime can just result in being Delisted.

Best Regards.

before last update we have as well the error 493 and stream doesnt start sometimes by themselve, but after last build this error doesnt exist. Now only restarts without this 493 error. For last build we have done manual installation.

[DrO]

the complete logs would be best as a starting point. though I'm wondering how many people are having such issues and not bothering to report them (as its taken what 2 weeks before we've had any reports of issues with the new build).

[MRGrp]

Originally Posted by DrO

the complete logs would be best as a starting point. though I'm wondering how many people are having such issues and not bothering to report them (as its taken what 2 weeks before we've had any reports of issues with the new build).

Hello DrO,

Thank you for your reply.

If you are so kind to provide step by step guidance about what to do, I will be more than happy to pull the log/data you are looking for and provide them/it.

In the meantime I was able to download the "all logs" compressed folder using Centova Cast features. I will try to send you a private message with a download link.

Best regards

[MRGrp]

Originally Posted by DrO

the complete logs would be best as a starting point. though I'm wondering how many people are having such issues and not bothering to report them (as its taken what 2 weeks before we've had any reports of issues with the new build).

Hi DrO,

Would you please check your PM inbox? You will find a link to download the complete logs (pulled utilizing Centova Cast).

Thank you.

Best regards

MRGrp

[DrO]

i've had a quick look and it's not showing anything obvious, though i only quickly skimmed through the files. it doesn't look like it's due to the known issue noted (as the logs for such cases show different things going on) and i'm wondering if it's related to some of the YP instability as another use has found their DNAS crashes when the YP responds with a certain HTTP header (100-continue).

really would need the DNAS to have all of it's debug logging options enabled to see what is going on. am not sure if the Centova options allow for that or it'll need the DNAS config file to be manually changed (which makes me wonder for such situations if it'd be better to have a DNAS admin page that allows for easily toggling such options on/off).

[MRGrp]

Thank you DrO,

Is there anything that we can do in order to help with the debugging? Even if it has to be pulled from the SHOUTcast server page itself with your guidance?

We run our stations on a server with Linux 64 bit/latest CentOS.

Is it advisable to switch to the 32 bit version of the DNAS 2.4.2 (Build 167) in order to fix this issue, or would you suggest for the moment to just roll back to the old DNAS dated 2011?
What differences (let us say "limitations"?) will we will face, broadcasting 7 to 10 radio stations of our Group with a x86 version of the DNAS installed on our 64bit server?

We have our radio stations going online and offline like the lights of a Christmas tree, and we are really keen to find a solution ASAP.

Thank you for your assistance.

Best Regards.

[perfectlemon]

To enable more debug logging options in Centova Cast you would have to edit Shoutcast's configuration file. You can do this from within Centova Cast by loging into the affected station's account, Settings->Raw Configuration->Shoutcast2

Not sure what debug logging options are needed, but I guess you should probably change
yp1debug and yp2debug from 0 to 1. After that restart the station and check the logs when the problem occurs again.

[MRGrp]

Thank you perfectlemon,

I have enabled yp1debug and yp2debug for one of the radio stations (the one stopping or restarting every about 30 minutes).

Regards

[DrO]

it needs more than just those options (one of which, yp1debug, was deprecated in 2.2). the following is what needs to be enabled (which doesn't need to restart the DNAS, just a config reload on the DNAS's server admin page):

webclientdebug=1
yp2debug=1
shoutcastsourcedebug=1
uvox2sourcedebug=1
streamdatadebug=1
microserverdebug=1
httpstyledebug=1
shoutcast1clientdebug=1
shoutcast2clientdebug=1
relayshoutcastdebug=1
relayuvoxdebug=1
statsdebug=1
threadrunnerdebug=1


and if the issue is what i think it might be, it won't matter if using the 32-bit or 64-bit version. and i definitely wouldn't advise going back to a version from 2011 (there's nothing we can do with that as it's got a slew of other issues), but i don't know what you were using previously so for the moment, i can only suggest sitting it out until we've got a log dump which gives more indication of what the issue is. if you must, then i guess the last pre-libcurl based version (2.2.1) would have to be the one to try (though that has some weird issues as well if the YP goes down which i think is part of the issue).

[DrO]

i've just sent 2 windows users a test build based on the crash they've been seeing (which was not the known issue mentioned in the first post) and was helped to determine with a full debug log.

once i've seen a full debug log from a linux build (as per instructions above), i can then see if it is the same issue as fixed in the Windows build or if it's something else. so is down to waiting to see who can provide that information (assuming the DNAS are still crashing).

[MRGrp]

Hello DrO

Thank you for your message.

As you anticipated (in the meantime we were doing tests) the x86 version of the SHOUTcast DNAS 2.4.2 build 167 did not improve things. The radio stations kept going offline or restarting at incredible rhythm.

I respectfully disagree regarding your advise not to go back to the old version (we were using the version linux_x64_10_07_2011) and sit+wait & see.

With that old version the radio stations were broadcasting with continuity without going offline several times every hour, and we were not having deadly notable issues with that version.

I was happy to see a new version of the DNAS (we were all waiting for it!), but seeing the outcome and having to give priorities, we have to give the priority in keeping the acquired thousands of listeners per day, that right now, seeing the radio stations offline are just "leaving".

I have already requested to the tech team to roll-back, but I will keep following this thread. I cannot wait to install a stable & reliable new version of the SHOUTcast DNAS.

Thank you.

Best regards

[DrO]

and i will disagree as well since running the older version means i'm not going to have the log data needed and so cannot resolve the issue and provide the a newer build as you're asking for.

the 2011 version is not even comparable to the current builds, hence why i said if you are going to roll back, at least go to 2.2.1 and not 2.0 - as 2.0 blocks client connections if the YP is not contactable which is even worse than having the stability issues.

and the issue happened again with the 32-bit version but you / your host have not provided any of the requested full debug logs? so we're back to square one with no information to try to provide a fix for an issue we're not able to replicate *joy*

[McLemmi]

The Log is running, and after first "crash" i will send complete.

[MRGrp]

Hi DrO,

The best is to run and Test such unstable builds having problems and in need of debugging in "private" streams and not to use published radio stations and public streams. I am sure that we can just both agree on this point.

We are providing a service, with radio stations listed in iTunes, Microsoft, etc. etc. and the first two are not very keen to list radio stations having technical troubles for days (we are witnessing issues since the 11th).

I offered to create logs for you (as suggested by perfectlemon), but your post was clear stating that what I was able to provide (I am not an expert) was not enough for you.

In this case probably the Centova Team would be the best in order to provide what you need (as it looks like Centova Cast is the platform more effected by the discussed new DNAS issues).
From my side each action I have taken because of this DNAS issue in these 3 days meant to place a paid work order to Centova and pay the related fees, other than seeing the radio stations continuously offline for 3 days.
I am not allowed to place few more work orders to debug the new version of SHOUTcast DNAS (as I can't assist directly with the logs and other tech stuff) and the issues it faces on Centova Cast installations.
I wish there would be a direct channel open between Centova and SHOUTcast.

I hope this clarifies that there was all the desire to assist and contribute, but sometime there are other factors to deal with.

Thank you.

Best regards

[DrO]

i am not disagreeing with that point, and i should have been clearer that once it happened again that there was nothing to stop you reverting to an applicable version (i still hold that 2.2.1 is a better option than 2.0 but it's your stream, you can use what you want).

my post clarified that the options suggested was not going to be enough, that was not a call to say don't bother to do it - it was clarification to ensure that logs would give the information needed so it would just be a single run that would be needed and then you could go back to the older version.


however as the issue is seemingly only happening with some public streams, the only way to get to the bottom of the issue is from data from a setup which is experiencing the issue. we do not intentionally try to cause issues with the DNAS builds and is why i am trying to get as much information in one go so we can provide a patched DNAS build asap - we don't want the DNAS to crash as it's not good for anybody involved.

hence my frustration as well since this is taking time away from working on required new features and it means the image of the 2.x DNAS being unstable persists due to what i suspect is likely an innocuous parameter check failure (if the issues with the Windows builds is anything to go by). and truth be told, i don't think this is a Centova-centric issue, it's just seeming that way due to all of the reports that have been publically made being from people using such setups but that is likely not the case based on other reports that have not been made on the forum where the DNAS is managed directly.


so i apologise for not being clear enough in what i was asking for (this is why developers should not provide support) and for the financial implications it has caused you and everyone else.

[MRGrp]

Thank you for clarifying and no apologies needed DrO.

I don't disagree with you about the best alternative version of DNAS: I don't have the necessary knowledge!
What we were running in our server (without bad "visible" results) as installed by the Centova Team, was the version Linux_x64_10_07_2011.
I don't know much more about it, and at this point I am wondering what could be the technical reason that made Centova Team prefer the Linux_x64_10_07_2011 DNAS version to the one you are suggesting.

Thank you.

best regards,

MRGrp

[MRGrp]

Hello DrO,

We will have the Centova Team installing the SHOUTcast DNAS version 2.2 (the version you suggested).

Could you please give us good news and confirm that rolling back to this DNAS version 2.2 will NOT affect our ability to list our stations on the public directory, and that NOTHING will prevent older versions of DNAS (like the 2.2) to use the YP service?

I hope you will give us good news. At least we will be able to get things to work for now, and utilizing the DNAS release you have suggested in your earlier post.

Looking forward for your response.

Thank you.

Best regards

[DrO]

ignore me, let them do what they think is best. as i have no idea how well 2.2.1 will work in the Centova install you're using since there were issues with it on log rotate in the Centova 3.0.x releases.

however if you do go back to 2.0, i cannot provide any guarantee that that build will work correctly or be able to be listed correctly (i assume it should be ok as you were using it and some others still do, however i wouldn't want to use it with all of the other stability issues which are known to exist in it and the lack of feature compatibility, etc). so is down to you what you install.