Icecast dev - Oct 2013 - Android App for Icecast Administration

Hi Thomas,
> In addition to that you can extract additional mount point related
> information (also in XML format!) from other virtual files in /admin/ as
> mentioned in the documentation.
I had a look at
http://www.icecast.org/docs/icecast-2.3.3/icecast2_stats.html - is it
possible to get the aggregate time of listener connections from the
admin interface, or only by parsing the connection log?

This aggregate 'tuning' time is required for music royalty calculations
in some countries. Another useful thing to know is the geolocation of
each listener, as not all countries are members of the IFPI reciprocal
scheme for webcasters.

Cheers!

Daniel

On 07/10/13 12:41, Daniel James wrote:
> Hi Thomas,
>
>> In addition to that you can extract additional mount point related
>> information (also in XML format!) from other virtual files in /admin/
as
>> mentioned in the documentation.
> I had a look at
> http://www.icecast.org/docs/icecast-2.3.3/icecast2_stats.html - is it
> possible to get the aggregate time of listener connections from the
> admin interface, or only by parsing the connection log?
As this is historical data I don't see any reason why you'd try to get
this through the web interface. Chances are, that there you'd miss out
on some seconds or even miss whole connections if they fall in between
polling intervals.
Also the playlist logging might be interesting in that context as it
will contain metadata, which some agencies seem to require.

> This aggregate 'tuning' time is required for music royalty
calculations
> in some countries. Another useful thing to know is the geolocation of
> each listener, as not all countries are members of the IFPI reciprocal
> scheme for webcasters.
But that's surely something that's done on some time interval basis?
monthly, quarterly or yearly?
So why would you want to parse this out of the web interface?

Cheers

Thomas

Hi Thomas,
> As this is historical data I don't see any reason why you'd try to
get
> this through the web interface.
The use case is when there is an Icecast service, but there might not be
shell access to that server. So we have a stats interface in Airtime
that only needs the admin password to create a listener count graph
against time.
> Chances are, that there you'd miss out
> on some seconds or even miss whole connections if they fall in between
> polling intervals.
Yes, that's a risk with the current system.
> Also the playlist logging might be interesting in that context as it
> will contain metadata, which some agencies seem to require.
Right, but we have detailed custom logging of playout in Airtime 2.5.x
so that side is taken care of. (In Canada, some stations have to play a
certain percentage of Canadian content, so that has to be logged).

On the listener side, we need the same level of detail. Because
royalties should be calculated on the geolocation of listeners, agencies
might collect money for listeners outside of their territory.
>> > This aggregate 'tuning' time is required for music royalty
calculations
>> > in some countries.
> But that's surely something that's done on some time interval
basis?
> monthly, quarterly or yearly?
Yes, usually you need to report at intervals, but in the meantime you
want to be able to predict those costs.

Ideally, you want to know the trends in listenership in real time - for
example, when I play a particular kind of music, do I get more stream
disconnections in a certain territory? In theory, we could return that
kind of metadata to the database of the playout system and use it to
tweak the playout.

It may be that we need to use something like
https://github.com/jonty-comp/iceking on the Icecast side and find
another way of getting this data to the users.

Cheers!

Daniel