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.
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” 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.
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.
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.
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.
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.