Cover Art Not Appearing in Picard

Tags: #<Tag:0x00007fe3169f87a0> #<Tag:0x00007fe3169f8638>

I’m having issues with getting some Cover Art to appear in Music Brainz Picard. Here’s the release:

The Cover Art is for the front (as it’s digital media) and appears on the release and is approved. When I load up the song in Music Brainz Picard, all of the relevant information is gathered except for the Cover Art. I don’t see any errors with it in debug mode, however the Cover Art refuses to load.

Does anyone have any ideas on why this is happening?

I can’t test right now with this release. Just to.make sure everything else is setup correctly on your side: Cover art for other releases loads just fine?

It is working for me.
Is picard up to date? the current version is 1.4.2

@outsidecontext - Cover Art for other releases load perfectly fine.
@dns_server - Is it working for this particular release? If you tag this release, does the cover art show?

I am using MusicBrainz Picard Version 1.4.2 on Linux Mint.

I wanted to see if someone else can see it and if the issue is isolated to my installation.

Yes if I load Picard and paste the url for the release in the search box the release is looked up and the cover art is downloaded.

I can reproduce the cover art not loading, if I have set “Download only cover art images matching selected types” with the only type “Front”. Looks like the type of the image is out of sync on CAA, in the response to it says type “Track”.

EDIT: On CAA it is also not set to “approved”, that means if you have “Download only approved images” set this image will also not load. I tried to edit the cover art type by removing “Front” and adding it again, but this seems not to trigger a sync.

That would explain it. I originally set the artwork to ‘track’ (as I’m new to updating data). I fixed it but it looks like the sync hasn’t happened.

What do we need to do in order to get CAA to a) set it to approved and b) have it set as ‘front’ (or is this something that has to happen automatically)?

a) should happen automatically once the corresponding edit is applied (in this case
b) should have happened automatically at the time was applied.

@Bitmap, do you have any insight as to what might have happened/be happening here? is a ticket similar to this and previously playing with the image types has always fixed it.

Thanks for all of the help guys!! :smiley:

I’m not quite sure what happened here other than the CAA-indexer possibly being down at the time and the update getting lost in the queue (though that shouldn’t really be possible…). I triggered a reindex of this particular release and the index.json looks correct now.


Hey @Bitmap!

I just attempted to update some songs and it all works seamless now! I came here to update the post and saw your message. Thanks for all of your help!! :grinning:

1 Like