Generating reports for SoundExchange, BMI, etc

Forgive me if this has already been discussed or if there’s a solution in code that I haven’t explored yet. I thought I would ask first and then maybe be pointed in the proper direction.

I’m eager to automate, as much as possible, the quarterly reports to Sound Exchange and the PROs. Currently this is a manual process because the two reports generated by Libretime are logs of playout history and listener stats, but there is not a one-to-one correspondence between timestamps in the two reports. So I have to pull the history of a two-week period, guestimate the number of listeners by looking at the graph, and then crunch the data down to unique tracks with the number of plays and the number of total listeners.

My question: Is there a point in the playout process where the application knows the file id of the current song playing AND the number of listeners currently connected to the stream? If so, I would like to add a method that records file id, increments number of plays, and adds the current number of listeners to any stored value for that file id (or creates a new record if it’s the first time the file has been played during this two-week audit period). Then I could run a query that pulls file info and numbers of play / listeners, using this new table, and be done with my report. Ideally, I’d also like to be able to turn the ‘reporting period’ on and off, maybe via configuration, so that this method would only fire if reporting_period = 1.

What do you think?

There is currently no functionality or code written for this. It has been requested before see https://github.com/LibreTime/libretime/issues/283 & https://github.com/LibreTime/libretime/issues/196 but nobody has specified out what needs to be done to implement it.

It sounds like you are on the right track here, the number of listeners is pulled from Icecast by querying the Icecast server and I’m assuming writing this info to the database. I’m also interested in helping with this as I think it would be good for the number of listeners to certain tracks to be easily tracked.

Discussing it on the above issues might be good as well once we get into the specifics of code etc.

Thanks, Robb. I’ve commented on issue 283 with my ideas.

– Pat

I just added some more thoughts based upon my analysis on there tonight. I’ll be doing some of this work paid for by the grant we received so any feedback would be welcome.