SC 2.5.5.733 stream disconnecting

[AxisNL]

Hmm.. forum seems to have ate my previous post..

I have client that sends its radio stream to my Shoutcast 2 server. Worked fine, his hundreds of users were happy. He was using DSP 1.9 to stream to our SHOUTcast Server 2.5.5.733.

Then we migrated him to a new server, everything seemed well, decommissioned the old server. Both old and new server are running the same sc 2.5.5.733 on linux. (Installed by Cast-Control mediacp).

Then we got a call from the client that his stream was disconnecting once or twice a day. He upgraded DSP to 2.4.3, but to no avail. Can't seem to pinpoint the issue.

I enabled debugging in the dnas log file, shows:

2018-04-18 23:08:34 DEBUG [STREAMDATA sid=1] frame match failed, resync set to 0
2018-04-18 23:08:38 DEBUG [STREAMDATA sid=1] frame match failed, resync set to 370
2018-04-18 23:08:38 ERROR [SRC x.x.x.x:1253 sid=1] SHOUTcast 2 source disconnected. Unable to sync to the stream. Please check the source is valid and in a supported format.

This indicates there's a problem between the client and the server, but not exactly why or what. Googling won't get me a lot further.

Do you guys have any ideas?

[ram130]

Sounds like a issue on the client end(ISP) since nothing much changed. I would reboot all servers and modems on both ends.

[AxisNL]

Originally Posted by ram130

Sounds like a issue on the client end(ISP) since nothing much changed. I would reboot all servers and modems on both ends.

Yeah, we figured out as much as well. Running a lot of pings reveals packet loss at the same time as the disconnects.

I would expect Shoutcast to have some extra error handling for connections, and spit out nice error messages like: "lost connection to source". It does not.

Since I think I'm not the only one having netwerk connection issues in the world, I would expect google to turn up at least some results when searching for "frame match failed". It didn't

Well, I guess case closed..

[ram130]

Originally Posted by AxisNL

Yeah, we figured out as much as well. Running a lot of pings reveals packet loss at the same time as the disconnects.

I would expect Shoutcast to have some extra error handling for connections, and spit out nice error messages like: "lost connection to source". It does not.

Since I think I'm not the only one having netwerk connection issues in the world, I would expect google to turn up at least some results when searching for "frame match failed". It didn't

Well, I guess case closed..

Funny thing I’m also having issues. I’m not if you’re using the streaming service as well but I’ve been getting connection issues with them. I don’t know the cause, it also seems to consistently happen around now (night time here In nyc) and some times randomly during the day. I can’t connect without being disconnected after a few minutes or just buffering and skipping issues. Yet others reports fine. Their stations are up fine. Then some days it’s just smooth as hell for me. This all started last week. Before that had no issues. Shoutcast customer service is pretty non existent.

So far today someone on another forum gave me a idea and I changed my DNS from Cloudflare back to Google’s DNS. I initially was hosting my stream with my host and I had switch Cloudflare DNS. I had noticed some connection issues at first, even on my laptop and the stream connecting to my host at times, but I blamed it on the fact they just announced the service. Either way I suspect it again and think it’s causing my issues on the streaming service, so I just changed it today. So far things are stable. Giving it 2 days before I call it.

Either way. Not sure if it’s related as I’m sure you’re not using the shoutcast streaming service. If not I think a reboot will sort things out. Sometimes routers get build up and cause issues, likewise modems. Both of which I also rebooted today.

[JCAlexandres]

Changing to version 1.x mode, the issue doesn't happen, it eventually happens if I let SHUTcast to login using v2.x or automatic. Also, after lowering the encoder settings to 128, using V2.x reduced the amount of issues and disconnections to almost none.