Display cover arts in MusicBrainz pages: “mb. FUNKEY ILLUSTRATED RECORDS”

I am sorry to say @jesus2099 but with one of the latest updates you must have broken something: On pages with many release groups not all cover art is loading anymore. I am using both the big pictures and the small pictures and today I have encountered two strange behaviours of your script that I have not seen before:

  1. Every time the page is reloaded different release groups are affected by missing cover art (browser console has a mix of 503 and CORS errors).
  2. Some release groups show both the small inline pictures and the big ones on top of the page, some display only one of them, some are missing both.

I did not have a look at the code yet, but maybe you are querying the CAA twice for each picture in the newer versions and this causes (some of) the problems? For debugging I can recommend this series as a test case which has over a hundred release groups with numbers on their covers, so it is very easy to spot the missing pictures :wink:

1 Like

Hi @kellnerd, thanks for the other regression report in github.
For this one, it looks related to what I’ve seen on some smaller lists:

It’s since I tried to make a cleaner script that uses CAA API instead of brutally trying all image loadings.
Maybe this ticket will fix your issue too. I’ll check that.


Hi @kellnerd, it’s fixed! :slight_smile:
Or not completely, sorry. :sweat_smile:


At last I have taken your fix to show FUNKEY CAA in user and entity edits!
Thanks very much again @kellnerd!
I still need to do it in INLINE_STUFF as well.
I already did it for INLINE STUFF in 2020.10.16: https://github.com/jesus2099/konami-command/commit/51f2affaf51da8555b85227a605a7c82184f3dff


Hi @aerozol,
There is a new MusicBrainz server (MBS) feature to display CAA icon on RG with CAA.
I made an update to follow this MBS change in version 2021.11.11 (it’s also the release date of the version: year.month.day[.time]).
How come your script did not auto-update?
How did you install it?

1 Like

Ah thanks jesus! I had disabled script updates because I didn’t want to keep setting:
var bigpics = false;

Looks great now :partying_face:


I don’t know if it’s the same for you, people, but it seems most of the pictures are not loading.

I looked into it a little bit and saw many 429 Too Many Requests.
I think the script is being too much demanding.
I must find a way to liaise that.

Example for the second release group (which does have a cover art) in Jacques Higelin - MusicBrainz

First (probably big pics):

GET https://coverartarchive.org/release-group/a5e6e6cc-ebf4-39d2-8460-95736355f5ef/front-250 429

Then (non-issue, it’s their 404, 429, error pages that are not part of CORS setup):

Access to XMLHttpRequest at 'https://coverartarchive.org/release-group/a5e6e6cc-ebf4-39d2-8460-95736355f5ef' from origin 'https://musicbrainz.org' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

Then (error 0 is usualy my company network setup, I guess):

Error 0 () for https://musicbrainz.org/release-group/a5e6e6cc-ebf4-39d2-8460-95736355f5ef

And then:

GET https://coverartarchive.org/release-group/a5e6e6cc-ebf4-39d2-8460-95736355f5ef net::ERR_FAILED 429

I have a very small amount of loaded cover arts, nowadays.
Is it the same for you?


I’ll tick a “me too”.

It is not only your Userscript. I am also getting “Too Many Request” errors when trying to load a single full size “original” image from the normal cover art page. Sometimes need two or three clicks to get it to load. I’m assuming they are having some slowdown issues on their servers again.

Notice also that when your script is turned off, MB’s own images are failing to appear on an Artist page.

Image from a browser without scripts


Thanks for your answerr!

Oh but this is the normal behaviour.
This placeholder is just an indicator that there are cover arts in this release group, but none is actually displayed, inline, by MBS.

Maybe displaying images everywhere is becoming too demanding for CAA.

Ah - I thought they had upgraded a bit. But there is still clearly issues at the CAA server as even loading normal “original” images with MB is failing quite often.

If you look at the history of CAA they go through periods of Heavy Load. That server is shared by so much other stuff. I’ve noticed lately more and more “music backups” getting slipped onto there as it is basically “free” storage. I do wonder what kind of stuff they are now hosting, and what that is starting to cost them on load.

I saw a link the other day to some old TV shows. Now that is going to be some pretty heavy load if stuff like that is going onto those servers instead of just living in the torrent systems.

So your images script will be a minor load compares to data volumes like that.

1 Like

It looks like this for me:



If I reload the same URL I don’t get the same result twice!
It seems to be random, which and how many pictures will be fetched from CAA.


Very much this. All a bit hit and miss at the moment.

Go open your Collection. That is a good example. Instead of five rows of images, there are always only seven images total at the top. That selection changes on each reload of the page. For me these are then the only ones that appear as little thumbs.

Update: Don’t want to spam the thread, so I’ll update this one. Picard also can’t download artwork now either.


Thanks for your feedback.
I will still try to make each cover load only once in Mutualise CAA image loadings · Issue #519 · jesus2099/konami-command · GitHub


It’s been pretty bad lately. Even ListenBrainz is affected.
I’ve first noticed on edit listings with “Supercharged Cover Art Edits” enabled and thus voting on cover art edits has become painful again.


I couldn’t help it:


We had some temporary issues with the CoverArtArchive (reached a global limit of number of connections) which should now be resolved (thanks @Zas !).
Please let us know if you keep seeing the same issue (seeing a lot of “429 Too many request” responses)


It’s working great now!
Thanks @mr_monkey. :slight_smile:

1 Like

I installed this script and it duplicates the covers lol why?

I went to the same page and I don’t see them in double.
You must have installed the script twice, haven’t you?
It’s strange because it should not be possible to install it twice, even from 2 different sites, thanks to the same namespace and name.

Please have a look at your installed script list.


Yeah, sorry, I found out I had Tampermonkey and Greasemonkey both installed and they had the same list of scripts, this explains why some of my MB scripts were coming up with duplicate edit notes too lol