As great as the new feature is, it didn’t take me long to find an edge case:
No links can be seeded if there’s a difference in the number of reported tracks between the vendors. This especially happens with Tidal where apparently some tracks get superseded with recordings from other releases, which results in the API returning less tracks than there actually are. This has already been a common occurrence on release lookups, which is why we often have to uncheck Tidal from searches.
I’ve seen several editors who seem to have fallen for this too. Wondering if there are other ways to avoid this than minding the order (add links first, then submit ISRCs) 
I just increased my cancelled edits by 30% because of this. 
I feel like this is a site bug, it shouldn’t treat lack of ISRC as removing? Form should be explicitly saying an ISRC is removed not treat the absence of them as a removal?
Addendum on 4:
If you can use the same recording edit page to add ISRCs that would be awesome! Magic ISRC always want me to log into MB after reopening my browser, and having one less link to open make less mess for me
The unintentional ISRC removal didn’t happen to me yet, and I’ve spent most of my free time during the weekend using the recording links’ seeder. Mind you, I’ve been mostly working on otherwise ‘complete’ releases (where all other necessary links and ISRCs were already added).
On a different note, I’ve just noticed a mistake on how Apple Music links are being seeded for videos on releases with both videos and audio-only tracks.
The last recording at the very bottom is a video. For the URL being seeded, the ID# is correct, but …/song/… should be replaced with …/music-video/…, ideally with the video checkbox ticked (if that’s possible without manual user input). Might be worth mentioning that the iTunes API already returns the correct links for videos:
{"wrapperType":"track", "kind":"music-video", "artistId":389219092, "collectionId":1640785129, "trackId":1640786023, "artistName":"Erin Morley, Yannick Nézet-Séguin & The Metropolitan Opera Orchestra", "collectionName":"Eurydice (Live)", "trackName":"Eurydice: Act II: This is what it is to love an artist", "collectionCensoredName":"Eurydice (Live)", "trackCensoredName":"Eurydice: Act II: This is what it is to love an artist (Live)", "artistViewUrl":"https://music.apple.com/gb/artist/erin-morley/389219092?uo=4", "collectionViewUrl":"https://music.apple.com/gb/music-video/eurydice-act-ii-this-is-what-it-is-to-love-an-artist-live/1640786023?uo=4", "trackViewUrl":"https://music.apple.com/gb/music-video/eurydice-act-ii-this-is-what-it-is-to-love-an-artist-live/1640786023?uo=4",
"previewUrl":"https://video-ssl.itunes.apple.com/itunes-assets/Video126/v4/9a/83/c1/9a83c174-5943-fcb1-6c47-dc2bc181ba1d/mzvf_13581171547046203665.640x480.h264lc.U.p.m4v",
"artworkUrl30":"https://is1-ssl.mzstatic.com/image/thumb/Video122/v4/b9/57/bc/b957bc7c-fd7d-f204-6b05-35be67ddcc2d/Job2b3faca6-31df-4d13-ad99-a9ede8b7cb75-135455504-PreviewImage_preview_image_45000_video_sdr-Time1660946537169.png/30x30bb.jpg",
"artworkUrl60":"https://is1-ssl.mzstatic.com/image/thumb/Video122/v4/b9/57/bc/b957bc7c-fd7d-f204-6b05-35be67ddcc2d/Job2b3faca6-31df-4d13-ad99-a9ede8b7cb75-135455504-PreviewImage_preview_image_45000_video_sdr-Time1660946537169.png/60x60bb.jpg",
"artworkUrl100":"https://is1-ssl.mzstatic.com/image/thumb/Video122/v4/b9/57/bc/b957bc7c-fd7d-f204-6b05-35be67ddcc2d/Job2b3faca6-31df-4d13-ad99-a9ede8b7cb75-135455504-PreviewImage_preview_image_45000_video_sdr-Time1660946537169.png/100x100bb.jpg", "collectionPrice":15.99, "trackPrice":1.89, "releaseDate":"2021-12-04T08:00:00Z", "collectionExplicitness":"notExplicit", "trackExplicitness":"notExplicit", "discCount":2, "discNumber":2, "trackCount":38, "trackNumber":15, "trackTimeMillis":334733, "country":"GBR", "currency":"GBP", "primaryGenreName":"Classical"}]
}
Unintentional ISRC has caught me twice now. See for example Edit #123601899 - MusicBrainz
Wouldn’t these be separate releases if the number of tracks differs?
Not necessarily. Sometimes tracks are removed after release or not allowed due to licensing deals between digital stores. I’d look at them at a case-by-case basis and compare more than just that one thing, i.e. barcodes, labels, artwork, etc. It’s easy to spot on Apple & Spotify because typically the tracks are greyed out or just removed (look at numbering on the tracks).
Wow, I didn’t expect the new release actions to seed recording URLs to become so popular to be honest. I thought I would quickly release that feature on a free evening and do the announcement later when I have more time, but when I came back our users have already done the job and left a ton of feedback 
I will try to work through your responses now, starting with those related to the new release actions. A few actionable tickets have already been created, so thank you all for your feedback!
This one is already being improved on the MB side:
Do you have a few examples? Are you visiting the release actions for old releases which were added in the past? I had thought about this and decided not to check for duplicates via the MB API yet, because I didn’t expect this to happen in practice:
The request is now tracked here:
Good catch, I’ve now fixed that in my dev version.
While I added a test case for such a release with video tracks, I noticed that video tracks don’t have the streamable attribute which audio tracks have. This causes the whole release to be marked as download only, but not as streaming release. Since I don’t have Apple Music, I don’t know whether that’s correct or whether Harmony should ignore music videos when it does the streamable check? My gut feeling is that the release should still be marked as streamable if all audio tracks are, but advice and opinions are welcome.
I agree that this is annoying when it is clear which release is the desired merge target, let’s see how we can make the merge algorithm relax a bit:
The first comment on that page describes how to work around this on the Release Actions page for now.
Ah, I think I understand what happens although I’ve never seen this happen in practice. I guess the rate-limit error causes all of the remaining calculations to never happen and the page renders the empty default state for everything which hasn’t been calculated.
Let’s see if simply putting the optional MB API calls after everything else solves this.
Only new releases so far. Pick your poison
Sorry if I was unclear, I meant examples when this happens in practice, except when you are visiting the release actions page of a release for which you have already seeded recording links.
That is, genuine examples of recordings already having external links when Harmony redirects you to the release actions page after a “fresh” import.
I am well aware that the release actions page is not perfect when you (re)visit it for older releases. Only artist and label links have actual duplicate checks (because they are always useful for “fresh” imports), ISRCs, cover art and recording links are always shown on the other hand. It would be possible to hide these as well, I just thought this would be less relevant:
P.S. That said, I still hope to have a “best accuracy” mode one day, where Harmony does its absolute best, no matter how many requests and time it takes. But until then I don’t want to sacrifice performance for features the average user is not interested in.
P.P.S. Actually the one additional MB API request is not too bad in the common scenario (redirected to release actions after import, release data is cached, all provider links are already known). Usually there is onyl one request to check duplicate artist links, having a second request for recording links doesn’t feel slower (unless we are exhausting the rate limit), so I’ve changed my mind and did the minor change.
Ive been caught out by this also!
Almost certain adding new ISRC matches wouldn’t remove old ones when previously using Harmony.
Apologies. Wondered why I had so many decline vote emails, only when I logged in did I noticed it was because of the ISRC delete
Nah it was the MB hate squad 
I noticed that on a Bandcamp release they had removed one track. I changed the Bandcamp link on the MusicBrainz release entity to ended.
I tried to import the data from other streaming services into this 10 track release with harmony, but it still keeps complaining mismatch with amount of tracks:
Providers have returned incompatible track lists: 10 tracks (MusicBrainz), 9 tracks (Bandcamp)
Where does a Jan 1st date come from in this:
It had been entered as 2003-01-01
Nothing is released on a Bank Holiday, so can that date be reset to just the year? Usually when something is Jan 1st on those Streaming Stores it means they are guessing.
It would also be nice to see a 2003 day wiped anyway as those stores did not exist then… but that is an old request…
Maybe it should be easy for Harmony to detect any year prior to 2008 and not pass this info to MusicBrainz.
Are you choosing that date as just generally when digital stores became prominent?
Correct. When I see in harmony the date before 2008 I try to remove the dates, as Deezer/Spotify where not yet a thing before 2008
Deezer was launched in 2007 - Deezer - Wikipedia
Spotify was founded in 2006, but launched in 2008 - Spotify - Wikipedia
the iTunes store was launched in 2003, and apple music replaced it in 2019 - History of iTunes - Wikipedia
Tidal was 2014 - Tidal (service) - Wikipedia
and Beatport in 2004 - Beatport - Wikipedia
I think if Harmony is going to auto remove dates, it should take these dates into consideration instead of having one specific year where it removes the date
Harmony internally already knows the start dates of each service. The functionality to filter out earlier dates just hasn’t been implemented yet.
Right now only for Bandcamp it considers this date when needing to decide which date from Bandcamp to use.