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.
6 Likes
Seems like Spotify is down again
3 Likes
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.)
3 Likes
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?
6 Likes
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?
1 Like
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.)
7 Likes
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.
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.
5 Likes
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
1 Like
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)
2 Likes
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)
See also:
This is not limited to Japan releases. Examples:
https://open.spotify.com/album/2KvaR6ovudAscP0J7p2PDwhttps://open.spotify.com/album/10nXxlMIWG8ZtypFsMX8WGhttps://open.spotify.com/album/5CJRnF6DMcoOzzEFgC9lcv
2 Likes
Getting this Spotify error now.
Suggested rate limit delay is unacceptably high, cancelling request (Retry-After 23842)
1 Like
Happening again tonight.
With TIDAL releases Harmony reports the distributor as the release label. Usually not a big deal, but when the release is on TIDAL, but not the other 3 many editors might show this is as the label and it usually isn’t. Common with hi-res releases that are only on TIDAL, HDtracks, Qobuz. I usually double check the Qobuz and use the label there. Maybe not have TIDAL report release labels would be a good update.
1 Like
Sorry, but I disagree with this. I’ve been adding the label TIDAL returns as a “distributed by” relationship to the releases I import. The only other place I know of to get this information is YouTube art tracks (which don’t exist for every release). Perhaps a warning would be better, for the newbie use case?
2 Likes
I agree a little bit both with @tigerman325 and @HibiscusKazeneko. It’s nice that we have that info, there’s no harm in adding it as a distributor relationship onto the release. But I also agree that it can be misleading for editors who mistake it as the release label or imprint. Perhaps Harmony should display it on a separate field.
Mostly I use that info to add “distributed by” relationships to the release. But I also avoid it if the label returned by Tidal is one of the major holdings (UMG, Warner, etc.) that also happens to own either the imprint or one of the rightholding/licencee labels.
1 Like
Well at least you recognize it as the distributor and not the release label. That’s the main thing I wanted to point out. The other places you can find this info is on the azure HDtracks API & Jaxsta. Maybe we could have a way to show it as the distributor and not the release label.