Over the last two weeks, we’ve addressed the song variety issue and have continued to investigate ongoing issues with metadata between the station and Azuracast with some interesting findings. For more details, read on!
Song Variety
First, let’s talk about song variety. When we transitioned away from co-locating our broadcast server, we began using Azuracast as a replacement for our previous broadcast software. While excellent, the software we used carries with it a Windows requirement which makes hosting it considerably more expensive and complex, but Azuracast enables us to use linux for the whole stack. Unfortunately, we also lost the ability to host our full library due to disk space limitations, so we came up with a system which updates the available songs on the station every week or so.
One issue we pinpointed recently was with the script that determines what songs are available for the rotation. In short, as time progressed, we found that the script would only consider songs that had played at least once in the past year rather than all station-available songs. We rewrote a large part of the script, plus we reverted back to an older library set which simplifies song selection in the script. The result is that the station now has about 2,500 more songs in the live rotation, plus updates will correctly prioritize songs so that the rotation has a level of variety listeners have come to expect from the station.
Now Playing Information
Second, there is an ongoing issue with metadata population for what’s currently playing. Our investigation has yielded some interesting results, including a potential unreported bug in Azuracast which we’ll be investigating further before submitting a formal bug report to its maintainer.
To simplify for our non-technical folks, Azuracast has a way for us to retrieve a list of songs along with unique identifiers for each song. When a song plays, we rely on that unique ID to determine what’s currently playing. There are two issues with this. First, our radio station is unique in that we have some songs with title - artist combinations that are non-unique, and it’s this combination that the ID is generated from (as a hash). Second, we found the list of songs retrieved from Azuracast is missing several songs, and thus, several IDs which we later match against the currently playing song.
Potential Azuracast Bug
The songs that are missing in this list have some similarities and often include songs with tildes, non-standard quotations, and other unusual characters. As we’re well aware, Touhou music (and plenty of other music from Asia) can often have uncommon characters in titles, artist names, album names, and so on, and the systems that handle and store this data don’t always play nicely with these characters
When an ID cannot be matched, we still try to display any metadata we can to inform listeners about what’s currently playing, albeit with reduced functionality (no song rating and no formal history logging). However, we’ve also found that Azuracast sometimes does not push an update when a new song is playing, and in these cases there is zero information about the currently playing song. We looked into this further and found that Icecast, the software listeners ultimately connect to, did have the current song but in a simple title - artist format, which as mentioned earlier, may not be enough info to systematically determine exactly what’s playing.
What’s Next
With all that said then, our next steps will be to adjust our rotation script to exclude duplicate title - artist combinations from existing at the same time, look further into the potential song list bug with Azuracast and submit a formal report if necessary, look into retrieving the list using an alternative (non-API) method, and create a helper system to watch for cases where Azuracast does not push a song update and instead use data direct from Icecast.
There’s still plenty to do, but in the meantime, I appreciate your patience as we continue to investigate a deeply technical issue, and thanks for listening!
[Knowledge #185]