[Icecast-dev] Android App for Icecast Administration

Thomas Rücker thomas.ruecker at tieto.com
Mon Oct 7 04:11:55 PDT 2013


On 7 October 2013 13:55, Daniel James <daniel.james at sourcefabric.org> wrote:
> 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.

For graphing this is the _only_ way to get it right anyway. I hope
you're not scraping HTML.

The Icecast web interface is for current data. We do not keep any
historic data in memory, that would just unnecessarily increase
complexity and memory footprint.

There are many ways to get to the log files, shell access is one of
them. If the hosting company is not providing any of those, then I'd
question if they are remotely suitable for a proper radio station.


>> 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.

That said you can get this data, somehow out of Icecast through
polling XML files in /stats/. it will just be horribly inefficient.
Look at the previously mentioned documentation. I clearly recommend
against it.


>>> > 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.

Which is completely irrelevant to the point of how you generate those
statistics. It will always be historical data and not real time.


> 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.

So if you don't have any way to access the server files, how are you
going to run that? Or is that a completely unrelated point you're
making?

Cheers

Thomas


More information about the Icecast-dev mailing list