Icecast Streaming Media Server

[DJ-Zath]

Hi karl and everyone!

This one's been going on for quite awhile..

During a broadcast, the listeners report "blurps" in the stream.. at first, I thought it was a connection issue and spent a considerable amount of time, resources and money (even changed ISPs) and yet, this problem still exists..

Severe cases of this has that "max headroom" effect where the last "chunk" of frames/audio (a buffer) repeats for up to 5 to 20 seconds...

The server is a dedicated box with a 1 Gig NIC, 4-core Xeon CPUs and 2 gigs RAM.. the box is running FreeBSD 6.x and is fully-patched and secured. The box lives in a datacenter connected to the local backbone, (in essence, its the BEST connection in town!) The load averages are no less than 95% free (I mean its 95% to idle) at ANY time.. it doesn't matter if its 1 listener, 2 listeners, 5 listeners or 20 listeners.. the effect appears the same for all listeners (even myself when I tune in "on the return").

I have tried (re)setting buffers and burst sizes and functions with no luck... the best discription of this problem is a "jump-ahead" every couple of minutes or so.. sometimes its just a single jump-ahead, sometimes its a few "frame repeats" and, in severe cases, its like

"maxxmaxxmaxxmaxxmaxxmaxx headheadheadheadrooooomooomooomooomooomm"

I have tried everything- even rebuilding the machine from scratch.. I'm sorta puzzled at this poiint.. any suggestions would be appreciated thanks!

-DjZ-

_________________
-DjZ-

[karlH]

Is this 2.3.2, and are you getting this in one connection, ie it's not the player reconnecting? I would try getting a sample of the content with curl or wget, large enough to capture this effect and then try playing it back as a file, maybe verifying the content as valid.

karl.

[DJ-Zath]

Hi Karl and thanks for the reply

sorry, I forgot to mention the version, its Icecast v2.3.2 "trunk"

and now for the latest:

all the connections seem to do it "together" as far as I can tell, there doesn't seem to be any connection issues- even if I ping the box continueiously during the tests..

I have, however, recently-noticed that a squeezebox radio tuned in will also "drop" the connection during extreme events and then re-establish. (since the intro file will be heard again) as far as I can tell, other players will continue to play (of course, other listeners are resetting their own connections during extreme events).

After posting here, last night, I decided to run some system-wide diagnostics in which, one test involves playing solid tones into the stream.. In doing this, I have discovered the "blurps" are a LOT more frequent that I initially-stated.. in fact, they are pretty much continueous! and, are pretty-much "small" and un-noticed in normal program material, however, a constant tone at ANY frequency reveals the anolomies quite easily and aubibly.

I will run some additional tests now, and see if I can find out more info.. I can attempt to curl the stream during an event, but they are usually too short-lived; of course, unless I just happened to catch it "at that exact moment".

this one has me puzzled!

-DjZ-



it is v2.3.2
_________________
-DjZ-

[Brutish]

What did your results show on your hops?

Actually, the real question would be what are you using to run test on your server with?

I usually use WinMTR, and have it set for 100 intervals. Just to weed out all of the possible hop issues.

Also have you put the source to server as a source and checked it? I have a streamer with rock solid streaming (right off the datacenter) if you want me to point it to the server let me know.
_________________
www.Hobbycaster.com

[Brutish]

http://icecast.imux.net/viewtopic.php?t=7508

Somebody else was complaining about this same issue. You might want to drop them a line and see what they found out.
_________________
www.Hobbycaster.com

[DJ-Zath]

hi and thanks for the replies..

I am using WinMTR

hops are showing "slight" packet loss throughout the entire run.. but nothing "out of the ordnary"

I can see theres SOMETHING going on as far as the streams go..

I'm losing 10 seconds for every "3 songs" (on average)

In other words, using Winamp as a player (for this test), its "out of buffer" by the 5th song.. I think thats excessive!

(thats "to be added" to the other problems I reported eariler..)

I'll look up the other thread and see if its related to what I'm getting..

-Zath-
_________________
-DjZ-

[DJ-Zath]

okay, I had a look at that other post...

I'm not running a "winamp caster" perse.. where one simply streams mp3s..

I have a full studio with lots of dedicated hardware that creates the streams independant from the program content.. in other words, I can send a DEAD carrier as one continueous stream from start to end.. theres no "stream and restream" of program audio (a simple playlist of tune-to-tune)

thanks for the link, in any event.. It was worth a read..

as for your "relay" I may try that.. but I can only add that as its own port/service since you can't "fallback to a fallback" in icecast

but, thats an idea for testing the server side of the connection.. (but I'm not entirely sure thats where the problem lies)

I'll keep you all posted... in the meantime, if you want to have a listen, come find me ( at warp-radio dot com ) and I'll demo this for you...

-Zath-
_________________
-DjZ-

[DJ-Zath]

UPDATE:

I have a small update..

Though I haven't been able to confirm this conclusively, it appears to be a UDP port issue.. whereas the incoming stream on a UDP port is then sent to a perl script which "converts it to TCP and logs it into icecast"... although the script itself doesn't "buffer" the frames except for 2 ahead, since the "max readroom effect" is a considerable amount of frames "repeated at once", I don't suspect this script, however, this problem DOES seem to be related to a "delayed arrival" of the initial UDP stream...

again, this isn't conclusive.. just ODD!

(I suspect its somethig screwy happening at the datacenter)
_________________
-DjZ-