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
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
Hi Thomas,> 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.Advice noted, thanks!>> 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 is true that we only know the connection duration for an individual listener after the connection has ended. Perhaps I should have said 'near 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?We do have shell access to our own Icecast servers, but Airtime users are free to use any Icecast service, including those that don't provide detailed stats. So our current listener graph was meant to provide a useful interface in all situations, but I can see it's not the right solution for everyone. Cheers! Daniel