[Icecast] Listener statistics on a fallback stream

[Jeroen van Oosten]

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>