Can't load an album

Clock is ticking past 30mins now on this 200Mbps line!! I think the Internet Pixies are currently hand crafting the pixels.

I would say it is worth noting the removal of old artwork on the ticket. Can be surprising the things that can lead to an issue occurring. Though I know I have uploaded artwork and deleted older lower res versions before myself. So it may not be that simple.

A test without the artwork option would be interesting. (So would maybe a “small” artwork test)

There have often been threads pop-up about Picard getting caught up on long downloads… but they always seem to peter out without any real solutions being found. Usually they are based around someone tagging 1000 albums. And normally that slowdown is at the writing the tags stage. Here the issue occurs just on the download of the info from the database.

And I am glad to help and be a sanity check here. Very used to testing and seeing oddities.

After an hour and a half it is hard to tell if Picard is actually doing anything. It still says “[Loading album information]”. Status message disappeared when I passed cursor over the toolbar and the help tip replaced it briefly. Now it is blank.

Task Manager is not exactly doing anything either. No disk, memory, handles movement. CPU at 0%. Not showing any buggy allocation racing. Application hasn’t “Whited out” due to over use of the CPU. (Yeah - this test is on Windoze)

The log file is as still as before. I didn’t turn on logging before starting, but no more network errors appearing in here.

It actually looks more like it has just got bored and forgotten what it is doing. :smiley:

Update: two hours has passed… I don’t think it is doing anything and has actually silently aborted. I have to go out now and will return later. Just for larks I am leaving Picard running…

There was no difference with or without cover art checked. I have been working with this for 4 days and at all times of the day and night. I let it run yesterday for 3 hours so the problem cannot be with us. I will try to set up a ticket. Over & out for now.

On my test now four hours twenty as passed… yeah… nothing changed… silently doing nothing.

This is clearly not getting stuck on artwork. When downloading a big box set like Pink Floyd’s Discovery set with dozens of extra images it is clear that Picard is busy as you see it struggling in TaskManager and the GUI. You see the status updating as the artwork is being downloaded. In this case nothing at all is happening.

This is not load. This is not artwork. This is a bug with something “odd” in the data somewhere that is making Picard give up silently.

I assume this is the only album you are experiencing this madness on. This needs to go over to someone who can see debugging data.

I agree with “something odd” and yes, it is the only album I am aware of. For example, If you search and use the green tagger banner for The Best of the Girl Groups, Volume 1, everything snaps into place as do the other albums I tried. I am going to PM one of the auto eds’ now. I’ll keep you posted when he gets back to me. (Way Different time zone)

Handy we can compare volume 1 and volume 2.

I can’t see anything weird about vol2 at all. All boringly simple looking track names, nothing weird stands out. Just looked at the edit history and then laughed when I realised I had also voted some of this through (you have a trustable name as I also have been a Llama since the 1990s…)

Clearly the larger art isn’t having an effect as all the images apart from the cover in that volume 1 are your upgraded ones.

The edit histories both have the same apostrophe and name arguments. And those insane mad merges that some people like to do where they see a track name and assume all thirty are identical…

I do notice when looking at Volume 1 that it still has the original smaller image as the Front. If you get a dev interested in looking at this I would suggest having a 600dpi scan to hand ready to repeat the “upload a 600dpi replacement, delete original” theory. I think you may be on to something there.

And please do post any finding back here. I’ll be interested in what this actually was.

Wilco, I’m finishing my PM as we speak! err, click.

I think the problem in this case is that the cover art type “Raw/unedited” is not supported by Picard at all (there’s a ticket for it, though).

Trying to load https://musicbrainz.org/release/95f96fa2-bbcc-4e3f-9f47-9322a8f81906 in a Picard 2 development build on Linux logs the following error:

D: 17:31:10,904 coverart.queue_put:206: Queuing cover art image CaaCoverArtImage(url='http://coverartarchive.org/release/95f96fa2-bbcc-4e3f-9f47-9322a8f81906/20260915655.jpg', types=['front', 'raw/unedited'], is_front=True)
Traceback (most recent call last):
  File "./picard/webservice/__init__.py", line 426, in _process_reply
    self._handle_reply(reply, request)
  File "./picard/webservice/__init__.py", line 415, in _handle_reply
    handler(reply.readAll(), reply, error)
  File "./picard/coverart/providers/caa.py", line 376, in _caa_json_downloaded
    self.next_in_queue()
  File "./picard/coverart/providers/__init__.py", line 151, in next_in_queue
    self.coverart.next_in_queue()
  File "./picard/coverart/__init__.py", line 187, in next_in_queue
    'type': coverartimage.types_as_string(),
  File "./picard/coverart/image.py", line 354, in types_as_string
    types = [translate_caa_type(type) for type in types]
  File "./picard/coverart/image.py", line 354, in <listcomp>
    types = [translate_caa_type(type) for type in types]
  File "./picard/coverart/utils.py", line 42, in translate_caa_type
    return gettext_attr(CAA_TYPES_TR[name], "cover_art_type")
KeyError: 'raw/unedited'

The code starting at 'type': coverartimage.types_as_string(), to the bottom of the stack is already there in Picard 1.4.

Picard 2 just crashes in this case, in Picard 1.4 something’s catching that exception, but doesn’t properly update the album loading state, meaning the album will sit there “loading album information” indefinitely.

6 Likes

@mineo Thank you for solving a puzzle. That also makes a lot of sense as that Raw/Unedited type was added not long ago. It is a little odd that the error handling just goes silent instead of flagging the “duff” data. (I am an old 1990s C programmer and was taught to “assume everything will go wrong, including stuff you never thought of”)

Do you know if there is any chance to patch Picard 1.4? Or is all work now in Picard 2?

Handy this has been spotted now, but also makes me wonder how many other people use the artwork if this hasn’t been reported before. The good bit is it is now crashing Picard 2 so that will hopefully persuade someone to look closer at this.

Yes, @Mineo you have probably solved the puzzle. I took the terms “raw/unedited” to mean that it hadn’t been photo-shopped, cut, spliced etc. So, the next question is: do I delete my front cover art since I can’t find a way to uncheck raw/unedited?

Yes, @IvanDobsky I am a firm believer in Murphy’s law.

To start with, I thought raw/unedited meant not photo shopped/unedited/not cropped or put together. This is why I checked the r/u box. Seems I was wrong. [See Murphy’s law] It is for art that is not prime time ready. I have since gone back and changed the few I had checked.

The initial album still just sits in limbo when I try to download it. Maybe it’s because the initial edit to add the art has not completed it’s 7 day waiting period. I’ll try again after the edit has been applied and will keep you posted. Thanks all!:hugs:

1 Like

I would say because the scans have not been cropped/they show a lot of white around the image they are ‘raw’ :slight_smile:
However if it’s causing issues you are of course free to set whatever type makes it work! (thanks so much for the scans - 600dpi is great as well!)

I will reduce my white edge. I “thought” (I’ve got to stop doing that) it might be helpful for the “purists” to see the complete art and know no edges were missing as I have seen some art that was over-cropped a little.

xiè xiè!

1 Like

It is. The best would be if you’d upload both; see e.g.,


… as well as multiple discussions in the #coverartarchive and #cover-art tags. :slight_smile:

2 Likes

I agree with Freso - it doesn’t hurt to have both! Epecially now that we can differentiate them with the ‘raw’ type.

Okay sports fans. My 7 day edit waiting period was over during the night and the edit(s) were applied. “The Best of the Girl Groups, Volume 2” now successfully downloads!! It still leaves questions. Was it a bug? Was it due to my checking the raw/unedited box with Picard not wanting to load the r/u art as the front? Could it [Picard] have been waiting for the edit(s) to be applied? The answer is beyond my limited powers of cogitation.

Many thanks to all who replied and offered suggestions. You’re a great group!:nerd_face:

1 Like

I’d blame leaves on the line. And pixies. In my experience it is nearly always pixies interfering. They are the ones who shove leaves down the back of the server air intakes.

1 Like

Possibly. You can eliminate this waiting period by unchecking the Download only approved images setting under the Cover Art Archive options.

Yes, it’s basically a bug. Picard maintains a list of cover art types in order to be able to translate them. In this case the raw type is rather new and Picard did not know about it. That alone is not the bug, but Picard until now does not properly handle that case where a new cover art type is added it does not yet know about.

A fix was proposed by @Mineo and is currently being discussed.

1 Like

Hello @rdswift, I had unchecked the download only approved images box as part of my limited troubleshooting. At the time, it still failed to download. I think @outsidecontext explained what might have happened.:smiley: I’m glad @Mineo proposed a fix. :bowing_man: Again, thanks to all!! (except the darn pixies)

1 Like