Yes, should be possible, but it needs a bit more work to implement that as it is the first step of the larger feature “update existing releases” which I already teased in my latest updates post.
I mean it is not wrong that music from the MB artist can be streamed/downloaded there. But I agree that I would not add these links myself when they have little value.
Harmony ignores external links which are attached to multiple different artists (or labels), so the alternative to not adding these links is to add them to multiple matching entities on MB (if you have the time and patience to do that).
This is indeed almost possible, internally you could even specify a list of preferred providers for almost every property of the release.
There are some sensible defaults to pick e.g. the most precise track lengths, but all other properties are picked from the first looked up provider which has them.
So if you are using e.g. a Spotify URL, Spotify is the primary provider and most properties come from Spotify.
Unfortunately the full power of the preferences it is not yet exposed in a user-friendly way, so you have to use the trick of starting with the “right” URL for now.
But when you initiate lookups by barcode, the primary provider is the first one which is specified in Harmony’s URL.
So you could directly manipulate the URL in that case, or alternatively change the order of the provider checkboxes on the HTML page using your browser’s developer tools
Not really long-term solutions, but they should work until someone finds the time to implement proper UI for this feature.
And finally I got to the post about the latest updates in v2024.10.18, which includes many small improvements:
The issues around unavailable Spotify tracks causing a mess have been fixed
I’ve tried three different approaches until I’ve found the most elegant solution which avoids additional API requests to get the correct data and still allows us to get (correct) ISRCs
That wouldn’t be much better, in addition to the wrong track numbers a-tisket also has some wrong titles, track lengths and ISRCs
Except for the ISRCs, these small differences can be spotted by closely comparing a-tisket and Spotify side by side.
Not at all, I appreciate your detailed reports, the examples are really helpful for testing potential solutions
Indeed, I had thought about that when I implemented the feature a few months ago, but forgot about it when I did the final polishing.
I agree that this behavior is too helpful to force users to disable the MB provider by triggering an incompatibility error as Harmony does for track counts which don’t match.
Instead I opted for making it clearer that the found MB release is not exactly the same thing by…
showing alternative values for medium formats/titles (also displayed now when there is only one medium)
clarifying that the existing MB release was only matched by barcode
Basically the user has the same responsibility to check for mismatches between different providers as they already had for differing tracklists. (These cases where GTIN and track count match, but the tracklists are different nevertheless.)
Indeed, Harmony is not checking the available tracklist precision for each release, it is a provider attribute because it is usually consistent across all releases from a provider.
MB is kind of an exception here, where some tracks have millisecond precision whereas others only have second precision.
I’ve introduced a new quality value in between those for MB, now millisecond precision providers are preferred over MB, which is still preferred over second precision providers.
Alternative track length values are grouped after having been rounded to the nearest second. That is why milliseconds were not shown in some cases, after rounding they were added to the existing groups that were already labeled by a value in seconds.
Deezer’s approach of truncating rather than rounding often leads to these track lengths having a separate group unfortunately, fixing this is not possible with the current generic implementation of alternative values, which is very simple.
Other changes:
Beatport’s endless release artist lists are now replaced by Various Artists if there are more than four artists. Improvements welcome, especially logic to detect releases with a main and many featured artists should be useful
By choosing the longest zero-padded GTIN variant for the permalink, this issue should be solved for all future permalinks.
is it planned to detect MusicBrainz duplicates without barcodes, like this one? even if it simply looks for matching URL relationships, that’d be better than nothing, methinks
I found a minor bug with the new feature of adding external artist links. When an artist has an Apple Music GB link, and you’re adding an album with a US region, the suggestion should be to add the Apple URL for the artist with the US region
an addition to this, perhaps Harmony could check the artists area and suggest that as the Apple Music URL region (provided the artist has an area and Apple Music is available there, of course)?
I assume that this is a Spotify rate limiting error. (And since Spotify doesn’t return a release with a barcode, no other providers could be queried.)
However the original error was obscured by a secondary JSON parsing error here, which happened because the Spotify API returns plain text instead of the expected JSON error object and this was not handled correctly by the Harmony provider.
I have already addressed this issue (and a similar one with the Tidal provider) last week, the error message should now read “Failed to fetch resource at …” and specify the name of the provider.
In the future I plan to also expose more details about why the request failed, but I have yet to figure out a way to do this which works for all providers.
The latest updates will be of interest mostly for people which are using (or developing) external tools which send users to Harmony’s release lookup.
Until now you either had to explicitly specify your preferred providers and region(s) in the URL like release?url=...®ion=...&musicbrainz=&deezer=&itunes=&spotify=&tidal=&beatport= (or tweak the options in the pre-filled form by hand and press Lookup again).
As I had expected (and feared) that has lead to many of these tools hard-coding all providers and/or their preferred region into the URL, which is quite inflexible and often causes many pointless requests to providers (where the user usually knows in advance that their artist of interest is not present on certain providers).
Previously I had already shared the hint to use category=default (or even category=all which I consider to be overkill) instead of manually encoding all providers into the URL and trying to keep that up-to-date.
Now you can use the new category=preferred query parameter which uses the individual user’s preferred providers. When you tick or untick the provider checkboxes, your choice will not only be remembered by your browser (as it was already the case), but also sent to the server as a cookie and used for lookups (if your request specifies the new category parameter).
There is also a cookie for the preferred region(s) which will always be used as fallback when the URL contains no region parameter.
So in most cases you should not include a region parameter when you are constructing a lookup URL.
TL;DR: For most use cases you should now use &category=preferred rather than &category=default or &category=all.
Also I’m seeing an issue that when adding artist links, where there is no spotify link added, even tho I used spotify to seed the artist. It’s not consistent, but it does it sometimes.
I’m putting this here, but do you prefer having issues here or in the github?
The Harmony feature to handle category=preferred has already been released, if you mean that.
I don’t understand the issue, please give me a concrete example with a Harmony (perma)link. What do you mean by “used spotify to seed the artist”?
Having them on GitHub is better to avoid the risk of reports getting lost in this long thread. But everyone who can’t create issues on GitHub can post here as well.
I will usually copy them over myself (unless they are expected behavior or trivial to fix), but sometimes I forget or don’t find the time to do that.
So any help which makes it easier for me to focus my spare time on development is appreciated.
Disk quota exceeded (os error 122): open 'snaps/1f/e4eec014cc2751e3ce38a7ea97de703d1764773d9f32f2486f49cd059d667d': Disk quota exceeded (os error 122): open 'snaps/1f/e4eec014cc2751e3ce38a7ea97de703d1764773d9f32f2486f49cd059d667d': Disk quota exceeded (os error 122)
Thank you for reporting, @atj has now adjusted the quota.
We are storing a huge amount of provider response snapshots already: 1,093,695 to be precise, totalling at 11GB
