Icecast Streaming Media Server

[Guest]

I've got Icecast 2.3.1 running on a Windows 2003 Server, and I can successfully feed it an MP3 stream from Nicecast.

However, when I try using libshout 2.1, built on Red Hat EL4, as an MP3 source instead, the client won't begin playback. Instead, it sits there trying to buffer 100% of the stream, which of course will never happen. When I kill the source process, playback instantly begins, since the client now has 100% of the file.

I've tried three libshout sources: the ruby-shout example, the libshout example, and ices 0.4. And I tried both WMP10 and Quicktime 7.0.4 clients on Windows XP.

Is there something I need to configure in libshout to fake out file sizes, or something like that?

icecast.xml:

<icecast>
<limits>
<clients>100</clients>
<sources>2</sources>
<threadpool>5</threadpool>
<queue-size>524288</queue-size>
<client-timeout>30</client-timeout>
<header-timeout>15</header-timeout>
<source-timeout>10</source-timeout>
<burst-on-connect>1</burst-on-connect>
<burst-size>65535</burst-size>
</limits>

<mount>
<mount-name>/topdir/testing</mount-name>
<username>source</username>
<password>ourpassword</password>

<hidden>1</hidden>
<no-yp>1</no-yp>
</mount>

[Guest]

Er.. that's libshout 2.2, not 2.1.

[karlH]

If wmp10 or quicktime are showing that behaviour then it needs to be reported to them. It could be that quicktime is showing the problem because it was started with an m3u and not with a pls file. Not sure about wmp, it's reported to work for many listeners.

karl.

[Guest]

Sorry, I guess I wasn't clear. In both cases - Nicecast source and libshout source - I'm playing a 128k MP3 file, broadcasting to a mount point, which is accessed as an m3u.

When I broadcast w/Nicecast, it works fine.

When I broadcast w/libshout, I get the aforementioned non-streaming behavior.

So something's different in either the source, or the way the icecast server treats it.

If this isn't a known bug, and if you can't repeat it, what can I do to troubleshoot?

[karlH]

Can you verify that the all the stream details (mountpoint, type etc) are the same for both source clients on the http://<host>:<port>/status.xsl page.

karl.

[Anonymous]

Interesting... they're different on the admin stats.xsl page. The working (NiceCast) stream mount-point info starts with "bitrate: 128". The bad (libshout) one starts with "audio_info: bitrate=128". So libshout is sending that header differently.

Quick, pre-coffee search of the source shows that that audio_info comes from an ice-audio-info: header from the source. It gets put into source->audio_info, but nobody but YP ever looks there.

However, format.c goes back and looks at the original headers. If ice-audio-info is present, it sends icy-br: [bitrate], and then it sends the whole original header for a relay to use. (Doesn't look like there's anything that's logging what the full header was.)

If the source has sent icy-br:, or ice-bitrate:, that gets sent down to the client as well.

Best I can tell, it does not send -anything- down to the client when the source has sent x-audiocast-bitrate.

So a few possibilities:

1. There's something extra in the icy-br: header from libshout that's throwing off the client. Doesn't seem likely, from reading the libshout source.

2. Nicecast is actually using the x-audiocast-bitrate header, which will show on the status screen but not get sent to the client, and maybe that causes them not to wait for the whole file.

3. Something else.

If this gives you any ideas, let me know.. otherwise, I will go fire up Ethereal in a few hours and check out what's actually getting sent in both directions. I wish Ethereal understood icy natively..

Jay Levitt (Oh! And look, I remembered to log in this time. Go me.)

[Anonymous]

And the answer is:

3. Something else.

If you're going to try to broadcast MP3s that are not encoded at 128k, you're going to want to enable reencoding, or your clients might act funny.

Sigh... sorry, guys!

Jay