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.

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 

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 

Read that by mistake (interested in 2.2.1), today tried to install centova cast on a new server,
it seems I get the exactly same errors about gzip. Shoutcast1/shoutcast2/ices-cc/sctrans.

Updater needs a fix ? Can't install anything, still waiting for support

Actually , I made the error and forgot to edit the post.. It was never fixed.. and is awaiting to be fixed... Sorry 

It seems the v2.2.1 archive was incorrectly built and wasn't realised until too late that it happened which is what support, etc have been referring (based on another post i just saw before posting this reply).

The installs are most likely failing due to the whole transition of all of the SHOUTcast sites over the last few days and at the moment, the downloads are not available (due to waiting on a few things which are required to be able to get new builds built and released - i don't have an eta, sorry).

So really there's no reason for Centova to 'fix' their updater since the prior DNAS archive was messed up when it was built. How it copes with no official downloads for the time being, i don't know what they'll do.

It's not a problem with our product by any means, but as it dramatically affects our customers I have implemented a workaround.

To clarify, what happened is that whomever built the latest SHOUTcast2 and sctrans2 archives made a mistake and failed to gzip them when they tarred them up.  But they named the file with a .tar.gz extension (which implies that gzip and tar were both used).

Since all prior archives had been tarred/gzipped, and because .tar.gz indicates a tar/gzip archive, Centova Cast's installer was trying to process the files as tar/gzip archives.  That was of course failing, because the archives were not in fact gzipped.

Today's build includes a workaround that will actually analyze the header of any files downloaded from download.nullsoft.com and determine whether or not they are actually gzipped, regardless of whether or not they are misnamed as gzip archives.

On a side note, great to see you back, DrO -- thanks for your insights on the various threads popping up here!