[GH-ISSUE #36] Using release-group id instead of release id to fetch album arts #1353

Closed
opened 2026-05-23 02:58:01 +01:00 by JakeStanger · 3 comments
Owner

Originally created by @salihgerdan on GitHub (Mar 21, 2023).
Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/36

I was investigating why this would not show album art for some of my albums.

This API call finds the release with the ID b56f3ba4-77c8-36c4-95f6-4b7da3d21e9a
https://musicbrainz.org/ws/2/release/?query=artist:Muse%20AND%20release:Origin%20of%20Symmetry&limit=1&fmt=json
We can confirm from the following url that no cover art exists for this.
https://coverartarchive.org/release/b56f3ba4-77c8-36c4-95f6-4b7da3d21e9a/front-250

There are 26 releases within the release-group of this album. Only 5 of them lack an attached album cover art. It seems to be hit or miss.
However, release groups themselves get album arts, and we can fetch them using this url, almost the same as it is done currently.
https://coverartarchive.org/release-group/{}/front-250

We can follow the same API result to get the release-group id. It's ef03fe86-b54c-3667-8768-029833e7e1cd. We can see that the following indeed does return a valid cover art.
https://coverartarchive.org/release-group/ef03fe86-b54c-3667-8768-029833e7e1cd/front-250

I found forgoing releases and going for the release-groups a more reliable way to get the album arts (at least for the artists I listen to), however I did not test this thoroughly. Alternatively, it could become a fallback if there is no cover for the release. This would require an extra request with the client.

Originally created by @salihgerdan on GitHub (Mar 21, 2023). Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/36 I was investigating why this would not show album art for some of my albums. This API call finds the release with the ID `b56f3ba4-77c8-36c4-95f6-4b7da3d21e9a` https://musicbrainz.org/ws/2/release/?query=artist:Muse%20AND%20release:Origin%20of%20Symmetry&limit=1&fmt=json We can confirm from the following url that no cover art exists for this. https://coverartarchive.org/release/b56f3ba4-77c8-36c4-95f6-4b7da3d21e9a/front-250 There are 26 releases within the release-group of this album. Only 5 of them lack an attached album cover art. It seems to be hit or miss. However, release groups themselves get album arts, and we can fetch them using this url, almost the same as it is done currently. `https://coverartarchive.org/release-group/{}/front-250` We can follow the same API result to get the release-group id. It's `ef03fe86-b54c-3667-8768-029833e7e1cd`. We can see that the following indeed does return a valid cover art. https://coverartarchive.org/release-group/ef03fe86-b54c-3667-8768-029833e7e1cd/front-250 I found forgoing releases and going for the release-groups a more reliable way to get the album arts (at least for the artists I listen to), however I did not test this thoroughly. Alternatively, it could become a fallback if there is no cover for the release. This would require an extra request with the client.
Author
Owner

@JakeStanger commented on GitHub (Mar 21, 2023):

Good spot. From my (limited) testing it looks like release groups are more reliable too.

MPD doesn't include the release group ID in its database currently, so this would require an API call to resolve. I think that's probably okay though.

Long term, I've opened an issue on the MPD repo in the hope it can get added in: https://github.com/MusicPlayerDaemon/MPD/issues/1767

<!-- gh-comment-id:1478388512 --> @JakeStanger commented on GitHub (Mar 21, 2023): Good spot. From my (limited) testing it looks like release groups are more reliable too. MPD doesn't include the release group ID in its database currently, so this would require an API call to resolve. I think that's probably okay though. Long term, I've opened an issue on the MPD repo in the hope it can get added in: https://github.com/MusicPlayerDaemon/MPD/issues/1767
Author
Owner

@salihgerdan commented on GitHub (Mar 21, 2023):

Thank you for looking into this.
If the release ID is specified in the tags, fetching the release album art might still be a good idea. That way it wouldn't necessitate an API call. This would also give the user freedom to use the release album art if that is desired (could also backfire if they unknowingly set a release tag without a cover art using an automated tagging tool).
This could be a search specific approach. It seems that the specific release on the API results is rather random anyhow, when the different releases are named identically.

<!-- gh-comment-id:1478433058 --> @salihgerdan commented on GitHub (Mar 21, 2023): Thank you for looking into this. If the release ID is specified in the tags, fetching the release album art might still be a good idea. That way it wouldn't necessitate an API call. This would also give the user freedom to use the release album art if that is desired (could also backfire if they unknowingly set a release tag without a cover art using an automated tagging tool). This could be a search specific approach. It seems that the specific release on the API results is rather random anyhow, when the different releases are named identically.
Author
Owner

@JakeStanger commented on GitHub (Mar 21, 2023):

Helpfully archive.org has gone down within minutes of me trying to test, but I think I have support for the release group art implemented. Will test and if it seems reliable, I'll try to get a release out in the next few days.

If the release ID is specified in the tags, fetching the release album art might still be a good idea. That way it wouldn't necessitate an API call.

I think trying to automatically resolve one or the other could be quite complex. EDIT: This isn't true actually now I'm fetching the release anyway. Will look into this.

I am not worried about the API call particularly, because it will only be made once per album for the application lifetime and then the result cached, so it's a fraction of a second longer to load first time around.

The current (new) implementation is as follows:

  • If we have the ID cached, great! We can use that.
  • If the song has a MUSICBRAINZ_RELEASEID tag, look up the release and get its release-group ID.
  • If not, search for release groups matching the artist/album and get the first result's ID.
<!-- gh-comment-id:1478735303 --> @JakeStanger commented on GitHub (Mar 21, 2023): Helpfully archive.org has gone down within minutes of me trying to test, but I think I have support for the release group art implemented. Will test and if it seems reliable, I'll try to get a release out in the next few days. > If the release ID is specified in the tags, fetching the release album art might still be a good idea. That way it wouldn't necessitate an API call. ~~I think trying to automatically resolve one or the other could be quite complex~~. EDIT: This isn't true actually now I'm fetching the release anyway. Will look into this. I am not worried about the API call particularly, because it will only be made once per album for the application lifetime and then the result cached, so it's a fraction of a second longer to load first time around. The current (new) implementation is as follows: - If we have the ID cached, great! We can use that. - If the song has a `MUSICBRAINZ_RELEASEID` tag, look up the release and get its release-group ID. - If not, search for release groups matching the artist/album and get the first result's ID.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
JakeStanger/mpd-discord-rpc#1353
No description provided.