Fetching ISRCs from Spotify

Tags: #<Tag:0x00007f0ea4959598> #<Tag:0x00007f0ea4959480> #<Tag:0x00007f0ea4959390> #<Tag:0x00007f0ea4959278>

Hi, thanks for the quick update @tatsumo … still have some trouble now with a release. It’s seems to be problematic with some release. Here’s the release I’m trying to add: https://d.ontun.es/#/explorer/album/5kZ4GZYBuEtdWV59xSMv1T/b1860856-9623-472c-9880-d74f3e7de9f2 (after i’m logged it says something went wrong). Usually it’s when I forgot to log in that I have that kind of problem but not this time. Is this another API modification from spotify?

Thanks.

No this is on the MusicBrainz side. It’s rejecting the submission as the ISRCs don’t appear to be valid. When I replayed the request the MB server responds with
usl4q2026614 is not a valid ISRC

When you add ISRCs via the MB web interface, it case-corrects them. When you do it via the API, it seems to fail them if they’re the wrong case. You’ll notice I’ve manually added usl4q2026614 to the first track – I did this via the web interface, without correcting the case first.

This is kind of a bug somewhere outside the utility. If ISRCs must be uppercase (don’t see why they must be, since they’re not case sensitive) Spotify shouldn’t return them lowercase (Spotify doesn’t validate ISRCs though) and MB web interface shouldn’t correct them.

If ISRCs are indeed case-insensitive and usually but not necessarily uppercase, then the MB API shouldn’t reject ISRCs that would otherwise be correct.

I’ll force upper-case ISRCs before submission, but not could be a few hours before I get a chance.

5 Likes

perfect! i’ve also had this problem from time to time and entered the isrc’s manually.

1 Like

A related issue, which I think is called out way way back in the thread, for the old version, is ones which are dash separated etc.

This is a “won’t fix”. By design it won’t “correct” ISRCs which are malformed for anything but the most trivial corrections – if it requires a case transform to make it “valid”, it’s almost certainly an ISRC (since, IMHO a lowercase ISRC was already valid, as they aren’t case sensitive). If it requires anything else the confidence is lower (I’ve seen a handful of ISRCs on Spotify which were clearly not ISRCs), so it’s up to the editor to manually examine them and determine what to do (and do a manual entry).

I think the old version did fix this (I’m too lazy to find it in the thread, or check the old code), but this time it will remain “won’t fix”.

Another ISRC related thing: It seems some tracks on Spotify have ISRC codes with dashes in them.

https://d.ontun.es/#/explorer/album/7AQAnFXPNcQljjWAkbqLS5/4caecb4e-1037-41fb-aa56-0317a0d3bfe8

It’s my understanding that dashes are optional in ISRCs and MusicBrainz always strips them out, but the ISRC codes in that release should all match. But the site colors them red instead.

Not a huge issue IMO.

This is the category of “won’t fix” above. The MB API doesn’t consider them valid (see server response when you try to submit) so they won’t be supported beyond showing them if that’s what comes back from Spotify

I keep getting a “Something went wrong” error with the button when trying to submit ISRCs. It’s consistent across browsers, Firefox 86.0.1 and Microsoft Edge 89.0.774.57. I’ve tried revoking access for SpotifyLinkV2 on my MB account and then re-allowing it, with no success.

Need a repro – what’s the album.

It’ll usually be the MusicBrainz server is rejecting it for some reason or another

https://d.ontun.es/#/explorer/album/2Pc9C27OlgTTtjvFxulqgG and https://d.ontun.es/#/explorer/album/4V8NUW8yUln846aiOZ8ANR currently, https://d.ontun.es/#/explorer/album/0S3drJbrd9qLMqBtpUvvt3 previously (I ended up doing that one manually).

Can’t repro. The first one worked for me. I don’t want to do the second one in case it stops reproing.

Before you try submitting it, can you open dev tools (either browser, doesn’t matter). Then, with dev tools still open, try submitting it, and see what the error in the console is.

Of course, now it works perfectly fine when I’m actively trying to troubleshoot it… :expressionless:

I’ll keep an eye out and see if I spot any others, then report back here.

I’m having the same problem: “Something went wrong”
Tried it with dev tools open:

Status 401 Unauthorized
VersionHTTP/2
Übertragen860 B (320 B Größe)
Referrer Policyno-referrer-when-downgrade
access-control-allow-origin *

content-type application/xml; charset=utf-8
date Tue, 23 Mar 2021 15:20:26 GMT
etag “e01a7deb932361743d38546927c4cb3d”
server Plack::Handler::Starlet
www-authenticate Digest realm=“musicbrainz.org”, charset=UTF-8, qop=“auth,auth-int”, nonce=“KNVXS+uL6xGc7ubwPUzVrw==”, opaque=“kP5XS+uL6xGc7ubwPUzVrw==”, algorithm=“MD5”
www-authenticate Bearer realm=“musicbrainz.org”, charset=UTF-8
X-Firefox-Spdy h2
x-ratelimit-limit 1200
x-ratelimit-remaining 1192
x-ratelimit-reset 1616512828
Accept /
Accept-Encoding gzip, deflate, br
Accept-Language de,en-US;q=0.7,en;q=0.3
Authorization Bearer undefined
Connection keep-alive
Content-Length 2659
content-type application/xml; charset=“utf-8”
DNT 1
Host musicbrainz.org
Origin https://d.ontun.es
Referer https://d.ontun.es/
TE Trailers
User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:86.0) Gecko/20100101 Firefox/86.0

not sure if that’s useful

1 Like

I think it’s useful.

So from this I can see the request made it to the MusicBrainz server (the call didn’t fail) and the request was not entirely rubbish, because it got a “successful” unauthorised exception. So it looks like the submission token is incorrect.

This could either happen because the MB server is having some intermittent issue, where

  1. it fails to correctly validate a validly issued token
  2. it issues bad tokens
    Or it could be some flow issue on my side where sometimes it keeps an expired token etc.

I’ll do two things but it may take me a day or two as I’m a bit busy.

  1. Expose the rejection reason in a failed submit, somewhere easier to access.
  2. Add a way to submit an redundant edit (e.g. all the ISRCs are already attached – it currently stops you doing this). This would allow testing of the authorisation more easily, cause right now, I can’t login 10 times and test the token is correct each time, since I have to keep finding releases with unattached ISRCs.
2 Likes

I think it might be fixed now.

For debugging only: you can now force edits to submit (if they are all redundant ISRCs which it would otherwise ignore) by quickly hitting f 5 times before loading the MusicBrainz album. The MB server should still behave the same as if you were submitting new data (though it doesn’t create an edit because nothing changed). This is just for replaying requests without finding new releases to test all the time – in general you shouldn’t use it because it will make edit notes incorrect if it’s actually submitting new data.

It seems when the tab was open for too long and the tokens expired they don’t renew on their own without reloading the whole tab.

From the artist view when opening an album I see the “Logged into MusicBrainz” notice but upon submitting it says:
Something went wrong. "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n<error><text>Your credentials could not be verified. Either you supplied the wrong credentials (e.g., bad password), or your client doesn't understand how to supply the credentials required.</text><text>For usage, please see: https://musicbrainz.org/development/mmd</text></error>\n"

That was for an album that I’ve already opened earlier but didn’t submit its ISRCs, now when I try to open a new one the album modal is empty:

Uncaught (in promise) TypeError: can't access property "next", t.tracks is undefined
    i https://d.ontun.es/static/js/main.c49b65a9.chunk.js:1
    promise callback*t/this.fetchFullAlbum https://d.ontun.es/static/js/main.c49b65a9.chunk.js:1
    ri https://d.ontun.es/static/js/main.c49b65a9.chunk.js:1
    lu https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    El https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    unstable_runWithPriority https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    Wi https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    xl https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    ul https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    i https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    unstable_runWithPriority https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    Wi https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    $i https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    Zi https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    I https://d.ontun.es/static/js/2.1928506e.chunk.js:2
    $t https://d.ontun.es/static/js/2.1928506e.chunk.js:2
main.c49b65a9.chunk.js:1:16260
Network requests
POST /ws/2/recording/?client=spotifyIsrcSubmit2.0 HTTP/1.1
Host: musicbrainz.org
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://d.ontun.es/
content-type: application/xml; charset="utf-8"
Authorization: Bearer wUTp88BqgEtAi41qneTl8HQSELZbvxkv
Origin: https://d.ontun.es
Content-Length: 920
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
HTTP/2 401 Unauthorized
date: Tue, 04 May 2021 19:03:38 GMT
content-type: application/xml; charset=utf-8
x-ratelimit-limit: 1200
x-ratelimit-remaining: 1098
x-ratelimit-reset: 1620155020
server: Plack::Handler::Starlet
etag: "e01a7deb932361743d38546927c4cb3d"
www-authenticate: Digest realm="musicbrainz.org", charset=UTF-8, qop="auth,auth-int", nonce="guhIbwut6xGX2wYOlSpaaA==", opaque="dqJKbwut6xGX2wYOlSpaaA==", algorithm="MD5"
Bearer realm="musicbrainz.org", charset=UTF-8
access-control-allow-origin: *
X-Firefox-Spdy: h2

<?xml version="1.0" encoding="UTF-8"?>
<error><text>Your credentials could not be verified. Either you supplied the wrong credentials (e.g., bad password), or your client doesn't understand how to supply the credentials required.</text><text>For usage, please see: https://musicbrainz.org/development/mmd</text></error>
GET /v1/albums/1CYUFZdHhNspmAMCGKr9Wi HTTP/1.1
Host: api.spotify.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:90.0) Gecko/20100101 Firefox/90.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://d.ontun.es/
Authorization: Bearer BQCtY5P46zCZ9So3-zr1oB6mv_1ZVAYhjMD4-gMMYw-coTzDLpFOVB2VAkI5lk9v99yXlCsYUhdj9K4oO6kak2RlYjy40e_420Sha-5VEQVnr8kbay8jYGnPaD4VEXdogDgfx6yGTA2SuWQWY9LQKkEaFVNT_B5CNA
Origin: https://d.ontun.es
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
HTTP/2 401 Unauthorized
www-authenticate: Bearer realm="spotify", error="invalid_token", error_description="The access token expired"
access-control-allow-origin: *
access-control-allow-headers: Accept, App-Platform, Authorization, Content-Type, Origin, Retry-After, Spotify-App-Version, X-Cloud-Trace-Context, client-token, content-access-token
access-control-allow-methods: GET, POST, OPTIONS, PUT, DELETE, PATCH
access-control-allow-credentials: true
access-control-max-age: 604800
content-type: application/json
content-encoding: gzip
content-length: 96
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
date: Tue, 04 May 2021 19:05:32 GMT
server: envoy
via: HTTP/2 edgeproxy, 1.1 google
alt-svc: clear
X-Firefox-Spdy: h2

{
  "error": {
    "status": 401,
    "message": "The access token expired"
  }
}

Also, what’s the “OK” button in the album modal supposed to do? Seems non-functional or is that just me?

1 Like