Garbled Stream Since Trans Drop 6

[Chief_1957]

Helllo,

Since upgrading to sc_trans2 drop 6, I have been getting a garbled stream after about 10 minutes and the only way to fix this is to restart sc_trans. The logs show an error message along the lines of "Data being sent to fast". sc_trans_linux_12_14_2010 gives me the same problem.

If I go back to drop 5, the problem goes away. This is a major issue as I like some of the features in the latest beta like the include= statement within the config file... not that it's much.

Can you please look into this and let me know when there is a fixed beta to test


Love the software guys and keep up the great work.



Thanks,

Chief

[jaromanda]

have you tried the latest .... i.e. build 40 http://forums.shoutcast.com/showthread.php?t=324841


edit: ... oops, didn't read your post fully, it seems you have

[DrO]

hard to fix when i can't repro the issue. are you just purely running sc_trans to a DNAS or do you have other sources connected to sc_trans? i.e. DJ's or on an input source, etc.

-daz

[Chief_1957]

Hello DrO,

sc_serv2 also appears to cause the problem. If I use sc_serv_1.9.8 and sc_trans_drop5, I have no issues. Upgrading above those versions causes the garble.

I had SAM4 connecting to sc_trans as a sc_serv v1 source.

96kbps, 44.1MHz Mono (MP3)

If I stream music for over 10 minutes (continuously) sc_trans / sc_serv starts to get behind and drop packets to try and keep up.

Have you guys changed MP3 decoder/encoder since those versions??


Thanks

[Chief_1957]

It just happened with those versions to. I feel so helpless

edit: I have changed the stream to 64kbps just in case it's a problem with the servers download speed.... just a stab in the dark at a one month long problem.

[DrO]

Originally Posted by Chief_1957

sc_serv2 also appears to cause the problem. If I use sc_serv_1.9.8 and sc_trans_drop5, I have no issues. Upgrading above those versions causes the garble.

maybe it's something with the client that you're using, or there's an issue with the upload speed (as per you following post).

Originally Posted by Chief_1957

If I stream music for over 10 minutes (continuously) sc_trans / sc_serv starts to get behind and drop packets to try and keep up.

the only time i've seen that was in my linux vm before i upgraded to the newer virtualbox though high cpu usage on a machine can lead to that happening as well based on something else i saw on another machine i've been tinkering with things on.

Originally Posted by Chief_1957

Have you guys changed MP3 decoder/encoder since those versions?

i don't believe there's any change in the mp3 encoder between the different sc_trans builds (i've not updated it as part of the sc_trans updates). i know that build 39 -> build 40 is probably built with a different compiler but with drop5 ->build 39 i'd assume it was the same compiler used (before my time). ironically, that's the only encoder / decoder which has not been updated in some way with the newer sc_trans build 40 and in the dev version (which uses newer aacplus libs allowing a linux x64 build).

-daz

[Chief_1957]

Ok, after doing some testing I have come to realise that the following is happening.

1. SC_Trans connects to SC_Serv
2. SC_Trans streams okay
3. SC_Serv stops accepting packets
4. SC_Trans chokes as it's still getting data from the source but SC_Serv won't accept it
so SC_Trans's buffer becomes full, very fast
5. SC_Serv accepts packets again, but SC_Trans now has a corrupt buffer :s

What could cause sc_serv to go silent like that??
If I go to the sc_serv admin.cgi it says "Server Status: Server is currently down."
But sc_trans still says it's connected to sc_serv...



Thank you

[Chief_1957]

This is sc_serv's last log entries:

2011-04-13 16:49:21 E msg:[SRC 59.167.140.30:49574 sid=1] [SRC 59.167.140.30:49574 sid=1] Timeout waiting for stream data
2011-04-13 16:49:21 E msg:[SRC 59.167.140.30:49574 sid=1] Timeout waiting for stream data

This is sc_trans last log entries:

2011-04-13 16:44:59 I msg:[titleupdate] receiving DJ metadata "360%20Ft%2E%20Pez%20%2D%20Just%20Got%20Started%20%28Auto%29"
2011-04-13 16:44:59 I msg:[titleupdate] relaying DJ metadata
2011-04-13 16:45:01 E msg:[DJPROTOCOLSHOUTCAST] Data arriving too fast. Some has been lost
2011-04-13 16:45:01 E msg:[DJPROTOCOLSHOUTCAST] Data arriving too fast. Some has been lost
2011-04-13 16:45:01 E msg:[DJPROTOCOLSHOUTCAST] Data arriving too fast. Some has been lost
2011-04-13 16:45:01 E msg:[DJPROTOCOLSHOUTCAST] Data arriving too fast. Some has been lost
2011-04-13 16:45:02 E msg:[DJPROTOCOLSHOUTCAST] Data arriving too fast. Some has been lost
2011-04-13 16:45:02 E msg:[DJPROTOCOLSHOUTCAST] Data arriving too fast. Some has been lost

[Chief_1957]

Is there somewhere in sc_trans to set the re-connect time??

2011-04-13 18:13:20 E msg:[UVOX2] 5635 [UVOX2] 5635 socket send error.
2011-04-13 18:13:20 E msg:[UVOX2] 5635 Waiting 60 seconds

I think it's the 60 seconds that's causing the issues.

[DrO]

internet connection issues usually appear to be the main cause leading to that scenario with the data arriving too fast. there isn't an option to change the sc_trans wait though you can change the autodumpsourcetime (or streamautodumpsourcetime for per-stream configurations) value to something higher (there's a bug with the current v2 dnas where setting to 0 will prevent connections which has already been fixed for the next release.

-daz

[Chief_1957]

Changing that to 120 fixes the dropping of sc_trans, but clients still buffer for a long time when this happens, will changing the sc_serv buffer size fix this and if so what value should i try?

[DrO]

clients are unfortunately going to buffer if an issue happens like that as there's not much which can be done if they're basically receiving some 'junk' packets from the buffer.

it may work better if you change it to a smaller buffer size so less of the 'junk' is kept, so maybe changing it to the adaptive type (buffertype=1) and adjusting adaptivebuffersize as needed (default is 1 second) might help but it's one of those things where you're going to have to play with things as such things seem to be specific to different systems so there's not usually a one fit all solution.

-daz

[Chief_1957]

In a DJ->trans->serv->serv scinario, where is the best place to have the most lag?

i.e. Would DJ->trans--lag-->serv->serv

be bettor/worse or no different to

DJ->trans->serv--lag-->serv