sc_trans2b5 - Error'Msg' => Data arriving too fast ...

[OM-SKremer]

Hi,

I use sc_trans2b5 now for more than one year, every day and with ~20 dj's.

Now, yesterday we becomes extremly problems with the Stream/sc_trans, every 10-15 minutes disconnect sc_trans from the Shoutcast server.

In the logfile are thousands entrys like this:

code:
2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:04     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:05     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:05     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:05     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-29 18:01:05     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

........

the whole time a DJ is connected, reconnect doesn't helps.

I searched at google.com and bing.com, but nothing was found, really nothing, so I'm the first person ever who had this problem?!
I hope no, but what means "Data arriving too fast. Some has been lost" there is no documentation about this MSG, or I'm blind?

Points of Interest:
- Linux Server (I'm the only root, no System updates the last 2 weeks, no sc_trans relevates updates/config changes the last 3 months)
- sc_trans2 beta 5 (no problems the last 12 months)
- No sc_trans restarts helps
- The automatic playlist streaming works fine (sc_trans)
- No updates by the DJ Broadcasting Software, all DJ's has the same Problem since yesterday evening
- No update on the Shoutcast Server (v1.9.8)
- No changes on the network [sc_trans & sc_serv] (IPs, Hosts, Ports, routing or something like that the last 5 months)

It's like a ghost, the problem comes, and I don't know why. Please help.

Thanks

UPDATE:
I updated sc_trans2b5 (beta 5) to sc_trans2b6 (beta 6), same Problem.

[OM-SKremer]

I saw the update, but i was not happy to "change a running system" ... but the system was not running so I update after a short brainstorming ... to sc_trans2b6.

Same Problem:

code:


2010-05-30 22:41:50     I       msg:<***>       Logger startup

2010-05-30 22:41:50     I       msg:<***>       version 0.2.0.0 build 0.0.39.0



<... other things, and ~15 minutes of testing by a DJ ...>



2010-05-30 23:08:49     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-30 23:08:49     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-30 23:08:50     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-30 23:08:50     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-30 23:08:50     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

2010-05-30 23:08:50     E       msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

The problem is still there, sc_trans2 disconnects from the server, all listeners kicks from the stream, the DJ+Listeners must reconnect and after 5-15 minutes the Problem comes again. There are no more debug msgs, any ideas?

[djares]

Well this is weird. After 7-8 months of transcoding without any issues, this woke me up just now (currently 2:05am in Los Angeles...)

2010-11-09 01:35:35 I msg:[titleupdate] receiving DJ metadata "Some random song title info here"
2010-11-09 01:35:35 I msg:[titleupdate] relaying DJ metadata
2010-11-09 01:35:36 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:35:36 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:35:50 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:35:51 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

And, as in your case, ~12 entries like that per second.

The only thing I can think of is our "ol' reliable" DSL connection was out, so the load balancer had us on the failover connection not normally used. Maybe that secondary ISP has started doing some sort of packet-shaping or otherwise f**king with of the data we're sending to the transcoding server..?

OM-SKremer: Did you ever find what the cause was? What sort of ISP were you using when this happened?

Thank you.

[Jkey]

may I ask,Is there a dsp plugin v1.9.2 anywhere in your setup ?
I.e A dj using it.

[djares]

No sir, using tried and true Orban Opticodec + PC card.

[matutos]

Solved?

Well this is weird. After 7-8 months of transcoding without any issues, this woke me up just now (currently 2:05am in Los Angeles...)

2010-11-09 01:35:35 I msg:[titleupdate] receiving DJ metadata "Some random song title info here"
2010-11-09 01:35:35 I msg:[titleupdate] relaying DJ metadata
2010-11-09 01:35:36 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:35:36 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:35:50 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:35:51 I msg:[shoutcastmetadata] Sending metadata
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost
2010-11-09 01:37:16 E msg:[djProtocolShoutcast] Data arriving too fast. Some has been lost

And, as in your case, ~12 entries like that per second.

The only thing I can think of is our "ol' reliable" DSL connection was out, so the load balancer had us on the failover connection not normally used. Maybe that secondary ISP has started doing some sort of packet-shaping or otherwise f**king with of the data we're sending to the transcoding server..?

OM-SKremer: Did you ever find what the cause was? What sort of ISP were you using when this happened?

Thank you.

Hi, how he managed to solve this problem? Thanks

[djares]

You know, after all this time I'm not entirely sure what caused this, BUT just after posting in this thread I connected that machine directly to the Time Warner modem and experienced the same problem. After fiddling around a bit, my final conclusion at the time was that Time Warner/Road Runner must poison packets intentionally.