mirror of
https://github.com/JakeStanger/mpd-discord-rpc.git
synced 2026-07-11 08:15:27 +01:00
[GH-ISSUE #36] Using release-group id instead of release id to fetch album arts #1353
Labels
No labels
bug
enhancement
help wanted
package
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/mpd-discord-rpc#1353
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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-4b7da3d21e9ahttps://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-250We 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.
@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
@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.
@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.
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:
MUSICBRAINZ_RELEASEIDtag, look up the release and get its release-group ID.