and i would appreciate not being mis-quoted on things as i don't know when asapcpu received that response but it's not correct if it was in the last few days as i've had zero contact with anyone from Centova for a few months now with the last thing being a notification of the v2.2.1 release which never received a response. and specifically that message relates to things which i said to Steve _over_ a year ago.

as for the DNAS crashing (which based on what i heard up to the end of the year was massively down compared to what v2.0 DNAS was doing), it'd be helpful to run it under a debugger to try to get some information on the crash that way. as well as what OS version and bit-type and listener numbers at the time (as it's noted in the known issues for it that at high peak / sustained loads it can crash).

so just because it's crashing for some, doesn't mean it's going to crash for all as per 'yeinu' (your experience is not universal) but on the whole, v2.2.x is a far better option to be running compared to a v2.0 setup (which is far more prone to crashing) and seeing as the v2 DNAS is new code, there's going to some issues still, same as with what Centova Cast v3 has (and still seems to be going through).

Hi DrO hope you've been well

100+ SHOUTcast v2 streams here for over a year and none restart, over the past year we may have had 2 clients complain of restarting and both were due to invalid characters in one or more of their mp3s, everything is stable for us other than minor issues unrelated.

SHOUTcast Server v2.2.1.109/posix(linux x64)

most of the SC v2 broadcasting issues stem from sc_trans v2 and it's issues (which is why it's always been classified as a beta product).

sure there were some issues with error handling in DNAS v2.0 which on non-Windows builds would cause it to crash (due to not handling a metadata failure correctly), but pretty much most of the stream stability issues stem from sc_trans (which i had generally worked out in internal builds but time ran out to release it before the end of the year).

and as i see Steve / whoever is making a feature compatible replacement, the issues with sc_trans as a source should go away anyway. sc_trans was a nice idea but was never allowed to be worked on as needed (always at the bottom of the list) and the fact of AOL legal messing with things and causing it to have to have the unlock code (which has now crippled it's usage anyway) means it's a dead duck imho.

Hi DrO,

Nice to see you around again.


The messaged quoted by "asapcpu" does seem like an old one and is most certainly not accurate anymore at this time.

Hey DrO, great to see you back!  Just wanted to clarify a few points:

and i would appreciate not being mis-quoted on things as i don't know when asapcpu received that response but it's not correct if it was in the last few days

I'm not sure why asapcpu posted that now in regard to 2.2.1.  That response from our staff was from many, many months ago (maybe as much as a year ago), back when you had said you were assigned to Winamp only and were not receiving any dev time for the SC toolset.  That was long before we were even aware that the 2.2 series was back under development, let alone 2.2.1.

as i've had zero contact with anyone from Centova for a few months now with the last thing being a notification of the v2.2.1 release which never received a response. and specifically that message relates to things which i said to Steve _over_ a year ago.

Apologies for the lack of response on my part -- I was like a kid in a candy store, rushing off to test out the new build and must have forgotten to reply to say thanks for the heads-up!   As ever I very much appreciate you taking the time to keep in touch regarding new developments while you were working with Nullsoft.

as for the DNAS crashing (which based on what i heard up to the end of the year was massively down compared to what v2.0 DNAS was doing), it'd be helpful to run it under a debugger to try to get some information on the crash that way. as well as what OS version and bit-type and listener numbers at the time (as it's noted in the known issues for it that at high peak / sustained loads it can crash).

The particular issue my staff was referring to in the helpdesk reply asapcpu posted was in regard to sctrans2 failing to properly UTF8-encode certain extended ASCII characters.  When DNAS2 received the XML metadata packet containing the un-encoded characters, libxml choked on them and apparently called abort(), and of course DNAS2 went down.  So it was a combination of a bug in sctrans2's encoding of the metadata combined with perhaps less-than-desirable error handling on the DNAS2 side effectively causing an inadvertent DoS.

I don't know whether that was fixed or not, but again, it was an issue from about a year ago (back before 2.2.0 was released) so it's quite possible it has been.  I'm not personally aware of any other widely-reported stability issues with 2.2 since then.

Also for everyone else in this thread, regrettably, I did not notice this thread prior to now, but for everyone who was wondering and/or still isn't aware, Centova Cast has never had any issues with DNAS 2.2.x and never needed any changes for compatibility with it.  DrO did an excellent job maintaining backward compatibility with DNAS 2.0, so everything just worked as-is with Centova Cast from the day DNAS 2.2 was released.

Even the Centova Cast installation system was designed to automatically detect and download the latest version of DNAS2 from the AOL servers, so that required no changes either.  Literally nothing more than a "/usr/local/centovacast/sbin/update shoutcast2 --force" was required to perform an automatic upgrade to DNAS 2.2.0/2.2.1.

I am willing to take help from anyone that has any ideas. I have an open ticket for a month now it seemsms

I am willing to take help from anyone that has any ideas. I have an open ticket for a month now it seemsms

Indeed it's been open a long while and I see that my staff are trying to help you track down what might be causing the crashes you're seeing, but I can more-or-less tell you right now that even if they are able to identify it, we won't be able to do anything to resolve it.  I've confirmed (since my earlier post) that a number of our clients are seeing similar crashes, so it's most likely a bug of some sort.  With that in mind, we *might* be able to suggest a workaround if we can track down the cause, but that depends on the nature of the problem.

Ultimately it comes down to the fact that SHOUTcast DNAS is not our product -- we are not in charge of its development nor do we have access to its source code, thus we cannot fix any bugs it contains, and we can only take educated guesses at what might be causing it to crash.

The only people who can fix bugs in SHOUTcast DNAS are the SHOUTcast DNAS developers.  Formerly that was DrO (who posted above), but unfortunately AOL allocated very little in the way of development resources to SHOUTcast toolchain development, so despite the excellent work DrO *did* do, there are still a number of bugs he wasn't able to get to.  That includes the crashbug that you and several others are experiencing right now.  At this point AOL has sold the SHOUTcast toolset code to Radionomy, so only Radionomy has the ability to fix things now... and it remains to be seen how they'll handle this.

Meantime, we (as SHOUTcast users in general) have only two options -- live with the crashes and wait and see what happens with Radionomy, or switch to IceCast which tends to be rock-solid stable.  Myself, I have opted for the latter with most of my own streams.  The main objection I've heard from stream operators in regard to switching to IceCast has been the loss of functionality offered by sctrans2, but upcoming developments in Centova Cast may even the playing field and make it practical for a greater number of people to make this same switch.

Back on point, DrO offered some suggestions as to the kinds of information you could post to try to narrow down the cause of the crash.  If you were to post that information to this thread (particularly a backtrace from GDB), we might be lucky enough to get his insight into what might be going on.

Is there a way Steve to do a Mass Rollback with the streams that are having the problem that are running 2.2.1. And roll them back to 1.9.8 without having to remake each one 1 by 1?

Replace DNAS file with old one and restart streams

I vote 1000 times as i speak for my clients.

Steve.. I am a bit confused. I was told by your support that my issues were caused by shoutcast 2.2.1 and that you dont support that version of shoutcast.

I was also told I had to pay to update to 2.2.1 where all I could have done was "/usr/local/centovacast/sbin/update shoutcast2 --force"

Seems like you and your crew are not on the same page.

Hey DrO, great to see you back!  Just wanted to clarify a few points:

and i would appreciate not being mis-quoted on things as i don't know when asapcpu received that response but it's not correct if it was in the last few days

I'm not sure why asapcpu posted that now in regard to 2.2.1.  That response from our staff was from many, many months ago (maybe as much as a year ago), back when you had said you were assigned to Winamp only and were not receiving any dev time for the SC toolset.  That was long before we were even aware that the 2.2 series was back under development, let alone 2.2.1.

as i've had zero contact with anyone from Centova for a few months now with the last thing being a notification of the v2.2.1 release which never received a response. and specifically that message relates to things which i said to Steve _over_ a year ago.

Apologies for the lack of response on my part -- I was like a kid in a candy store, rushing off to test out the new build and must have forgotten to reply to say thanks for the heads-up!   As ever I very much appreciate you taking the time to keep in touch regarding new developments while you were working with Nullsoft.

as for the DNAS crashing (which based on what i heard up to the end of the year was massively down compared to what v2.0 DNAS was doing), it'd be helpful to run it under a debugger to try to get some information on the crash that way. as well as what OS version and bit-type and listener numbers at the time (as it's noted in the known issues for it that at high peak / sustained loads it can crash).

The particular issue my staff was referring to in the helpdesk reply asapcpu posted was in regard to sctrans2 failing to properly UTF8-encode certain extended ASCII characters.  When DNAS2 received the XML metadata packet containing the un-encoded characters, libxml choked on them and apparently called abort(), and of course DNAS2 went down.  So it was a combination of a bug in sctrans2's encoding of the metadata combined with perhaps less-than-desirable error handling on the DNAS2 side effectively causing an inadvertent DoS.

I don't know whether that was fixed or not, but again, it was an issue from about a year ago (back before 2.2.0 was released) so it's quite possible it has been.  I'm not personally aware of any other widely-reported stability issues with 2.2 since then.

Also for everyone else in this thread, regrettably, I did not notice this thread prior to now, but for everyone who was wondering and/or still isn't aware, Centova Cast has never had any issues with DNAS 2.2.x and never needed any changes for compatibility with it.  DrO did an excellent job maintaining backward compatibility with DNAS 2.0, so everything just worked as-is with Centova Cast from the day DNAS 2.2 was released.

Even the Centova Cast installation system was designed to automatically detect and download the latest version of DNAS2 from the AOL servers, so that required no changes either.  Literally nothing more than a "/usr/local/centovacast/sbin/update shoutcast2 --force" was required to perform an automatic upgrade to DNAS 2.2.0/2.2.1.

Steve.. I am a bit confused. I was told by your support that my issues were caused by shoutcast 2.2.1 and that you dont support that version of shoutcast.

Hello  GroovinMind,

If you were kind enough to provide the ticket number we should be able to explain exactly what happened, however, you are probably referring to the invalid configuration line error messages, which as it turns out are harmless. Either that or you've encountered a legit bug in ShoutCast/Sc_trans, but again we would need your ticket number to tell exactly what the problem was.

I was also told I had to pay to update to 2.2.1 where all I could have done was "/usr/local/centovacast/sbin/update shoutcast2 --force"

I'm almost sure that you received this response before nullsoft made v 2.2.1 available on his official download site, at which time, the only way to get the new version was through manual installation.

Again if you'd provide us with your ticket number, we would be able to give you a more detailed response.


HTH

Hey, maybe.

Maybe you can help me out. I instentado shoucast install, but I get this error:
[root@server4 ~]# /usr/local/centovacast/sbin/update shoutcast2 --force

Checking Centova Cast Common Files ...
Downloading Centova Cast Common Files ...

Verifying archive integrity ...
Unpacking archive ...

Installing Centova Cast Common Files ...

Installation successful

Checking shoutcast2 ...
Downloading shoutcast2 ...

Verifying archive integrity ...
Unpacking archive ...

Installing shoutcast2 ...


gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
Sorry, an error occurred while unpacking ShoutCast DNAS v2.x.
Installer exited with error, aborting
[root@server4 ~]#

Not going to happen. I've tried installing with ./install.sh --shoutcast-all
and
/usr/local/centovacast/sbin/update shoutcast2 --force

but nothing no way. Could someone help me out?

thanks

It looks like Centova have broken file.

Unfortunately, you have to install Shoutcast 2 manually .. as a change was made to the way it is  uncompressed...Peace... Steve you need to update the install script ! UPDATE... It was corrected Sorry Steve