The Cover Art Archive is currently experiencing difficulties

Tags: #<Tag:0x00007f076557f558> #<Tag:0x00007f076557f288>


Is it just me, or is there an ongoing problem? Every time I have tried to load cover art recently, I have got the message “Warning: The Cover Art Archive is currently experiencing difficulties. Adding images for this release is unlikely to work at the moment.”
Also, no existing cover art is displayed. e.g. “Front cover image failed to load correctly.”

Keeping or dropping Amazon as a CAA fallback on

Sorry that nobody replied here before. If you’re still seeing these issues, can you link to some examples? As of right now our indexer seems to be working, and the IA’s S3 stats look okay too. Recent cover art additions all load for me except, interestingly, a few that are blocked by uBlock Origin ("||^ Found in: Malware domains").


I’ve experienced that too. I wasn’t sure whether to report it to the IA or not.


I emailed RiskAnalytics about it, the people behind (where that IA domain is included). We’ll see if they remove it.

Edit: They responded:

Thank you for bringing this to our attention. We will remove this false positive from our list in its next update. We typically update every 24-48 hours. If you have any questions, please let us know.


It seems to be an ongoing issue for me. Sometimes it works, but more usually not.
This is what I get as a home page:

And one from my collection:

The above are on a W10 PC using Slimjet, but I get the same problem with Safari on an iPad.


Would you be able to find out how to open Slimjet’s network tools/console and see if it shows why those images aren’t loading? Some kind of response code (404, 503, etc.) and which server/URL returned the code would help a bit in debugging this. Or, if it shows something like ERR_CONNECTION_REFUSED or ERR_CONNECTION_CLOSED (I think Slimjet is based on Google Chrome), the request may be blocked by your browser or network in some way.


As I said, it happens with Safari on the iPad too, so maybe it is a network issue?
How do I track that down?


Aha. Some progress … of sorts…
As I have a rubbish landline (BT’s best wet string) with no prospect of improvement, I have added a 4G connection with an external aerial and a load-balancing router. If I use the ADSL connection, I get images, but if I use the LTE connection, I don’t. I only kept the ADSL for FTP purposes (static IP with LTE is really expensive…).
I have put in place a work-round to enforce the ADSL connection for the MusicBrainz IP address ( and this fixes it!
But that means I am stuck with a slow connection to MB and I don’t know why it fails on 4G.

EDIT: Actually, it’s the archive IP address that needs to be routed via the ADSL - I’ve done this for -, which I hope covers it - and means that the main MB address is on the fast line.


About six months back I have seen a few sub-domains of getting onto Eset’s block lists for a few days. This would block a few of the images for me, but others still load.

Then on other random days I’d get a full set of non-loading images.

Similar random hiccups on uploading artwork too. Some days just feels like a painfully busy \ underfunded server to me. Works most of the time but suffers the odd hiccup.

Certainly been a lot better for me in the past few months.

I don’t know how controls what is on their network but I do know I have seen dubious items hosted on addresses. Stuff clearly not aimed at being hosted in an “archive”. A classic being KODI repos. Those add-ons that allow access to dubious film and movie streams. It almost looks like people hiding these items on there to avoid the ACE lawyers.

So what else is being hidden on their servers? Is this all then suffering pointless excess load? OR DDoS hits? I know when I hosted a (perfectly legal) repo it eventually got DDoS’d to death. So having KODI repos knocking around on the server could be causing odd load issues. And what else is being hidden on there?