Icecast Streaming Media Server

Fjellslange · Joined: 31 Dec 2008 Posts: 7

Greetings. I'm using icecast2 2.3.2-2 and Darkice 0.19-1 on Debian for a local streaming setup. I want the stream to never time out. Currently when silence (which can last over 30 minutes) is broadcast I have to disconnect and reconnect to the stream before hearing anything again. I tried setting

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

I suppose we could have a special case for 0, but just specify some huge number instead

karl.

Fjellslange · Joined: 31 Dec 2008 Posts: 7

Thanks for the quick reply. When I do that the stream never prebuffers unless something is already playing. Once I start playing a track (with MPD) a little data is sent and played, then quits. The stream stops shortly thereafter. So I have to have something playing before I connect.... This happens with Audacious and mplayer, so the player doesn't seem to be at fault.

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

If the stream stops then there has to be a reason, either icecast drops it or the source client does, check the error log. Note that the source timeout will be unaffected with silence as that means audio is still being streamed.

karl.

Fjellslange · Joined: 31 Dec 2008 Posts: 7

This seems to be the relevant portion of the log file:

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

These messages do not indicate the stream is dying. They indicate that the player or the connection to the player is not sufficient, ie the the data rate of icecast to player is lesser than source client to icecast.and the buffer in icecast is now at the trigger point at which the listener is dropped.

without checking the stream myself it's hard to say, the figures reported look odd but it does depend on what you are really doing.

karl.

Fjellslange · Joined: 31 Dec 2008 Posts: 7

That's the puzzling thing; typical transfer rate is about 1/3rd of my available bandwidth and the problem only happens if there is not music playing (in other words silence). As soon as there is silence the network activity goes very low; is that normal? Or should it stream at a standard rate the whole time, silence or not? That's what used to happen until I used alsamixer to choose my capture source. When resuming from silence a little data is sent, then a blip of nothing, then more data and then nothing. The player doesn't start playing and times out after that.

icecast.xml:

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

make sure the bitrate of 448 is not confusing things, I'd use ogg123 to check the ogg data stream to make sure it's what you expected.

karl.

Fjellslange · Joined: 31 Dec 2008 Posts: 7

Noticed that right after posting. Didn't solve anything and it turns out it's valid to have both a quality and bitrate when using CBR or VBR with Vorbis. Also downgraded Icecast to the stable version, but that didn't help either.

So on to a fun night of troubleshooting... tried streaming through VLC - that solves the problem of getting sound after resuming but starting is still a problem. Tried with gstreamer and it's the same issue.

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

If you skip over things and don't state your goals then you'll lose people.

According to what you have posted, 448kbps is what you wanted not quality 1.0 (which is around 80kbps for those settings)?

EOS is valid, you should receive them at the end of a chain. A typical example is just before a new track or when metadata updates occur.

karl.

Fjellslange · Joined: 31 Dec 2008 Posts: 7

Sorry if I'm unclear. Got a nasty case of gunk in the head so just ask if there's info you need or something I'm neglecting.

Goal is to play the stream without having to restart it (due to being dropped if there's not active noise being broadcast, apparently). Currently if I start the stream before any music is playing it drops and some players drop if there is too much silence between songs. Not sure what's going on since it was working a month ago Sad

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

according to the log you posted, the stream doesn't drop, but there are 2 listeners that disconnect. The first because they disconnected, the second because they had lagged so far behind that icecast had to drop them.

What I'm wondering is that if you are dropping from an average of around 448kbps to just above 0 with silence then maybe you are confusing some players because a prebuffer full of silence will take some time to playback. Maybe you need a minimum bitrate for those cases.

Ask yourself, what is your target bitrate/quality setting, I've asked this a couple of times now.

karl.

Fjellslange · Joined: 31 Dec 2008 Posts: 7

I see what you're getting at now Embarassed

must be cuz a few pints of gunk have drained out of my nose. I tried lowering the bitrate (commenting out quality) and that seems to solve the problem. Seems a bit of a waste though; all that unused bandwidth sitting there, so how would I set a minimum bitrate?

karlH · Code Warrior Joined: 13 Jun 2005 Posts: 5476 Location: UK

I cannot comment on the usage of bandwidth, most people are more concerned about paying for the bandwidth for the number of listeners they want.

Whether you want to specify bitrate or quality is up to you, it's just both that does not make sense. As for the minimum bitrate setting, you'll have to consult the source client documentation.

karl.