Icecast Streaming Media Server

[Alaska]

We use Icecast version 2.3.1 to stream mp3 files. An introduction file plays before live audio is sent.

Recently, 3 or 4 users have complained that the stream drops out right after the introduction plays. The common elements are: they use Windows Vista with Windows Media Player. The listeners are located at some distance from our server - 500 or more miles away - as one Vista/MP user had no problem in the local area. The server generates an error message indicating the "client ... has fallen too far behind, removing."

No other listeners have complained about this problem; we cannot duplicate it on other players and operating systems.

We have the burst-size set at 65535 to minimize any problems with network congestion and have burst-on-connect turned on. The queue-size is set at 524288. Perhaps these settings are too big, or small?

Any suggestions on what might be causing the problem or solving it?

[karlH]

Don't expect WMP to handle VBR streams properly, make sure that the channels, samplerate and bitrate are the same for both the intro and the stream.

karl.

[Alaska]

Thanks. The settings in both the file and live audio stream were set to the same settings when the server was set-up earlier this year.

The settings we are using are CBR, 48kbps, 22kHz.

Does Icecast have to sync the intro file with the live stream? If so, would the Vista/MP combo be so sensitive as to detect a slight inconsistency where other players would be more forgiving?

[karlH]

Icecast does not do any sync. Do these users show this problem all the time or just some of the time? If only some of the time then it could be just a quirk of the network they are going across to get to you, could be proxies, congestion, or just that WMP is not that good.

The log message you mentioned before is when icecast drops the listener because they are queue-size bytes behind, so 500k.

karl.

[Alaska]

The Vista/MP users suggest that the problem is consistent; although one user said his same system worked when he lived where our server is located.

I captured the audio stream and used "MPEG Audio Info" (a program written by Konrad Windszuz and obtained at http://www.codeproject.com/audio/MPEGAudioInfo.asp) to examine the frame information.

The program indicated a change in sampling rate at the switch point frame from 22050 Hz to 48000 Hz at the frame following the intro file. This same frame indicated a change from Layer III to MPEG 1. After this "bad" frame that varys in length, everything returns to normal settings of 22050 Hz and Layer III. This program is also interpreting the stream as VBR with an average bitrate of 48 kbps (perhaps because of the bad frame at the switchpoint and an incomplete frame at the end of my capture).

Perhaps this glitch is what Vista/WMP is catching on. But it would seem to me that dropped packets due to network congestion would create the same problem (or would be interpreted in the same manner).

I do recommend that the user try Winamp or another player.

Any suggestions? Thanks.