Sync To Stream error

[BLCR]

Can someone explain what causes this error, and what the fix is?

ERROR [SRC xx.xx.xx.xx:xxxxx sid=1] SHOUTcast 1 source disconnected. Unable to sync to the stream. Please check the source is valid and in a supported format.

Thanks!

[jaromanda]

what are you using to source DNAS?

[BLCR]

I believe the customer said they were using SAM.

[jaromanda]

Yeah, I've heard SAM is utter garbage when it comes to streaming

[drivehell]

The problem keeps occurring for us too. We have to switch to a different bitrate or restart the sc_serv for it to start working again

[drivehell]

Happened again today.. This is killing our daily #'s.





Option 1 - to get around the problem I have to turn off the encoder and switch to a different bitrate and connect again which succeeds. After that I can change encoder back to original bitrate and it works.

Option 2 - restart sc_serv

SHOUTcast Server v2.5.1.724/posix(linux x64
on Ubuntu 16.04.1 LTS

sc_serv config:

code:


;DNAS configuration file

;Made with the SHOUTcast 2 Configuration Builder



password=xxxxx

adminpassword=xxxxxx

portbase=8000

requirestreamconfigs=1

logfile=logs/sc_serv242.log

w3clog=logs/sc_serv242_w3c.log

w3cenable=0

publicserver=always

banfile=sc_serv.ban

ripfile=sc_serv.rip

maxuser=250

maxspecialfilesize=115000000

relayconnectretries=0

ratelimit=0



;MAIN CHANNELa

;------------------------

;main mp3

streamid_1=1

streampath_1=/dnbradio_main.mp3

streammaxuser_1=250

streamautodumpusers_1=0

streamallowrelay_1=1

streampublicserver_1=1

streamauthhash_1=xxxxxxx

unique=dnbradio_main.mp3

streambanfile_1=sc_serv.ban

streamlog_1=logs/sc_dnbradio_main.log

streamw3clog_1=logs/sc_dnbradio_main_w3c.log

streamautodumpusers_1=0

;admetricsdebug=1

[jaromanda]

Originally Posted by drivehell

The problem keeps occurring for us too. We have to switch to a different bitrate or restart the sc_serv for it to start working again

Are you using SAM Bastardcaster too?

[drivehell]

Originally Posted by jaromanda

Are you using SAM Bastardcaster too?

The issue mostly likely is on sc_serv side. Even SAM uses the standard LAME encoder.. We are using liquidsoap for another stream and it has the same issues. Additionally, I noticed a relay having the same sync to stream issue -- meaning the relaysource was being rejected with this odd sync to stream error. I believe this is the same issue we had when running our main DNAS on windows. Now the main DNAS is on linux and having the same problem with crashing and sync to stream problems.

[drivehell]

and magically, after days of this happening every few hours, it as stopped.

I can't help but wonder if shoutCAST team is tinkering with their ad platform and causing these issues. If the problem comes back I will start sniffing packets to see what's going on.

[drivehell]

Server completely crashed a few minutes ago:

Here are the log entries right before it happened. notice the same error "Unable to sync to the stream"

2017-05-27 14:08:18 ERROR [RELAY 78.47.134.103:13128/dnbradio_darkstep sid=2] Relay source rejected. Unable to sync to the stream. Please check the source is valid and in a supported format.
2017-05-27 14:08:18 INFO [RELAY 78.47.134.103:13128/dnbradio_darkstep sid=2] Connecting to source relay...
2017-05-27 14:08:18 WARN [ADVERT sid=2] Aborting data transfer due to the stream source disconnecting.
** sc_serv CRASH **

sc_serv relaunched (from CRON)

uptime is now showing 20minutes... this was definitely a crash.

and.. the affect on our listeners...

[Desavil]

I have the same problem on SHOUTcast Server v2.5.1.724/posix(linux x64)

[BLCR]

Wondering if anyone has and idea why this is happening. One radio station has everyone streaming fine, then comes another DJ that gets this error. DJ's after them have no issues. The next day it happens to one of the DJs that had no issues the day before, then we go days before it happens again, etc.

Is it possible the issue can be because they are not streaming at 44,100 kHz? Sadly SAM defaults to 48,000 kHz and users tend to just accept default as gospel. I ask the streaming owner if they were at 44,100 and of course they swear up and down the users are, but... he really has no clue.

Yea, I know... I'm grasping here. Just trying to figure out why this is happening.

[MegaRock]

I've used both 44 and 48 at 320k without issues. Got a lot of other ones but never seen this happen but I am also the only person who connects direct to the servers and using Sam (2014 version) with the latest 2.5.5 DNAS.

[Tormy]

I did get the same issue but not found any solution.

What I did and it seems successful (with SAM), is do not send ANY script during encoding.
Thus, if you have activated ti: just untick the checkbox

[Jason113]

I have the same issue. Is very frustrating. Posting so remember to check incase someone finds a solution.

What I did and it seems successful (with SAM), is do not send ANY script during encoding.
Thus, if you have activated ti: just untick the checkbox