I’m having the same trouble on https://musicbrainz.org/release/5ff9f8e5-066c-4950-b3ca-2d38d35bd194/cover-art
Been about 6 days and no thumbnails.
They will be there eventually. There is some issue (I don’t think we know what exactly yet) that causes the indexer to be very slow at the moment.
I think it a bug and find it consistent, triggered by upload package total. A big package (i.e. 300 MB) also makes browser unstable at stage between pictures dragged onto window (i.e. thumbnail preview) and press ‘Upload’, freezing and/or crashing. Splitting upload into smaller packages solves that part, but does not make uploaded pictures show up back. Below a list of releases with full scans that does not show up yet, 1 month at the oldest.
Ordered by last Add Cover Art edit timestamp:
2016-11-10 21:52 UTC bccc36fc-f315-4803-98f1-b8d662eb6a80 0 pics shown
2016-11-10 22:39 UTC c322dd0b-1386-4ea4-9c1f-4cd9c6c8b9da 0 pics shown
2016-11-12 03:26 UTC be87ae0d-fdf5-430b-8563-f21bc2ac699f 0 pics shown
2016-11-14 23:31 UTC e25fd978-7575-4508-9037-1b411b1f431a 0 pics shown
2016-11-16 15:59 UTC 564f8b97-f954-453b-bef0-ae1aee2c6c5a 0 pics shown
2016-11-17 15:07 UTC 065e35eb-9dd8-4c62-87b5-7829fd10d56f 1 pic shown (Front)
2016-11-17 17:02 UTC dd64d1fb-0b52-4e42-9c33-27cc780c7dcd 1 pic shown (Front)
2016-11-25 13:33 UTC 8d7c14f2-9b09-448f-9e60-8c9e0cfb1fa2 0 pics shown
2016-11-26 10:56 UTC a57adb1c-c4c5-4923-8114-6daefc440de6 0 pics shown
2016-11-26 20:29 UTC 38e5262f-0181-4fc4-b934-651c7c2fdc5f 1 pic shown (Front)
2016-11-26 21:12 UTC 85005f34-c6ac-4f92-9347-626e51514d0f 0 pics shown
2016-11-26 22:13 UTC 676243cf-c70e-48da-97e8-b1112862812e 0 pics shown
2016-11-26 23:47 UTC c8e65d92-69a9-4d56-96e9-07b2a57a6e95 0 pics shown
2016-11-30 22:51 UTC 9158eb90-d8fc-42c3-bd66-e9c88097edb9 0 pics shown
2016-12-03 14:45 UTC 96ff57c9-dd26-49e5-b138-b2a725d987ec 1 pic shown (Front)
2016-12-04 12:36 UTC 39819b81-3bbf-4269-8ac2-88c1bbde0b52 0 pics shown
Pictures are all there, but seemingly not indexed (and resized). At ‘All sizes: 250px | 500px | original’, you get “Page not found” for ‘250px’ and ‘500px’, but reach every picture ‘original’. 4 exceptions are similar, presumably because Front pictures are the smallest (by area, not ‘weight’).
It’s only a bug if it doesn’t behave as designed. Partnering with the IA, this is how it is. As much as we might want it to be, indexing the CAA is not their #1 priority. Just like MetaBrainz, the Internet Archive is understaffed and overtasked.
That’s likely because the browser is storing the entire image in memory. Lower RAM machines will likely get hit by this more than people with more. (I’m on 16 GB RAM 64-bit machine, and I still encounter this.)
1 month sounds pretty extreme. @Bitmap or @reosarevok, can you check whether something’s up with these releases and possible “reset” them or whatever it is in CAA’s system. 
FTR, I had the same problem with a small set of small images.
But my PC is most certainly not very powerful.
My browser process was overloading one of the CPU cores and I had to wait for minutes before my Enter edit mouse click was possible in a tiny window of 1 or 2 seconds.
The system shows the first one as having no pending tasks at all. I’ve asked the IA.
Good enough. I would think indexing to be a fairly simple and straightforward automation with high output unit numbers compared to more complex routines, so it should very well be a matter of priority – but then also, every now and then users get the impression of being a flaw to design.
Yes, that feature may come by full courtesy of whatever browser is used, is however integral to the MB Add Cover Art user nuisance – the string of actions however easy enough. At the moment 3 GB RAM 64-bit here, and browser crashes even with Task Manager giving CPU load at 1 % and browser session fresh at 300 MB – but that’s Windows’ make-up face, I know.
Kind of you, thanks. That extreme is my normal. I am guessing CAA has set high resolution to low priority, in order to up output number. All in order of perspective though.
Hank from the Archive:
i’ve got a guess - there’s an odd character (xD7) in the “comment” string for the first image:
https://archive.org/download/mbid-bccc36fc-f315-4803-98f1-b8d662eb6a80/index.json
the derive is probably running a newer version of PHP, and the newer
json_encode()may be stricter than what i’m seeing on the command line
confirmed -
json_last_error_msg()tells usMalformed UTF-8 characters, possibly incorrectly encoded
@Bitmap, this sounds like a problem on our side?
4 Likes
Yes, it looks like the CAA-indexer is sending index.json files with latin-1 encoding. I’ll investigate the issue today.
5 Likes
As an aside, the comment field shouldn’t be used to store information already present elsewhere (such as the image size or the file format).
1 Like
@reosarevok, @Bitmap & @chirlu : I usually put a comment like “2810×2810” under a picture meant for front (and ‘Folder.jpg’ source), to indicate it is cut to square shape. The link in Hank’s answer refers to the release topmost in my list, but that one has no ‘(xD7)’ character (multiplication sign ‘×’).
Cut? As in cut off? You shouldn’t modify cover art – it should show the release as it is (possibly non-square).
No, not anymore.
2 Likes
[quote=“chirlu, post:12, topic:178073”]
Cut? As in cut off? You shouldn’t modify cover art – it should show the release as it is (possibly non-square).[/quote]
Yes, because it is always immediately followed by the uncut cover front; and since the uncut cover front of a CD most often is 1 of 2 booklet cover pages, a ‘Front only’ would otherwise have to be added (or, instead, a similar automated preview). I understand your objection and the notion of Front not including the folded pseudo-Back of that spread, and am happy to comply with whatever MB principle-in-practice I am still trying to pick up on. (In this particular case, one could counter-argue with the auto-link for Amazon pictures, then in both directions with Guideline completeness.) The cut (about 20 px at 600 dpi) is done to just excise visible staples and even out edges, as the paper is often not cut in right angles and seldom print aligned. The cut Front is also made from the full booklet cover spread image, identical dust pattern and all for anyone to check. Every scan other than the cut Front thus annotated have their source edges visible.
I also scan in greyscale (exceptionally even black/white for text only) pages that have no colour, fully aware that an other may think something vital is missing.
I also have a bad scanner, poor image correction ability (colour, dust, pen writing; and other practical realities subject to user/temper rule) and little time.
Trying not to sound sarcastic, I will hence go for uncut Front. No problem.
No mistake then. Thanks.
@Griomo I believe @chirlu is referring more to things like Digipaks - these don’t have a ‘square’ cover, and sometimes editors try to add them/crop them because the result looks better on their mp3 player.
Luckily we have the option to use the release-group image when tagging (which can be set to the ‘cleanest’ and most digital playback-friendly square image) so we can comfortably vote no on those additions.
I don’t think anyone has a problem with slight edits to remove staples or weird bits visible on the edges (I often do this, as you say often the cover often isn’t cut perfectly square, leaving large areas of white on the sides of the scan), especially if the full scan is still available 
Any edits that make it no longer represent the release in hand though, just for consistency/ personal preference sake… no thanks.
3 Likes
Digipak, yes of course – but then again, how much deviation to allow for a square before it becomes something else, or precision to go the other way, still is subject to user rule, as also the borders that “represent the release in hand”. Better keep to visible or visibly nearing edges (slight edits), to save time from others’ correction and own response. Any mp3 user wanting a square Folder.jpg is free to perfect it from the uncropped Front original, just as I have done.
@Anyone This release
2016-10-16 17:54 UTC http://musicbrainz.org/release/61cf3dfd-4d3b-4bd8-92ca-f284d001ccb7/cover-art
has its sole picture visible on Cover Art page but not ‘heading’ release right of page, and i think Comment dash is from me forgetting to set Type. So this should not be exactly the same fault as the above one.
It’s the job of MP3 players to either display rectangular image with white borders or to pan and scan (zoom and crop) it to square.
We should not upload cut off covers for this or that purpose, it must all be post edit by the specific needs users.
Maybe it could be a Picard feature to auto squarify front covers for the people who want it?
Auto‐square front cover (zoom and crop)
Update (2017-08-02):
4 Likes
A new version of the CAA-indexer has been deployed which should prevent some failures in thumbnail generation. I re-indexed the releases linked in this thread, but if you see any more, send them to me.
7 Likes
I got this list from the IA:
mbid-7781fbf1-8dc7-4b9c-b21e-a81b6a3b607c
mbid-21273725-fc85-4557-985a-502ad74476a4
mbid-0375999c-82be-4d1a-bc29-acb4e2167d7e
mbid-1fffce2e-3e61-431b-af11-cea4d008e877
mbid-380b96dd-d0fe-44b0-8d2b-791b4ccd6bec
mbid-77f46a62-2820-42a3-a57e-efed4abf0691
mbid-7af3b9cf-8f40-48a6-9f36-c0ca7eaff69b
mbid-83076c88-03ab-4ced-9406-65f45983fe1b
mbid-d50fe8c2-3869-42b7-b631-b3426ca1aa91
1 Like
In reosarevok’s list, 6 out of the 9 are by me. Here 2 more:
mbid-9584d047-bad3-44ec-9685-e621bf1ecf1d
mbid-aced546e-9eb3-41fe-9e30-3209b5527eaa
Edit: … and now they are OK. That was quick, thanks again.
1 Like
The one posted in between went MiA:
mbid-61cf3dfd-4d3b-4bd8-92ca-f284d001ccb7