SHOUTcast DNAS 2.4.2 (Build 167) 30th October 2014

[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.

[MRGrp]

Thank you for your prompt reply Dro; it is much appreciated.

If you wish, I can update you, once we roll-back and see the result.

Best regards

[DrO]

if there's issues rolling back, the only thing i will be able to suggest is going back to the current version and dealing with the stability issue (until it's fixed). as we cannot patch prior builds as we don't have any code from prior to 2.2.1 and with everything else that has changed since then, our only option is to fix things against the current code base and move the builds forward (as it looks like we'll be doing a 2.4.3 once we've got a solution for the stability issue).

[MRGrp]

Hello,

A quick update: with the assistance of the Centova Team, we have successfully rolled back to the DNAS version SHOUTcast Server v2.2.1.109/posix - linux x86 (not x64 because of known conflicts with Centova Cast). We do not witness servers going offline or restarting anymore.

Before going back to the 2.2.1 build 109 we tried to switch from the 64 bit to the x86 version of the DNAS 2.4.2 (build 167) but unfortunately without seeing improvements.

Thank you.

Best regards

[Bryon Stout]

MRGrp:

What issues does centovacast have with v2.2.1.109/posix - linux x64?

Because that is what I use currently and I dont have any issues.

[DrO]

for some setups, it didn't like the log rotation with those builds and for some, the 32-bit version didn't crash whilst the 64-bit one did.