Icecast Streaming Media Server

heydan · Joined: 25 Jul 2008 Posts: 8 Location: Bangkok, Thailand

Hope you are not finding my questions too annoying yet Smile

We are finally getting places setting up our icecast streams how we want them. Now we are working on our fallback and intro a/v files which we assumed had format problems. This is because the connection hangs when the fallback moves to the live stream or when the intro stops and the live stream should start.

This is only for a/v streams though - audio only is fine.

I have read that the format of the fallback/intro file must be identical to the format of the live stream, and so we have been working on making this so.

We use flumotion to produce the stream, so we have used flumotion to create our test intro files, and have also used gstreamer commands to transcode ogg a/v files produced by video editing software.
We are now at the stage where ogginfo reports that the stream and any of our test intro/fallback files are the same format, but we still the same prob.

I just ran 2 tests (using vlc and wget in turn) to capture the live stream and then using the resulting file as the intro, but still the stream hangs at the end of the intro.

If using an intro file, if we connect with vlc or cortado, we get:
1) the intro with no probs
2) Then the player hangs with no further data received. So we kill the player after a few minutes.
3) Checking icecast admin shows the listener still connected. Currently I have 4 identical listeners listed for my VLC player at my IP address from my last 4 tests - they show over 4000 seconds connected (I was actually only connected 30 seconds each time and then killed vlc after 2mins of no data)
4) Nothing more than the listener connecting is shown in the error log, and nothing appears in the access log as the listener never disconnects.

We now have icecast-2.3.2-20080729 from ~brendan/snapshots/icecast but the problem existed when we had 2.3.2.

The problem occurs on a relay server that relays (on demand) an audio and an audio/visual feed from the master server, both generated from the same feed via flumotion.

This problem only occurs for the a/v stream though - the audio stream has no problem at all.

Has anyone else had similar experiences or have any idea of what we could try next? Or any idea of where the problem may still possibly lay (before we finally decide that it must be icecast that is causing the prob)?

In terms of format - Anything that ogginfo might report, and anything that vlc reports about an incoming stream is identical for our intro and our live stream.

Cheers once again Smile

Hayden

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

Your point 2 will be wrong. if the application does not receive data then icecast will drop them for lagging too far behind, this isn not happening. I suspect you actually mean that the the player does not decode anything further.

This is a known issue that a number of the players have regarding a new set of headers in the stream. This should be reported to the player developers because you cannot rely on the stream being exactly the same when the client is moved. This has been in the spec for years so I don't know why it's still an issue.

karl.

heydan · Joined: 25 Jul 2008 Posts: 8 Location: Bangkok, Thailand

Hi again Karl Smile

I hope that your not the only one that has to spend all their time dealing with our silly requests Wink

Thanks heaps for your time once again.

Whoops: should have mentioned....

- I have been using vlc (and cortado) to test with - vlc being pretty good with changes in streams, and cortado being a little troublesome here and there. Also, when I suspect a prob, I use wget.
- I used wget to save the stream, and when the intro should have moved to the live stream wget stopped receiving data - I left it for about 10 mins but the resulting file got no bigger.

The logs follow for what happened to these connections finally.

In all cases, I had a short intro, which, once completed, caused the player to hang with no further data received, so I killed the player after 2-10 mins. You will see that I used vlc, Cortado and wget (to confirm that no further data is received), and in all cases the client had been exited for more than 2 hours before the listeners were dropped. Notice the amount of data sent over the connections which is very slightly more than the size of the intro file used for each test. As test intro files, I have used: 1) a file captured from the live stream with vlc, 2) a file captured from the live stream with wget, and 3) a file we created ourselves - in all cases ogginfo and vlc (scanning the messages) both report that the intro had all the same characteristics as the live stream.

Again, this is only affecting video streams; audio streams are working perfectly (except cortado drops the sound when a fallback loops but I will look at that today...).

And the logs:

and ...

I can't find any record of the supposed 7th listener that existed at 06:20:52 before it looks like a new connection came in at 08:02:28

Thanks once again,

Hayden

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

There's little to go on here, the logging only shows INFO level but the access log shows the wget finishing at the same time as /service/low.ogg

karl.

heydan · Joined: 25 Jul 2008 Posts: 8 Location: Bangkok, Thailand

Hi again Karl - I hope you get to sleep sometimes!

I'm learning a little more each time Smile

We are really happy with our audio-only stream now - the fallback and intro work perfectly and our only prob is that cortado stops playing the audio on the fallback when it loops - silly cortado - but we are looking into that.

The point with the wget mentioned earlier was that the log says that it only sent a tiny amount of data (a few bytes more than size of the intro file which is 30 secs in length) over a period of more than 2.5 hours, yet I ran the connection for only about 10 mins (only recieving data for the first 30secs while the intro file ran) - I would have expect to receive more that the size of the 30sec intro file while conencted for 10mins (or 2.5 hours).

Here is some log with DEBUG set . I :
1) started icecast afresh with the stream already running on the master server
2) connected to the relay (cutting the log from just before I connected)
3) Received the intro
4) When the intro finished, I received no further data (and still am not) - I cut the log soon after this point when I saw that no more data was being sent to me.

As an explanation:
- We are running 3 streams: /service/high.ogg, /service/low.ogg and /service/audio.log
- With this test, we are looking at the /service/low.ogg stream
- The intro file for /service/low.ogg is /streamFiles/streamvid-test2.ogg
- /streamFiles/streamvid-low.ogg is the fallback for the low stream.

I hope that it is OK to include this much log on the forum ....