Icecast - Apr 2007 - Question about HTTP headers and Icecast stream status

Hi all,
  I'm working on a script to check the status of streams from multiple
streaming sources (ie. icecast, shoutcast, wms, etc.). With Icecast I
am looking at the HTTP header returned by the server when I do a GET
on the mountpoint I want the status of. It appears that a HTTP/1.0 200
indicates that the mountpoint is up while a HTTP/1.0 404 indicates
that it is down.
  Two questions:

1. Is this correct?
2. Does Icecast return a different value when the mountpoint is up,
but has no audio (data)?

  If the answer to #2 is 'no' then how hard would it be to hack the
code to do this?

  I want to be able to indicate three conditions concerning the stream
status: up with audio, up w/o audio, and down (no source).

Thanks,
Chris

Can anyone verify this for me?

Thanks

On 4/13/07, Chris Nighswonger wrote:
> Hi all,
>  I'm working on a script to check the status of streams from multiple
> streaming sources (ie. icecast, shoutcast, wms, etc.). With Icecast I
> am looking at the HTTP header returned by the server when I do a GET
> on the mountpoint I want the status of. It appears that a HTTP/1.0 200
> indicates that the mountpoint is up while a HTTP/1.0 404 indicates
> that it is down.
>  Two questions:
>
> 1. Is this correct?
> 2. Does Icecast return a different value when the mountpoint is up,
> but has no audio (data)?
>
>  If the answer to #2 is 'no' then how hard would it be to hack the
> code to do this?
>
>  I want to be able to indicate three conditions concerning the stream
> status: up with audio, up w/o audio, and down (no source).
>
> Thanks,
> Chris
>

As far as live streaming goes.

404 = mount point down.
200 = mount point up.

Its up to your application to analyze the audio data and decide if there
is enough "sound" for you or not. What if there is meant to be a 5
second pause?

I just use the 404/200 method in my scripts which monitor mount points,
It's never failed me yet.

Cheers

Rob

On Tue, 2007-04-17 at 19:19 -0400, Chris Nighswonger
wrote:
> Can anyone verify this for me?
> 
> Thanks
> 
> On 4/13/07, Chris Nighswonger wrote:
> > Hi all,
> >  I'm working on a script to check the status of streams from
multiple
> > streaming sources (ie. icecast, shoutcast, wms, etc.). With Icecast I
> > am looking at the HTTP header returned by the server when I do a GET
> > on the mountpoint I want the status of. It appears that a HTTP/1.0 200
> > indicates that the mountpoint is up while a HTTP/1.0 404 indicates
> > that it is down.
> >  Two questions:
> >
> > 1. Is this correct?
> > 2. Does Icecast return a different value when the mountpoint is up,
> > but has no audio (data)?
> >
> >  If the answer to #2 is 'no' then how hard would it be to hack
the
> > code to do this?
> >
> >  I want to be able to indicate three conditions concerning the stream
> > status: up with audio, up w/o audio, and down (no source).
> >
> > Thanks,
> > Chris
> >
> _______________________________________________
> Icecast mailing list
> Icecast@xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast

On 4/17/07, Rob McDonald <rob.mcdonald@nzpages.net>
wrote:
> As far as live streaming goes.
>
> 404 = mount point down.
> 200 = mount point up.
>
Thanks!
> Its up to your application to analyze the audio data and decide if there
> is enough "sound" for you or not. What if there is meant to be a
5
> second pause?
>
I understand. We used SAM Broadcaster to source audio streams to
Icecast, Shoutcast, and Windows Media servers. I have had a situation
where the SAM process hung in such a way that the encoders were still
connected to the streaming servers, but no audio was being encoded on
them. It may be that I need to learn more about how the encoders work
in order to determine the presence/absence of audio data.
> I just use the 404/200 method in my scripts which monitor mount points,
> It's never failed me yet.
>
This is what I do right now. Thanks for the response!

Chris

> Cheers
>
> Rob
>
> On Tue, 2007-04-17 at 19:19 -0400, Chris Nighswonger wrote:
> > Can anyone verify this for me?
> >
> > Thanks
> >
> > On 4/13/07, Chris Nighswonger wrote:
> > > Hi all,
> > >  I'm working on a script to check the status of streams from
multiple
> > > streaming sources (ie. icecast, shoutcast, wms, etc.). With
Icecast I
> > > am looking at the HTTP header returned by the server when I do a
GET
> > > on the mountpoint I want the status of. It appears that a
HTTP/1.0 200
> > > indicates that the mountpoint is up while a HTTP/1.0 404
indicates
> > > that it is down.
> > >  Two questions:
> > >
> > > 1. Is this correct?
> > > 2. Does Icecast return a different value when the mountpoint is
up,
> > > but has no audio (data)?
> > >
> > >  If the answer to #2 is 'no' then how hard would it be to
hack the
> > > code to do this?
> > >
> > >  I want to be able to indicate three conditions concerning the
stream
> > > status: up with audio, up w/o audio, and down (no source).
> > >
> > > Thanks,
> > > Chris
> > >
> > _______________________________________________
> > Icecast mailing list
> > Icecast@xiph.org
> > http://lists.xiph.org/mailman/listinfo/icecast
>
>

-- 
Chris Nighswonger
Network & Systems Director
Foundations Bible College & Seminary
www.foundations.edu
www.fbcradio.org
cnighswonger@foundations.edu
V:910-892-8761
C:919-820-5473
-------------
NOTICE: The information contained in this electronic mail message is
intended only for the use of the intended recipient, and may also be
protected by the Electronic Communications Privacy Act, 18 USC
Sections 2510-2521. If the reader of this message is not the intended
recipient, you are hereby notified that any dissemination,
distribution or copying of this communication is strictly prohibited.
If you have received this communication in error, please reply to the
sender, and delete the original message. Thank you.

On 18/04/07, Chris Nighswonger <cnighswonger@foundations.edu>
wrote:
> I understand. We used SAM Broadcaster to source audio streams to
> Icecast, Shoutcast, and Windows Media servers. I have had a situation
> where the SAM process hung in such a way that the encoders were still
> connected to the streaming servers, but no audio was being encoded on
> them. It may be that I need to learn more about how the encoders work
> in order to determine the presence/absence of audio data.
If you encode to Vorbis, the bitrate should drop to some very low
value if the stream goes silent. Perhaps you could check
<incoming_bitrate> in /admin/status.xml for abnormally low values?
(This data might only be available from the kh branch version of
Icecast?)

Leo