All the dates are 2015 or earlier, but it detects a Chinese distributor I’ve never seen associated with that band and appears to have been founded in 2019 as the label. Any idea if it’s more plausible that it’s a 2015 release with a glitch in the label detection, or a post-2019 release that was backdated?
Dates, labels, etc are supplied by the APIs of each service. Sadly, some labels retroactively change these. This is why you see Warner Records on releases before 2019, etc. On Deezer, I have seen occasionally (but becoming more rare) a different label than what is shown on other sites. Usually a parent company or some strange distributor as you report here. The release label according to Apple Music (using Toad King script) is ДЖЕМ. So, not sure if these 2 are the exact same releases or not.
Client Challenge, shows the same date as Deezer, but same label as Apple.
@kellnerd, Harmony is absolutely brilliant. I really appreciate the work you’ve done on it, and in turn it’s helping me contribute to MusicBrainz.
There’s one part of the process that doubles my submission time, which is returning to the newly-created MusicBrainz release and adding artwork.
Am I missing the Harmony feature that automatically associates the highest-quality image with the new release, or is that an opportunity for a contributor?
Is it just me or has it become impossible to add external links to existing recordings via Harmony? I get the error message “Too many requests queued, please wait and try again” every time. I don’t buy that there are actually too many requests queued for any particular release; is there some kind of global MusicBrainz API limit that Harmony users are exceeding?
Yes, it is a global rate-limit for all additional requests to MB (resolving external IDs for release lookups, finding existing artist/label/recording links on the release actions page). It currently triggers when there are already 20 pending requests.
There were tons of these errors in the logs (multiple times per minute), but they completely disappeared as soon as I restarted the web app with some additional request logging enabled
Since lookup requests are coming in at approximately the same rate as the errors previously, I assume that the error occurred for almost every request which sent those additional MB API requests.
So I don’t think there were actually too many requests to MB but some kind of bug which only showed up after the app had been running for almost four weeks.
I have an idea what it could have been, but I don’t have the time to investigate this now. In any case, it will probably take a few weeks to reproduce this again or prove that it has been fixed if I am on the right track
Was an “hard refresh” button already suggested?
I am cleaning some monstercat tracks that were imported without UPC, but I cannot refresh harmony to tell it to retry finding the release, preventing me to add release link and accessing release actions until the cache expire (and thus not having SAMBL detect the release as well)
Your release simply has too many different artists
There are 44 unique artists on this compilation and the MB API only returns up to 25 artists (with their existing links) for “browse” requests.
I thought it was not possible to get the missing artists, but I just realized that there is an offset parameter to page through the results
Anyway, until I get to implement this, you can still add missing links to about ten artists as the page suggests 29 artists to link, out of which only 19 can be unaware of already existing links (44 unique artists minus 25 artists covered by the current browse request).
The rate limit warnings returned by the API itself are expected, they will go away (as opposed to Harmony’s own warnings from the buggy queue size limit). Apparently the HTTP headers on which my MB client relies contain global limits rather than per user limits. It was agreed in a recent dev meeting that they should be changed to be per user, so I have been waiting for that and haven’t changed my implementation (which is working good enough ).
There was no official request so far, but there is an undocumented hack to circumvent the cache: You can append &ts=0 to the URL and the current implementation will fetch the data again because it fails to find a snapshot of the data from the 24 hours before Unix epoch. (I might change that behavior in the future, so it would be good to have a ticket for an explicit refresh checkbox.)
It is planned, but requires more work to get there:
On release labels, if a Musicbrainz search is also checked, it only shows the label that Musicbrainz has on the release. Obviously, this could be wrong. I like the way Harmony shows all the differences between the different sites, including MB on tracks, artist, etc. Is there a way that could be done as well on release labels? Currently, I have to use a-tisket to see what label Spotify, etc. shows (it shows the different labels from different sites) or uncheck Musicbrainz and leave the Musicbrainz URL out of the URL box to see what the label the APIs are showing. I’d like to just be able to plug in the MB URL in the URL box and have Harmony show the MB label, in addition to what the APIs show from Spotify, etc. Many editors, especially on digital releases from the 2010s used the phonographic copyright as the label instead of the actual imprint. It would just be easier to see if there is a conflict on release labels or not.