Icecast Streaming Media Server

[heydan]

Hi,

I have a setup which has been working fine. We have an icecast server streaming both a/v and audio streams over a broadband connection which can't cope with many listeners.

So we have an icecast relay on the Internet which relays [some of] the streams from the master server. We only stream on-demand to minimise bandwidth usage.

Both icecast servers are v2.3.2

This has worked well, but we have now decided to put a fallback-mount on the relay so that we have something playing when the live stream is down. The fallback-mount is an a/v file and is about 6 minutes long.

So we have something like:

<relay>
<server>master.server.hostname</server>
<port>8000</port>
<mount>/live.ogg</mount>
<on-demand>1</on-demand>
<relay-shoutcast-metadata>0</relay-shoutcast-metadata>
</relay>
<mount>
<mount-name>/live.ogg</mount-name>
<fallback-mount>/fallback.ogg</fallback-mount>
<fallback-override>1</fallback-override>
<fallback-when-full>1</fallback-when-full>
</mount>
<mount>
<mount-name>/fallback.ogg</mount-name>
<max-listener-duration>900</max-listener-duration>
</mount>

The two problems we are experiencing are:

1) Now when we connect to /live.ogg while the stream is not running, there is a huge wait time of (I guess about 1 minute - I should really time it) before the fallback starts playing. In vlc, there are no messages - it just waits until the fallback starts arriving, and then starts buffering as per normal. In cortado, the applet just remains blank for this wait time before it even starts buffering. If the /live.ogg stream is running, and we connect, the stream starts quickly as expected.

2) You can see that I put a max-listener-duration on the fallback mount. The fallback video is about 6 minutes long. The /live.ogg stream only runs 3 times, one day a week for about 2 hours each time. What I intended by inserting the max-listener-duration setting was to minimise bandwidth usage by ensuring that people would not be able to leave the fallback streaming for long periods of time. I figured that about 15mins was long enough for them to notice the times that the stream is live and also long enough for those turning up early just before we go live each time. But the problem is that the listeners are never kicked off (well I have tested it for about 30 mins and was not kicked). I figure that this is something to do with the fallback file only being 6minutes long (vlc resets time-played to 0 each each time the fallback file repeats).

Can anyone give us any pointers or tips on either problem?

The live URL is http://streams.kingsland.org.uk:8000/service/low.ogg - you may get live or fallback as we are currently playing with the setup. Also, the fallback file format seems off as some players hiccup when it tries to go back to the live stream - but we will get around to fixing that.

Thanks for your help,


Hayden

[karlH]

1. Not sure why it would be a minute. The timeout for a failed relay connection is around 10 secs. The error log may help in identifying the issue but you could also configure is as a slave so that the relay is removed when not available on the master.

2. The timeout only applies when connecting to the fallback directly. There is an argument for preventing a loop or maybe imposing a time limit but no one has put that forward, but should be possible to add it.

karl.

[heydan]

Hey, thanks for your reply Karl

1) I did say that the 1 minute was a guestimate It turns out that the delay is any time upto 2 minutes. Here is some log (I have changed the master server's address an dadded some notes) ......

#No current connections, and nothing recent in the log - so I connected from vlc
[2008-07-28 02:53:30] INFO slave/start_relay_stream Starting relayed source at mountpoint "/service/low.ogg"
[2008-07-28 02:53:30] INFO slave/open_relay_connection connecting to master:8000
[2008-07-28 02:53:30] EROR slave/open_relay_connection Error from relay request: /service/low.ogg (File Not Found)
[2008-07-28 02:53:30] INFO source/source_move_clients passing 1 listeners to "/streamFiles/streamvid-low.ogg"
[2008-07-28 02:53:31] INFO source/source_main listener count on /streamFiles/streamvid-low.ogg now 1
# Left vlc running for a few minutes
[2008-07-28 02:55:30] INFO slave/start_relay_stream Starting relayed source at mountpoint "/service/low.ogg"
[2008-07-28 02:55:30] INFO slave/open_relay_connection connecting to master:8000
[2008-07-28 02:55:31] EROR slave/open_relay_connection Error from relay request: /service/low.ogg (File Not Found)
[2008-07-28 02:55:31] INFO source/source_move_clients passing 0 listeners to "/streamFiles/streamvid-low.ogg"
[2008-07-28 02:57:31] INFO slave/start_relay_stream Starting relayed source at mountpoint "/service/low.ogg"
[2008-07-28 02:57:31] INFO slave/open_relay_connection connecting to master:8000
[2008-07-28 02:57:32] EROR slave/open_relay_connection Error from relay request: /service/low.ogg (File Not Found)
[2008-07-28 02:57:32] INFO source/source_move_clients passing 0 listeners to "/streamFiles/streamvid-low.ogg"
# Normally the messages above carry on the same every 2 minutes.
# At the instant that the previous messages appeared in the log, I also connected from vlc on another computer
# The new connection is hanging .......
....
# vlc just received something from the stream and has started playing - just as the next lines appeared in the log (2 minutes after I started vlc)
[2008-07-28 02:59:32] INFO slave/start_relay_stream Starting relayed source at mountpoint "/service/low.ogg"
[2008-07-28 02:59:32] INFO slave/open_relay_connection connecting to master:8000
[2008-07-28 02:59:32] EROR slave/open_relay_connection Error from relay request: /service/low.ogg (File Not Found)
[2008-07-28 02:59:32] INFO source/source_move_clients passing 1 listeners to "/streamFiles/streamvid-low.ogg"
[2008-07-28 02:59:32] INFO source/source_main listener count on /streamFiles/streamvid-low.ogg now 2

So the fallback works fine for the first listener, but after that, any new listeners must wait for up to 2 minutes before being connected. Bug? or my dodgey setup? Or is there an option to lower that 2 minute wait time?

2) I suppose that I could write some sort of script to drop those connected to the fallback after a certain period of time (I have already seen some connections of 8 hours plus - I guess it is people eagerly waiting for the next live stream next week some time and not minding listening to the same 6 minute video 24/7 until then ...), but it would certainly be much nicer to have 1 option to specifying that the fallback file just play once, and another to say that listeners on fallbacks should be kicked after a certain period of time. Should I post this comment under 'Feature Requests' as well?

Thanks for your time,


Hayden

[karlH]

The 2 minutes is probably because of the master-update -interval default setting. Restarting a failing relay too frequently is just pointless. You can certainly post up feature requests.

karl.

[heydan]

Hey, thanks for the comments Karl The timely responses to queries is really appreciated!!

So is it quite normal for the 2nd, 3rd, and all other listeners who are redirected to fallbacks to have to wait for up to 2 mins before receiving any sort of reply from the server at all? In the case of cortado, it appears as if the web browser has hung for that period - similar sort of response from vlc too - although pushing 'stop' returns vlc to a normal state.

Or is it specifically that we are using a fallback on a relayed mount? - in which case it seems that fallbacks on relayed mounts are not a good idea as most people would not think to wait that amount of time when it appears that their browser or player has crashed.

Not knowing the complexities of icecast, I would have thought that icecast would respond the same to the 2nd connection (as soon as they connect) as it did for the 1st listener, and not just ignore all new connections until a time period of ?x2mins has passed since the first listener connected. Of course, if we don't use the fallback when the stream is down, each new connection gets an answer without having to wait any amount of time no matter how often new connections arrive - I would have expected the same timely response to new connections (for mounts with fallbacks) too ....

I just tested again, running 4 clients as all-at-the-same-time as I manually could. One connected first and got the stream instantly. All the others just hung, with no data returned from the server at all, until the first client had been connected for 2 minutes - then they all started receiving data from the server. The listener stats page only showed the one connection for the 2 mins, and then the others suddenly appeared.

A sort of fix would be for me to kick anyone who is on the fallback mount after they have had enough time to view the 'we are not streaming just now' vid, and just hope that we don't get more than 1 person connecting at a time. Then, while the stream is down, all new connections would [hopefully] be the only connection and so will be dealt with instantly.

Does anyone else have any experience using fallbacks on relays for streams that do not run 24/7 - as a 'Hey, where not streaming just now, please come back at X time'? What are your experiences?

Cheers,


Hayden

[karlH]

I have committed a fix to trunk (post 2.3.2) which may help your situation. In relation to on-demand relays which fail. source is on http://people.xiph.org/~brendan/snapshots/icecast/ but if you need a win32 build I can get something sorted.

karl.

[heydan]

Wahoo!

That's awesome Karl - thanks so much for that! All listeners now get a response from the server as soon as they connect.

Hope I was not too much of a bother, but I really appreciate it - especially the seriously quick fix!

I will get on to suggesting the fallback timeout as a 'feature request' some time today


Hayden