I have been using ices-cc with Shoutcast 2.4.7 for quite a while with no issues. I just upgraded to SHOUTcast Server v2.5.0.715/posix(linux x64) this week and have been experiencing issues ever since. I'm curious if anyone else is using this setup.

Generally the error I see in the Shoutcast logs is: "ERROR   [SRC 10.0.2.226:41928 sid=1] SHOUTcast 1 source disconnected. Unable to sync to the stream. Please check the source is valid and in a supported format."

I turned on full Shoutcast debugging last night, and the log quickly grew to 500MB with the repeated error: "DEBUG   [DST xxx.xxx.xxx.xxx:32563 (xff) sid=1] Bad frame found at pos: 65270

• , 0(128), 0(48000)".

In the ices-cc log, the error is: "Error during send: Libshout reported send error, disconnecting: Socket error"

I'll post this in the Shoutcast forums as well.

Thanks,
Mike

Dunno if you ever got a solution on the SC forums (I don't go there) or if you contacted their support, but the issue is a side-effect of the advert related handling improvements that were put into 2.5 where it tries to ensure that the audio data it's receiving is correct (i.e. it's getting what it deems to be valid and complete audio frames). That all is then part of trying to keep a better track of where things are in the stream to ensure that when adverts are played that they transition into and out of them reasonably close to where they should be in the original data stream.

One option if still seeing the issue with a 2.5 DNAS (by now I'd have to expect you've gone back to a 2.4.7 or something else if it wasn't fixed in the 2.5.1 update) is to set ratelimit=0 which disables most of the checking and might help with the issue (though it's a bit hit & miss based on the results with someone else I helped out a month or so back).

Another thing to check is the details of the encoding being used as I see 48kHz being reported from your log snippet along with invalid values for the processed data frame which might be causing the checks to fail unexpectedly if what is reportedly being sent isn't what is actually being received (another check that was put in place to help ensure that intro & backup files are correct for the stream being played).

-dro