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:
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).
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
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 @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?
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?
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.
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.
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.
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.
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)
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.
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