Icecast Streaming Media Server

[Anonymous]

Okay, I've been reading around the forum for a while and I just can't figure it out. I have 2 DJs on my server. I want to make it so when one DJ disconnects the sever automatically redirects to the other DJ whom is the autodj. I have configured the server to what I think its supposed to be, which is 2 mountpoints with fall-backs. The only thing is that when I disconnect one server the client just sticks. Doesn't move or disconnects, just stays. thats in winamp; in windows media player it just keeps buffering nonstop. Any help would be much appreciated

[karlH]

First thing to make sure of, is that both DJs are playing in the same format, players tend to dislike changes to things like samplerate/channels and format midstream.

Second, the setup best for that sort of setup is, listeners connect on say /A, where /A is a relay of the autodj mountpoint. The DJs have their own mountpoint which overrides and falls back to the autodj mountpoint. DJs can have their own user/pass, and /A is a statically named mountpoint for listeners.

karl.

[Anonymous]

Both DJ's are playing 96KBPS, 44KHZ. The first DJ is the fall-back dj and the second one is me which goes live as well as the other one. I have i setup for the 2 mountpoints but when one disconnects it doesn't go to the second one

[karlH]

Well that is a different setup to what I said, If you don't want to use a relay then you can use a single fallback if you want. eg /chuck as the autodj which has no fallback setting but can be hidden and /sammah which falls back to /chuck (with override). Your source client then connects on to /sammah and takes listeners whenever you are on and drops them to /chuck whenever you disconnect.

karl.

[Anonymous]

well i need to know what i need to do to make it not put the clients in an endless buffer when I change DJ's.

[karlH]

Assuming you have the fallback setup and the 2 streams are compatible then nothing else is required.

karl.

[Anonymous]

Guys:

You can't image how many small radio station trying out ICEcast according to our recommendation changed back to Shoutcast because of loosing listeners during a DJ change!

The fallback function is also buggy, the duration of playing the fallback file increases and increases with each DJ change.

karlH:

Here us and pay attention to the comments and statements of the ICEcast users!

Please add a function to keep listeners connected at the current mountpoint for a time period in seconds which could be set by parameter before the clients are forwarded to the fallback mount or are disconnected form the server if no fallback is configured. Shoutcast has it, why not ICEcast?

Don’t tell us again this function can’t be included because of “performance reason”.
No small station with 20 or less listeners can accept this ICEcast behaviour.

If that forum here is not the right place to discuss this issue, so please provide me the direct contact to the ICEcast developer team.

[Anonymous]

I've switched from Shoutcast to Icecast on my radio and I can say that fallback works like a charm. I have an mp3 stream as a fallback and a live dj stream as main public mount. The only two things that can cause problems are different channels or samplerates as karl said

[Anonymous]

karlH/aspin:

Of cause the fallback function works, your channel and bitrate mode comment is right, but not what I meant:

Example:
Conditions:
a) You have fallback MP3 of approx. 15 sec duration in the same channel, sample- and bitrate as the previous and next live stream, i. e. all DJs use the same encoder settings!

b) A DJ change takes aporx 5 sec, i. e. the actual Dj disconnets from stream the next connect to.

During the first DJ change (A->B) the listeners hear the fallback for few seconds, let us say 5 seconds then they are take back to livestream of the next DJ (B). That’s works fine, you are right!

Now DJ B has finished his broadcast and DJ C is on the schedule, the live source change here is also done very quickly in few seconds but the listeners are hold on the fallback for much longer time than the first time.

Two hour later next DJ (C) comes: DJ C -> DJ D, quick source change, but the fallback runs now longer than at the second time.

-> The duration of the fallback play increases with each DJ change, also when the DJ change time (disconnect / connect) is very short everytime.

For small station with a lot of DJs and serveral livesource each day programme this circumstance is not acceptable.

We tested it several time with Winamp Player / MS Media Player and Real Player. We also played with the fallback file duration, but it doesn't matter if fallback has only 5, 10 or 60 seconds. The duration of the fallback does not have influence how long ICEcast needs to recognize that a ive source is avaialable to forward the listeners back to it.

As already explain, this recognation time grows with each live souce (DJ) change.

Regards, Adam