Streams 'Playing Now' status not refreshing after each song

I have no idea what this entails on the backend but I noticed that ‘Playing Now’ status from http://stream.gensokyoradio.net:8000/index.html?sid=1 doesn’t always update when the next song starts. I believe this is the property that media players like foobar use to display whats playing. It would be awesome if it updated regularly when the song switched.

The only reason I probably noticed is because I’ve been using last.fm for over 10 years now to keep track of my music listening history. For streams, if the ‘Playing Now’ status isn’t being changed, then none of the other songs being played will be recorded.

Sorry if this isn’t the right place to put this, I can move it elsewhere if need be.
Thanks

Many before you have asked about this. It’s a well-known issue that the station has had which, at its core, is rather cryptic and difficult to solve completely.

SHOUTcast provides a feed which services such as TuneIn, last.fm, Foobar2000, Winamp, etc. use to display the currently playing song. Occasionally, a song will play which causes an “xml not well-formed” error, and the root cause of this is likely due to a character (or characters) in file metadata that aren’t able to be parsed by SHOUTcast’s internals.

A few years ago, this issue caused a complete server crash. These days, it merely stops the flow of song data for a few songs before picking it up again. During this time where no song data is available via SHOUTcast’s feed, Gensokyo Radio has a couple feeds (https://gensokyoradio.net/api/station/playing/ and <ARTIST/><ALBUM/><YEAR/><CIRCLE/></SONGINFO><SONGTIMES><DURATION/><PLAYED>0</PLAYED><REMAINING>0</REMAINING><SONGSTART>0</SONGSTART><SONGEND>0</SONGEND></SONGTIMES><SONGDATA><SONGID>0</SONGID><ALBUMID>0</ALBUMID><RATING>0</RATING><TIMESRATED>0</TIMESRATED></SONGDATA><MISC><CIRCLELINK/><ALBUMART/><CIRCLEART/><OFFSET>0</OFFSET><OFFSETTIME>1622541843</OFFSETTIME></MISC></GENSOKYORADIODATA>) which will continue to provide song information.

Since this is a custom solution, other services like last.fm and such won’t pick up on it, but it can and is used in custom players such as Lunatic Player and the player found on our website.

So, what can we do to fix the problem? First we need to identify the songs which cause this issue. SHOUTcast’s forums point us to a range of unicode characters which are known to be problematic, but when we run a search in our library for some of these characters, some results are known to be good songs (they have been reported as having played before).

An example is the album silver†. The cross symbol is one of the symbols which falls in the range of supposedly bad unicode characters, but it isn’t causing any issues as far as we can tell. We must investigate further.

Behind the scenes, we keep a log of songs that have been reported by SHOUTcast’s feed. We also have a playlist system where we’re able to control timings of songs and other events (like the hourly station inserts). With this, it’s possible to check the log against the playlist and find the gaps in data. However, we can’t just look at one playlist and compare the log for that since we know the feed will stop for a few songs before catching again. So we’ll collect data for a while while purposely avoiding adding any new material to the station.

Aha, now we have some results. However, it’s still not quite clear what the cause is. We can see in the screenshot that sometimes it’s one song in an album that’s a problem; sometimes it’s an entire album. Additionally, there’s no obvious difference between albums which have East Asian characters in visible metadata and those which do not.

At the end of our analysis, we find that about 14% of all songs in the current playlist have never been logged via SHOUTcast. That’s kind of a lot.

So yes, it’s a problem, we’re aware of it, and fixing it isn’t easy. One thing we could do is simply remove the problem songs (that is, songs which have never been logged by SHOUTcast) at least as a temporary fix, and then try to see if we can fix it somehow, even if that means re-rendering or re-ripping nearly 600 tracks. It would be a significant effort to fix completely.

It’d probably be worth it and appreciated though. Right now it’s just seen as a problem which shouldn’t exist. Once it’s fixed, new listeners would never know~

Sorry for the slow response. Thanks for the super detailed reply! Sorry for asking something that’s been asked and answered previously.

I see, so basically there is a set of characters that don’t play nice with shoutcast but that list and what you are experiencing isn’t necessarily 1 to 1. Which makes fixing the issue difficult.

I don’t know to what extent you’ve looked into this issue and I certainly don’t want to feel like an annoyance suggesting stuff you’ve already investigated. That being said I have some experience with software development and if you’d like some help I can certainly lend some time to getting this resolved.

If you want, I listen to music all day at work, I can try and pay attention to exactly what songs are causing issues and when it comes back. I realize you already indicated having most of that information though. But I can use the Playing API to see if anything stands out to me.

You mentioned “Visual metadata” which I’m assuming are just artist, album, and title. Or is “visible metadata” just the metadata included in whats sent to shoutcast? Could there me metadata with breaking characters in other metadata fields other than the obvious artist, album, and title.

Is there a way we could set up a shoutcast stream in some sort of vm or test environment and feed it some of the broken songs you have recorded in those spreadsheets? I feel a reproducible environment like that would be the easiest way to figure this out. I’ve never done anything with Shoutcast before but I can do some research this week when I have some time.