Hi,

have no sense what they told you, i use SC_TRANS2 not ICES, and i didn't have this bad experience till last update, i test before and works all well, without get 1 million restarted email notification. The bad part is as they close Centova2, and they release Centova 3.0.5 as a stable version, with is not so stables as we can see. I have no problem with centova2, but migration to centova3 it's more than impossible till is not 100% with bugs solved, major bugs. Also i do not understand why they refuse to continue to support shoutcast1 to work with SC_TRANS2, as we know it's not so sure the situation with AOL and SHOUTcast, if they close YP we will see son many people crying with SHOUTcast v2

Anyway, back to this issue, as i say before, i didn't have this issue till last upgrade to 3.0.5. i run 2 servers with same audio files on test, one stream is AAC+ and works normal, the second one MP3 send me frequent restart notification email.

I hope this will be a point for debug.


Regards,
CyberMIX

Friend, do not use the migration feature of Centova or via server commands to copy the MP3 files.
Make the uploadas centovacast by the panel and perform new tests.
Again, the bug is in the migration.
With new uploads and new accounts the problem does not happen.

So we got a couple new servers, just added accounts on them, and nothing but restart emails.

I think we got down to why this is happening...

I found today that one of the resellers was receiving these emails over and over (as we were also getting them).

The account it was doing it on was a Shoutcast v1.x stream.  When they stopped "Auto DJ" and went live, This is when the emails started flowing out.

Does Centovacast think when auto DJ is turned off or is "kicked", it thinks that there is something wrong with the stream itself ??

IF so, there must be something that can be done there to get that fixed up?

@DJFire - wondered if you were able to get any resolution. I too have the same problem when someone stops the autoDJ and goes live. Like clockwork every 5 or 10 minutes I get the server has been restarted email.

I have ran across this before, do any of the mp3s have non-english characters? If so I think that's the reason it keeps restarting, simply changing the character set should correct the problem but If there is a mix of English and non-English characters mp3s (which can be common if your client has a mix of different music, I think the last client I found that had this problem had some Russian mp3s mixed with USA songs so I just deleted the few Russian songs and the problem was gone! 

But the issue could be in mp3 name file or mp3 ide tags or both? Because if was the mp3 name centovacast could make something to filter (delete) the anormal caracters after upload or after some media library update.

Any new possible solution.. as I also have this issue.. and none of the above corrects it...

Just to put an official end to the speculation here: in all but a few rare cases, "server restarted" emails basically mean SHOUTcast DNAS or IceCast crashed.  Centova Cast is not the problem here -- it's just reporting what happened, and telling you that it restarted SHOUTcast/IceCast so that it didn't remain down.

Our clients often mistakenly believe that Centova Cast is the cause of the problem since Centova Cast notified them of the problem, but it's important to avoid shooting the messenger, as the saying goes.

DNAS, DNAS2, and sctrans2 all have known crash bugs at this time, with DNAS2 and sctrans2 being the most commonly affected.  Since DNAS, DNAS2, and sctrans2 are NOT our products and we do NOT have any access to their source code, there is nothing we can do about any bugs in their code -- your options are to either wait for a fix from Radionomy (who recently purchased the SHOUTcast intellectual property rights) or switch to IceCast.

To complicate matters, there are a few other rare situations (usually hardware or kernel issues) that can cause ALL processes to terminate, and this will be reported identically by Centova Cast.  Odds are, 95% of you do NOT fall into this category but I'm mentioning it for the inevitable 5% who will complain that my diagnosis must be wrong simply because you're not one of the 95% I mentioned above.

In either case, our helpdesk staff can usually help you identify which category you're in.  Feel free to open a ticket if you're in doubt.

Like the major problem could be bugs in shoucast, sc_transcv2 or other software not related with centova would be good identify what could be the commom factors that cause that. If users of centova identify some possible causes I believe that help to guide users to not make the same. I don't know if that is possible, because must be more than one thing that explore the possible bugs, but each user with the problem could try to test the panel deleting musics and adding to see what is the file or folder that could start to cause the issue. After identified some causes maybe centovacast could make something to prevent some cases. I suggested in feature requests a way to centova filter "strange" caracters from folders or files to see if that could cause something. If not, the problem could be related with some mp3 corrupted or something...

But steve,  sc_transcv2 could only be used with shoucastv2? is not possible give other option to aac streams?

I did read other post about shoutcast v.2.2.1 and I make a update in server to see if a problematic account will stopt to restart. I will post here the test result.

Like the major problem could be bugs in shoucast, sc_transcv2 or other software not related with centova would be good identify what could be the commom factors that cause that.

Excellent suggestion.  The problem is just that it's not always easy to determine exactly what causes a crash in a closed-source program that's made by another company.  In most cases, without the source code, unless you can reproduce the crash consistently every time you perform a specific action, you have no way of knowing what's causing it.

To be clear, we're not trying to say "it's not our software so it's not our problem" -- we hear that a lot from clients who don't understand why we can't help them with DNAS2/sctrans2 crashes, but that's not the case.  We've had clients encounter crashes under IceCast before, for example, and while IceCast isn't our product either, it's open-source so it's not hard for us to run it under a debugger and get an idea of why it's crashing.  And then we can suggest a workaround, or modify Centova Cast to avoid triggering the crash.

With DNAS2, the only crash that we've been able to consistently reproduce (and thus diagnose) is caused when using sctrans2 with MP3s with certain accented characters in their ID3 tags.  In some cases sctrans2 does not properly UTF8-encode the accented characters, and when it sends them to DNAS2, DNAS2 crashes.

Anyone experiencing crashes should first look to see if it's always the same set of MP3s that causes this problem.  And if so, they should try removing the accented characters from the MP3's ID3 tags and seeing if that fixes the problem.

Again, this was easy enough for us to diagnose because *every* time our client used a specific MP3, DNAS2 crashed.  With that information we were able to narrow down the cause.  Other crash situations are not so easy for us to diagnose, and there is at least one other DNAS2 crash scenario that a lot of users are reporting that we haven't been able to track down yet.  (And unfortunately, we may never be able to unless a clear trigger is found.)

But steve,  sc_transcv2 could only be used with shoucastv2? is not possible give other option to aac streams?

Yes, we're working on it!  We should hopefully have a preliminary release with support for an sctrans2 alternative (including AAC support) by the end of the month.

In one case here, after I changed to the new SHOUTcast Server v2.2.1.109 the the constant restarts stopped. The same mp3 and account that was restarting each 30 minuts now works fine. So I believe that the new Shoutcast v2 have fixed some bugs. I don't know if that is a solution for all cases, but is a very good news to me.

And goog to hear too that centova will add more options to aac stream early.

Unfortunately, I have to agree with you Steve, but it was hard.
I realized that the problem only happens with the files with  specials chars if it is renamed after shipping (within the panel), if sent via FTP third party programs, or if they are migrated from one account to another, regardless of the process used.
If you upload these the same files of MP3  via panel, the problem does not occur.
What I do now is to guide my clients to uploads via  panel and not rename uploaded files. With that, I have no more problems with rebooting the server and the flood of emails with this notice in my inbox.