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

Does it now works for you like on my screen capture?

Oh indeed, this release group which has a release with front cover does not show it.

It must be because of the pending edits (moderation pending) orange background mark span.mp I’ll fix that.


I found that this front cover art is still pending.

Because I know that if a release has a removed front cover or a voted down front cover, those are still in the cover art archive.

This is why I check that the front cover art is approved before showing it.
But maybe it’s silly.

I want to find a release with voted down and removed front cover to make sure I can remove this check so that pending front cover art edits can be shown.


I could check a removed front cover art:

The image is still in the CAA but the release-group API returns a Not Found 404 Error :white_check_mark:


I could check a voted down front cover art:

The image is still in the CAA but the release-group API returns a Not Found 404 Error :white_check_mark:


I can remove my useless check to include pending edits.

2 Likes

Ah maybe I wasn’t clear, it was always working like in your screen capture. And now it works for pending edits too!! That’s what I thought was broken!

In my opinion you can remove the check for pending edits… if it’s wrong/a removed cover hopefully someone will be encouraged to upload the correct one for the RG.

The updated script still has: var bigpics = true;
Which I always change to false :slight_smile:

2 Likes

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.

4 Likes

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

2 Likes

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

4 Likes

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:

2 Likes

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?

5 Likes

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
Image from a browser without scripts

2 Likes

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:

and

and

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.

3 Likes

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.

2 Likes

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

2 Likes

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)

6 Likes

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.

2 Likes

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

2 Likes