JSON Cover Art Archive Errors - Can We Help Fix Them?

There’s several threads on this, but none seem to say anything about helping to correct it.

https://ia800607.us.archive.org:443/17/items/mbid-517077f0-873a-32ec-b7f1-38841c1eee02/index.json

This is the Album:

When I look at the cover art, there are no issues indicated. Can we do something (from our end) to help fix these when we encounter them?

Download Only Approved Artwork is un-ticked. [ ]

I may have missed the question, what is it that needs correcting?

… JSON error, the album shows up on the left as Red.
It’s getting a 404 when retrieving something from the CAA.

Okay. Got ya. I’ve jsut fired up Picard, and use the Green TAGGER button from the webpage and got the same issue. Zero images download (but I don’t know where I’d see the JSON error)

As a test I’m going to download the cover manually, then resubmit it. See if that will then download correctly.

Update after test…

Okay, that is weird. I downloaded the front and reuploaded it as new art. And now Picard is downloading all SIX withoutout troubles. Old and newly uploaded.

I’ll now remove my extra and see if the other ones are behaving again.

Update again… now extra image removed, all is behaving fine. I can download all the artwork no problems.

Probably just a bad timing with an overloaded CAA server.

I’m guessing that this behaviour is due to CAA/IA regenerating the JSON whenever changes are made (such as adding or removing images).

@Bitmap may have more information and also know what to do when you notice something like this.

1 Like

That would make sense. Nothing was downloading to Picard until I added artwork. But there were a couple of hours between tests so I assumed server load.

I added and then cancelled an image to that page and all is smooth now.

I’m sure these instances are not due to capacity or timing. They’re fairly few and far between, but the ones I’m seeing are constants.

OCD kicks in and says… “Yes, I know it’s ‘perfect’, but -WHY- is it still red???”
Say it again. “But, it’s all there !! But. It’s. RED” :exploding_head: Why why why.

As I admit ‘defeat’ for that Album, I still mutter to myself … "I know, Let’s fix it! Oh, wait. Seems I can’t. ".
Save it anyway. Move to the next one.

What happens when you look at this example album now? Is it behaving okay after my faffing around?

Oh - and an “ALL RED” is a different error. Are you sure you haven’t got any Read Only files there?

1 Like

We have a process called the CAA-indexer which is what sends these index.json files to the Internet Archive whenever a release is updated (such as when cover art is added, edited, or removed, or if you change other metadata on the release). That explains why @IvanDobsky adding a test image and removing it triggered us sending a new index.json file.

As for why it didn’t exist before, that’s unclear. There were times a year or two ago when we saw issues with the CAA-indexer, but it should be much more reliable now. Unfortunately some older updates may have gotten lost in the queue when it was less reliable, meaning the releases targeted by those updates don’t have an index.json file (or do, but out of date).

As I mentioned, changing the release metadata in some way is usually enough to trigger a reindex, though I don’t encourage making invalid edits to do it. You can also bring any broken releases to my attention on here, IRC, or by email and I can reindex them manually by prodding the CAA-indexer.

Sorry for the trouble! At some point we’d like to detect and fix all of these releases ourselves, but it’s lost in the shuffle of all our other priorities at the moment.

7 Likes

Is changing the TYPE of an image enough to trigger the reindex? Or does one need to actually add\remove an image?

Toggling a quick type change, and then cancelling the edit is a very quick thing we can do without needing to pester.

Adding or changing the type is enough, but the edit needs to be accepted first (it won’t trigger a reindex for edits that haven’t applied). So unless it’s a legitimate edit, I’d rather be pestered. :slight_smile:

3 Likes

When I uploaded a new image, that edit went into the queue for seven days. It got no where near the “being accepted” stage. I cancelled it only a short time later, but that seemed to kick the page into working. That is why I wondered if a simple Type change would also do that. It would be a quite tweak without disrupting you.

In that case, you will be pestered in this thread. Assuming I can find this thread again when artwork goes weird.

That’s true, since new images are inserted when the edit is opened, rather than when they’re accepted. (So my comment about them being accepted wasn’t entirely accurate, it’s more about when the changes are applied.)

But I believe artwork type changes are auto-edits for everyone by default — so in order to “[toggle] a quick type change, and then [cancel] the edit,” you’d firstly have to tick the “make votable” checkbox to leave the edit open so that you can cancel it; but that wouldn’t trigger a reindex, because the changes wouldn’t be applied unless the edit is accepted.

4 Likes

Always good to know how something works. Thanks for the details.

In future I’ll post in this thread, or if I can’t find it I’ll make a thread called “BITMAP the JPEGs and PENGUINs are Broken” with links and then chant your name three times and see if you appear.:grin::+1:

2 Likes