[Icecast] Icecast streaming issues

[Philipp Schafft]

Good afternoon,

Answering for Icecast 2.4.x below. Icecast 2.5.x has only little changes
in the statistics yet, however Icecast 2.5.x is developer version and
may have future changes not reflected by this mail.

On Wed, 2019-03-06 at 11:12 -1000, Adam Taufmann wrote:
> Hi,
> 
> I've read the definitions listed on your website about each of the
> statistics that is tracked with my IceCast stream, but still have a couple
> questions.
> 
> I'd like to know how many listeners we've had (from start to finish).
> 
> After reading through the definitions, it looks like the
> *Listener-Connections* statistic is the one I want. My question is, *what
> exactly counts as a listener connection?*
> 
> For instance, if I have turned off the source from which I'm streaming, but
> then someone still tries to go to that IP address, will it be counted? (I
> actually just tried this, and yes, it does still continue to count).


There are many diffrent counters, two of them are the listeners and
clients counters. They come in two flavors: current connections and
accumulative connections (this is what you want).

As client is everything considered that connects to Icecast and sends a
HTTP request. This includes requests that Icecast can not reply to
positively such as File not found errors.

Listeners are actually clients that pull a stream off a source.

All listeners are clients but not all clients are listeners. Other
examples of clients are e.g. requests to the web admin interface.

Listeners are only defined for sources and only for as long as the
source is connected.


> The reason I'm asking is that it seems like the number is a little higher
> than what I'd of suspected it to be. Not to say that it's wrong, I'm just
> trying to make sure I've got it right.

This can be correct. E.g. some browsers and some smartphones make
useless parallel requests. (We do not know why they do that, however
it's not needed and likely a misunderstanding or incorrect
implementation of the standards.)

Such user agents may therefore make multiple listener connects and
therefore are counted multiple times.

This is not a Icecast problem. It's a bug in the user agents.

You can check with your access.log. Such clients would be reported at
least two accesses at about the same time.

Notes:
      * The accesslog entry is written when the client is disconnected
        as only after disconnect all the log information are known to
        Icecast.
      * The last value in the access.log is the time on how long the
        client is connected. It might be useful to keep that in mind
        when debugging.



> What I ultimately want to know is how many times has someone actually
> gotten to connect and listen to what I'm streaming.

Yes, this is a very common problem. However it depends on how you define
"someone". Beside this user agent misbehavior there are also other
questions such as, what happens if a client reconnects because of
connection loss. Is it a new listener or is it still the same one?


If you need professional business support regarding this, feel free to
send me a mail off-list.

With best regards,

-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon: +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)     Registration number:
Bickinger Straße 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20190315/61fe5d33/attachment.sig>