Because it’s not a worldwide release. See all the “unavailability” there. That is not a worldwide release and shouldn’t be set as such. It’s not even in the US or CA.
Actually I would have expected at least that the available information about "country availability’ be seeded in the annotation … At least as an option … For now I used atisket to store the unavailable countries in the annotation… Otherwise what is this info good for if it’s not used for seeding at all ?
Definitely agree with that. Should be blank but needs the exempted countries in the annotation if the release country is blank.
A question from someone who uses Atiscket very rarely.
Does Harmony put the (p) and (c) in the right relationship, or is it just left in the written annotation like Atisket does?
It has always confused me as to why Atisket does that.
Annotations. It’s not possible to seed (internal) relationships.
Regarding Tidal:
I don’t know much about it yet but this appears to be a pre-release entry:
https://listen.tidal.com/album/365033100
Note how it says 3 tracks (3 Titel) and lengths don’t add up.
Harmony gives no warnings whatsoever unless you attempt to merge it with other provider’s listings and will happily let you add it standalone:
https://harmony.pulsewidth.org.uk/release?tidal=365033100®ion=GB&ts=1718104580
https://harmony.pulsewidth.org.uk/release?gtin=853566749223&url=https%3A%2F%2Fwww.beatport.com%2Frelease%2Fthe-bounce%2F4585106&category=all
Providers have returned incompatible track lists: 2 tracks (Beatport), 3 tracks (Deezer), 1 track (Tidal)
And @outsidecontext did it again, I am sure many of you will appreciate it: With today’s release Harmony finally has a Spotify provider!
We have even solved a long-standing Spotify issue which a-tisket has when a barcode search sometimes does not return the release while the Spotify website does.
The issue is unrelated to the zero-padding of the barcode which is sometimes necessary, instead the API has a region parameter…
For lookups by Spotify ID leaving away the region parameter returns the release with a list of available regions, but for the search API it apparently defaults to the US silently and only returns the release if it is available in the US.
An example which perfectly illustrates this:
So that is one more reason for you to fill Harmony’s region input with the region you are interested in. (Having said that I should finally make that input remember its last value, just like the provider checkboxes do…)
Additional changes include Bandcamp license URLs now being extracted and aditional or improved warning messages, see the full commit changelog.
As a first step Harmony now also displays alternative values for the copyright property. It still seeds only the main value since merging of copyrights or the feature to select alternative values still have to be implemented.
Thanks for reporting, I have created a ticket with permalinks, so even if we don’t implement it in time before the release date we can still use the examples for testing:
There will be an option to include the available and/or unavailable regions once there are options for the annotation at all. In fact I already had a request for an option to remove the copyright from the annotation.
Currently the whole website is static and rendered on the server, but as soon as it is dynamic this should be one of the first/Implest things to add.
P.S. I can’t promise an ETA for any of these features as I will busy with other things for the next months, but I hope that I will always be able to review contributions.
All iTunes requests are currently failing on the server. Still works when running Harmony locally. I wonder whether something got blocked or some rate limit applies.
Update: Seems to work again
iTunes is sometimes returning 403 Forbidden responses for a while, but their body is empty. No idea about the purpose of these, if it would be a rate limit, the API should return 429 reponses?
We are not logging every outgoing request, but the traffic to iTunes should be pretty low at the moment, only one request per release lookup since we are not even querying every region like a-tisket does.
I’m guessing Harmony doesn’t use d.ontun.es for ISRCs because it’s spotify only, but would it be possible to switch from keepstin’s MagicISRC to reubot’s MagicISRC?
The latter lets you add an edit note, I use it to keep the source of where the codes are from, example https://musicbrainz.org/edit/112787164
There is a pull request to bring edit notes to the original MagicISRC for which I am waiting:
There are a few critical issues which are blocking the merge and haven’t been addressed by @reubot, so I will also not switch to their forked version.
For now you have to manually copy the description which is offered by Harmony, sorry.
it seems the same is happening for a-tisket right now too (tho a-tisket might be running on the same server as Harmony, I don’t know)
Unfortunately I didn’t notice there were changes requested - I’ll have a look on the weekend.
It seems for Bandcamp Harmony is lacking the check if a barcode is used for another edition like the userscript does:
- Bandcamp Importer: display UPC instead of adding to barcode field · murdos/musicbrainz-userscripts@6e1f053 · GitHub (via)
- Bandcamp: set barcode if digital only · murdos/musicbrainz-userscripts@9852692 · GitHub (via)
https://harmony.pulsewidth.org.uk/release?url=https%3A%2F%2Fconsvmer.bandcamp.com%2Falbum%2Fseelenfrieden&category=all
https://harmony.pulsewidth.org.uk/release?bandcamp=consvmer%2Fseelenfrieden&ts=1718342804
According to the listing at Apple Music it should be 3617389461901
This release is doing weird things, durations are totally off, I didn’t investigate much but Harmony doesn’t work well for this one (not yet imported).
Weird, Apple Music has a completely different track order, some tracks are even shuffled from medium 1 to medium 2. If I unselect the iTunes provider, the result looks plausible (besides the 1900 release date from Tidal ).
What is concerning me more are the processing times, each provider takes about 1000 ms while these durations should go down to about 10-20 ms for cached results… This generally seems to happen for all permalinks right now, but most are “only” taking 300-400 ms to process, I will investigate.
Edit: Restarting the app did not help unfortunately. Using my local server brings the processing times down to about 20 ms once the API results are cached. The main difference is that my local server’s snapshot directory only contains 25M of data (400k sqlite DB) while the pulsewidth server uses 150M already (3M sqlite DB), but the performance can’t scale that badly!?
Since the userscript does not check the barcodes of physical packages at all, I guess we can do better and only unset the digital release’s GTIN if it matches one of the physical releases:
It you put the Apple Music URL as the provider URL it works as expected. I think it’s likely because newer releases can’t be found using the iTunes API by barcode lookup, only by the store ID. See how it’s stating that another release was skipped that was also found by API. That release has a completely different barcode. Same issue with a-tisket. Always have the Apple Music ID as a provider or it sometimes doesn’t work correctly.
Not sure if that’s an issue with Harmony or rather on the sources, but the release date is weird on https://harmony.pulsewidth.org.uk/release?spotify=694ymzzhqQOr1deQgDzyTy>in=194491983772&deezer=&itunes=&tidal=®ion=GB&ts=1718885190
ISRCs are dated from 2019 and copyright infos say 2020. But the selected release date is set to 2015-11-01
It’s the sources. Not uncommon unfortunately. Digital releases on the major services usually use the date of first release in the release group, not the date for that release. I typically will cross check dates on mora.jp or 7digital as they typically use true release dates.
So, I just double checked the 7digital API and the true release date is 2020-02-10.
https://api.7digital.com/1.2/release/tracks?releaseid=13474031&oauth_consumer_key=7digitalclips&country=gb&usageTypes=download