Icecast - Dec 2015 - Listener statistics on a fallback stream

Hello,

I've come across a small problem and I'm not sure it's a bug or a
misconfiguration in icecast, so I thought I'd ask here.

The situation: we have an automated radio station that is fed from a
dedicated virtual machine with SAM broadcaster. I set up a stream with a
fallback mount; SAM connects to the fallback. Now, whenever the DJ wants
to broadcast live all he has to do is start up his studio and connect to
the 'real' stream, thus taking over the stream without having to logon
to the server, stop encoders, etc. When he's done he disengages the
stream and listeners are automatically back on the automated stream.
This setup may be somewhat unusual in that we're running in
"fallback"
mode most of the time.

The problem I have is that the listener statistics are now on the
fallback stream, not the 'real' one, so now are listener graphs are flat
at zero :( Of course I could pull the statistics from the fallback
mount, but then we won't have listener stats for when we're live.

To me it sounds like a bug; surely the fallback never needs statistics,
only the real steam because this is where listeners connect to. Or maybe
I need a different configuration.

This the portion of my configuration that deals with the streams:

    <mount type="normal">
        <mount-name>/high.mp3</mount-name>
        <fallback-mount>/high-server.mp3</fallback-mount>
        <fallback-override>1</fallback-override>
    </mount>
    <mount type="normal">
        <mount-name>/high-server.mp3</mount-name>
        <public>0</public>
        <hidden>1</hidden>
    </mount>

Listeners are directed to http://radiogfm.dyndns.org:8200/high.mp3, SAM
connects to .../high-server.mp3. There are also 2 ACC+ streams with the
same structure.

So, what I want to know is: how do I get the proper listener statistics
from /high.mp3? Is it a bug? Is there a different configuration that
will work? The main requirement is that switching over to live streaming
is effortless, i.e. just turn on the encoder on the DJ machine and start
streaming.

Thanks in advance,

Jeroen

-- 
Bankai Software
Jeroen van Oosten
Telefoon: 010-4134567
E-mail: jvoosten at bankai.nl
KvK inschrijving: 24455492

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

>
> >To me it sounds like a bug; surely the fallback never needs statistics,
> only the real steam because this is where listeners connect to.

Well, the fallback mount is still a mount-point nonetheless. you could
still use it as a "regular" mount-point even if its configured as a
fallback to another.

Now, as for the statistics, should we be able to help without knowing what
system you use to gather your statistics and build those charts? or i
missed it?
anyway, i can think of two options:
1. gather statistics for both mount-points.
2. depend on the software you use, you can write some code to determinate
whether a live source is connected and pull the stats from the relevant
mount-point accordingly.


On Sun, Dec 6, 2015 at 2:13 PM, Jeroen van Oosten <jvoosten at bankai.nl>
wrote:
> Hello,
>
> I've come across a small problem and I'm not sure it's a bug or
a
> misconfiguration in icecast, so I thought I'd ask here.
>
> The situation: we have an automated radio station that is fed from a
> dedicated virtual machine with SAM broadcaster. I set up a stream with a
> fallback mount; SAM connects to the fallback. Now, whenever the DJ wants
> to broadcast live all he has to do is start up his studio and connect to
> the 'real' stream, thus taking over the stream without having to
logon
> to the server, stop encoders, etc. When he's done he disengages the
> stream and listeners are automatically back on the automated stream.
> This setup may be somewhat unusual in that we're running in
"fallback"
> mode most of the time.
>
> The problem I have is that the listener statistics are now on the
> fallback stream, not the 'real' one, so now are listener graphs are
flat
> at zero :( Of course I could pull the statistics from the fallback
> mount, but then we won't have listener stats for when we're live.
>
> To me it sounds like a bug; surely the fallback never needs statistics,
> only the real steam because this is where listeners connect to. Or maybe
> I need a different configuration.
>
> This the portion of my configuration that deals with the streams:
>
>     <mount type="normal">
>         <mount-name>/high.mp3</mount-name>
>         <fallback-mount>/high-server.mp3</fallback-mount>
>         <fallback-override>1</fallback-override>
>     </mount>
>     <mount type="normal">
>         <mount-name>/high-server.mp3</mount-name>
>         <public>0</public>
>         <hidden>1</hidden>
>     </mount>
>
> Listeners are directed to http://radiogfm.dyndns.org:8200/high.mp3, SAM
> connects to .../high-server.mp3. There are also 2 ACC+ streams with the
> same structure.
>
> So, what I want to know is: how do I get the proper listener statistics
> from /high.mp3? Is it a bug? Is there a different configuration that
> will work? The main requirement is that switching over to live streaming
> is effortless, i.e. just turn on the encoder on the DJ machine and start
> streaming.
>
> Thanks in advance,
>
> Jeroen
>
> --
> Bankai Software
> Jeroen van Oosten
> Telefoon: 010-4134567
> E-mail: jvoosten at bankai.nl
> KvK inschrijving: 24455492
>
> "If you think it's expensive to hire a professional to do the job,
wait
> until you hire an amateur." --Red Adair
>
> _______________________________________________
> Icecast mailing list
> Icecast at xiph.org
> http://lists.xiph.org/mailman/listinfo/icecast
>


-- 
Yahav Shasha,
Web Developer
+972-(0)549214421
http://www.linkedin.com/in/yahavs
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20151206/9117152d/attachment.htm

Hello,

On 06-12-15 13:58, Yahav Shasha wrote:
>
>     >To me it sounds like a bug; surely the fallback never needs
>     statistics,
>     only the real steam because this is where listeners connect to.
>
>  
> Well, the fallback mount is still a mount-point nonetheless. you could
> still use it as a "regular" mount-point even if its configured as
a
> fallback to another.
Hmm, you have a point there. But the point is, the *listeners* connect
to a certain mount point; I want to count them there. What's happening
behind the scenes to get the music to them (be it a fallback stream or
even a file played from disk) is irrelevant.
>
> Now, as for the statistics, should we be able to help without knowing
> what system you use to gather your statistics and build those charts?
> or i missed it?
No you didn't miss it; I'm using a homebrew XSLT to present the
information in a simple, parseable format:

<xsl:stylesheet xmlns:xsl = "http://www.w3.org/1999/XSL/Transform"
version = "1.0" >
<xsl:output omit-xml-declaration="no" method="text"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
indent="yes" encoding="UTF-8" />
<xsl:template match = "/icestats" >MountPoint,Connections,Stream
Name,Current Listeners,Description,Currently Playing,Stream URL
Global,Client:<xsl:value-of select="connections" /> Source:
<xsl:value-of select="source_connections" />,,<xsl:value-of
select="listeners" />,,
<xsl:for-each select="source">
<xsl:value-of select="@mount" />,,<xsl:value-of
select="name"
/>,<xsl:value-of select="listeners" />,<xsl:value-of
select="description" />,<xsl:value-of select="artist"
/> - <xsl:value-of
select="title" />,<xsl:value-of select="url" />
<xsl:text>&#10;</xsl:text>
</xsl:for-each>
</xsl:template>
</xsl:stylesheet>


The output is a text file that I can easily parse from a script; the
output is fed into MRTG. At this moment, the 'real' mount points are
missing from this output, even though clients are connected.
> anyway, i can think of two options:
> 1. gather statistics for both mount-points.
I thought of that, but the fallback mounts are hidden so I don't get the
info at all. They are hidden simply because I don't want to show them up
to the users on the statistics page.
> 2. depend on the software you use, you can write some code to
> determinate whether a live source is connected and pull the stats from
> the relevant mount-point accordingly.
Way too complicated. Why should I bother "switching" between mount
points when my listeners connect to a single mount point?

I'm beginning to think this is a 'feature' of IceCast with
unintended
consequences...

Thanks,

Jeroen

-- 
Bankai Software
Jeroen van Oosten
Telefoon: 010-4134567
E-mail: jvoosten at bankai.nl
KvK inschrijving: 24455492

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20151206/fd1f23d0/attachment.htm

Goedemorgen.

On Sun, 2015-12-06 at 13:13 +0100, Jeroen van Oosten
wrote:
> Hello,
> 
> I've come across a small problem and I'm not sure it's a bug or
a
> misconfiguration in icecast, so I thought I'd ask here.
> 
> The situation: we have an automated radio station that is fed from a
> dedicated virtual machine with SAM broadcaster. I set up a stream with a
> fallback mount; SAM connects to the fallback. Now, whenever the DJ wants
> to broadcast live all he has to do is start up his studio and connect to
> the 'real' stream, thus taking over the stream without having to
logon
> to the server, stop encoders, etc. When he's done he disengages the
> stream and listeners are automatically back on the automated stream.
> This setup may be somewhat unusual in that we're running in
"fallback"
> mode most of the time.
Ok, That is fine so far. Even a quite common setup.

> The problem I have is that the listener statistics are now on the
> fallback stream, not the 'real' one, so now are listener graphs are
flat
> at zero :( Of course I could pull the statistics from the fallback
> mount, but then we won't have listener stats for when we're live.
> 
> To me it sounds like a bug; surely the fallback never needs statistics,
> only the real steam because this is where listeners connect to. Or maybe
> I need a different configuration.
Ok, I think there is some confusion here:
There is *no* difference between a mount used as fallback and one that
isn't. The only difference is in the configuration of the mount falling
to a specific other mount. That is also why the config looks like it
does.

When a stream falls back to another one the listeners are *moved* from
one to the other mount. So they are no longer on the mount they entered.
Therefore they're not on it's statistics.
> This the portion of my configuration that deals with the streams:
> 
>     <mount type="normal">
>         <mount-name>/high.mp3</mount-name>
>         <fallback-mount>/high-server.mp3</fallback-mount>
>         <fallback-override>1</fallback-override>
>     </mount>
>     <mount type="normal">
>         <mount-name>/high-server.mp3</mount-name>
>         <public>0</public>
>         <hidden>1</hidden>
>     </mount>
> 
> Listeners are directed to http://radiogfm.dyndns.org:8200/high.mp3, SAM
> connects to .../high-server.mp3. There are also 2 ACC+ streams with the
> same structure.
Beside that you use non-free codecs this looks fine to me. (And it seems
to work fine for you beside the statistics problem).

> So, what I want to know is: how do I get the proper listener statistics
> from /high.mp3? Is it a bug?
They are proper and there is no bug here.

> Is there a different configuration that will work?
> The main requirement is that switching over to live streaming
> is effortless, i.e. just turn on the encoder on the DJ machine and start
> streaming.
Ok, I after clarifying (at least I hope so) above here is what I would
suggest:
If you only have a 1:1 mapping between entry and fallback mounts I would
just sum up the numbers.
If there is a more complicated mapping you can used more advanced
options to track how listeners move between mounts. E.g. based on the
event of entry update your statistical data.

What the best option is depends a bit on what you're using and how.
On the other mail you mentioned MRTG. I think it supports both a broad
way of adding data. Both poll and trigger based. If you like I can asks
our in-house MRTG staff for his opinion.

Have a good Sunday!

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url :
http://lists.xiph.org/pipermail/icecast/attachments/20151206/627fa934/attachment.pgp

Hello,

On 06-12-15 15:41, Philipp Schafft wrote:
>> The problem I have is that the listener statistics are now on the
>> fallback stream, not the 'real' one, so now are listener graphs
are flat
>> at zero :( Of course I could pull the statistics from the fallback
>> mount, but then we won't have listener stats for when we're
live.
>>
>> To me it sounds like a bug; surely the fallback never needs statistics,
>> only the real steam because this is where listeners connect to. Or
maybe
>> I need a different configuration.
>
> Ok, I think there is some confusion here:
> There is *no* difference between a mount used as fallback and one that
> isn't. The only difference is in the configuration of the mount falling
> to a specific other mount. That is also why the config looks like it
> does.
>
> When a stream falls back to another one the listeners are *moved* from
> one to the other mount. So they are no longer on the mount they entered.
> Therefore they're not on it's statistics.
You know, I have a problem with the term 'moved'. The way it is worded
it seems to indicate that the clients are actively moved to a different
URL (by some special codes in the stream, like a HTTP redirect or
something), which is not the case. It is only an internal 'move' between
mount points. At least that much is clear now.
> Beside that you use non-free codecs this looks fine to me. (And it seems to
work fine for you beside
the statistics problem).

This is a bit beside the point, but give a me a free (open source) codec
that works reasonably for music at 28/56 kbit and works on all
platforms, and I'll switch tomorrow :P We had an Ogg stream for years,
nobody used it. Sorry, but that's the way it is.
>> Is there a different configuration that will work?
>> The main requirement is that switching over to live streaming
>> is effortless, i.e. just turn on the encoder on the DJ machine and
start
>> streaming.
>
> Ok, I after clarifying (at least I hope so) above here is what I would
> suggest:
> If you only have a 1:1 mapping between entry and fallback mounts I would
> just sum up the numbers.
That seems to be the most logical solution for now, though from my point
of view it looks silly. I can have 10 different 'input' streams, there
is only one stream/mount point our listeners connect to and that's the
one I'm interested in; the rest are technical details. I'm sure
there's
a technical / architectural reason for this but clearly designed for a
different use case.
> What the best option is depends a bit on what you're using and how.
> On the other mail you mentioned MRTG. I think it supports both a broad
> way of adding data. Both poll and trigger based. If you like I can asks
> our in-house MRTG staff for his opinion.
Thanks, but getting the statistics into MRTG isn't a problem. I'll just
need to extend the script(s) a bit.

Regards,

Jeroen van Oosten


-- 
Bankai Software
Jeroen van Oosten
Telefoon: 010-4134567
E-mail: jvoosten at bankai.nl
KvK inschrijving: 24455492

"If you think it's expensive to hire a professional to do the job, wait
until you hire an amateur." --Red Adair

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/icecast/attachments/20151207/787de017/attachment.htm