Harmony: Music Metadata Aggregator and MusicBrainz Importer

kellnerd · July 6, 2025, 12:00pm

There is even a check to hide this message when no provider found ISRCs, but the Beatport provider didn’t properly handle missing ISRCs. Fixed.

Good idea, should be fixed now, but I couldn’t test it.

yomo12 · July 7, 2025, 2:18am

Seems like Spotify is down again

LullabiesAndAshes · July 7, 2025, 3:09am

The /release endpoint isn’t excluded by robots.txt, so bots could be attempting to scrape the endpoint repeatedly. (Setting up something like Anubis or go-away could help with misbehaving bots that ignore robots.txt once that is set up; many smaller services like self-hosted Git instances have been hammered by misbehaving AI bots.)

kellnerd · July 7, 2025, 8:22am

I really have no idea what is wrong with Spotify’s API, but the HTTP 429 errors suddenly kicked in again at around 2025-07-07T01:05:00Z:

Spotify rate limit error (HTTP 429): Retry-After 30827

With the retry-after value being in seconds, this would mean that Harmony has to wait more than 8 hours(!) until the next API request.
Since this is an unreasonable delay (and I’ve luckily implemented an upper limit), I’m simply letting these requests fail.
Unfortunately this doesn’t seem to be a unit mistake or something similar, because the errors continued for the next 7 hours with the value slightly decreasing. Apparently the API will start working again in about 80 minutes

What is confusing is that the API went straight from answering every request to straight out blocking Harmony for many hours, apparently without a chance to avoid that.
(The Spotify API documentation only talks about a 30 second window and the Retry-After header without ever mentioning a concrete rate limit for this window, so that doesn’t help either.)

P.S. We are not alone with this issue but Spotify support doesn’t seem to care?

elomatreb · July 7, 2025, 3:03pm

I encountered the same problem with my application that interfaces with the Spotify API. In my case I resolved it by avoiding use of the detailed /albums endpoint as much as possible, maybe they consider that one particularly expensive for their rate limit calculation?

kellnerd · July 7, 2025, 5:03pm

These metrics from the Spotify developer board at least explain what has changed over the weekend:

There has been an increase of release lookups from roughly 1k to 4k (in black). I wonder whether someone has started to mass-import releases from Spotify recently?
The number of track lookups (usually one request per release, in blue) tries to follow the black curve but hits a ceiling at about 3k (probably because they are more expensive).
Each barcode lookup/search (in red) triggers a consecutive release lookup by ID to get complete data. So the red curve is generally below the black curve, except when the barcode is not found. Which means there have been many lookups by Spotify URL/ID recently, whereas most lookups were by barcode in the past?
The number of releases where additional tracks have to be loaded (green curve) is neglectable.

It still doesn’t explain why Spotify doesn’t use the HTTP headers to warn about a too high quota before completely blocking the app for a very long time…
Harmony’s now trying to handle the Retry-After header for all requests (and not just for HTTP 429), but I haven’t yet seen a single successful Spotify request setting it so far. We will probably find out in a few hours if there is a Retry-After warning before HTTP 429 occurs again. (If there isn’t, I have no clue what might help as I haven’t seen any X-RateLimit headers from Spotify.)

Isabelxxx · July 8, 2025, 6:43pm

I think this is an additional case of distrokid which should be remapped to self release

In this case it shows distrokid as label, but it uses 292. I have noticed other cases where only 292 was reported though, and I assume they are also from distrokid. No 292 label exists.

BuoyantBeetle · July 11, 2025, 9:20am

I’m not sure how exactly the language guessing works, but I just found a quite weird mistake it made: หัวโบราณ – Harmony is 94% confident the language is Japanese, despite all the titles being written in the Thai script (which it correctly identified). While of course transliterations are a thing, it seems odd that it’d detect it being in one language, and be so confident, when it’s in a script not used for that language.

yindesu · July 11, 2025, 3:03pm

I’ll also take this opportunity to share another bad language guess: Crazy Crazy Crazy – Harmony is 98% confident the language is Polish, despite… everything

yindesu · July 15, 2025, 3:38pm

Can we please blacklist and/or add workarounds for the detection of (not) release labels from the “Big 3”?

Take Universal Music Japan:

e.g., 巡ループ – Harmony

“A Polydor Records / Perfume Records release”, as seen on both Apple Music and Spotify, should have been turned into the two release labels “Polydor Records” and “Perfume Records”. Whether that support is added or not, there’s never a case where “Universal Music LLC” should be seeded to the release editor as the release label from the field(s) that Harmony is currently using from these music platforms.

More examples:

女狐 – Harmony → UNIVERSAL SIGMA
花言葉は調べないで – Harmony → Virgin Music
～ 45th Anniversary ～ YOSHIE SELECTION ALL TIME BEST (UM EDITION) – Harmony → USM JAPAN
青い太陽 – Harmony → Polydor Records
Pain Give Form – Harmony → EMI Records (this is missing from the Spotify API, but present on the Spotify page)

chaban · July 15, 2025, 6:28pm

Something annoying with Spotify is that some releases, especially singles, will not have the featuring artist set at release level but only track(s).

I think in such cases where all track artists are the same it should be applied to the release artist too. (Apple Music however seems to put them in the title as feat. instead)