If I put in my cd and click lookup cd, this album starts to download but seems to be caught in a never ending loop of some sort. After 30 minutes it has still not completed the download. It doesn’t matter if I do a manual search and click the green tagger button. The download starts but never completes. I have tried it with three different computers. Here is the debug:
E: 13:49:53 Plugin ‘bpm’ : Traceback (most recent call last):
File “picard\plugin.pyo”, line 299, in load_plugin
File “C:\Program Files (x86)\MusicBrainz Picard\plugins\bpm_init_.py”, line 30, in
ImportError: No module named aubio
Those images are clearly odd as they are taking a long time to just load by clicking on them. The CAA seems to suffer with load issues when images are too big or too high quality. (Or just the wind blowing in the wrong direction)
When I click on these images to view them it reminds me of the old days of dial-up with a 28.8Kbps modem as they are slowing appearing line by line on the screen. Kinda comical on a 200Mbps conenction!
Go to the CoverArt page and try viewing the original images. How long is it taking to appear?
Go to the COVER ART page and click on some originals. Note how long they take to appear on screen. (The Cover image being the worst)
Now go to COVER ART page on a random different album. Again click on a random Original. Note how long this takes to appear.
Just comparing the “original” image download speeds in the web browser is “interesting”.
Personally I am using Vivaldi Browser so it is easy for me to check physical size of am image as well as pixel dimensions. Or just download and check the specs in something like IrfanView.
I only have a 50" 1080p TV screen to display my artwork on. The uploader of that artwork is clearly aiming at a 4K screen or higher. The cover image is a huge 3030x2895 pixels / 600dpi / 2.54MB.
I get a feeling that CAA is straining with images like this. Just the fact that the web browser alone struggles - I won’t be surprised if Picard is not built for images of that size.
(As a Winamp man I know about how that app leaks slowly on the huge images that it was never designed for…)
Cover Art keeps popping up in this forum with issues… but the debate always gets lost without a solution. I think the CAA archive is struggling to deliver us the artwork. It would be handy to see some kind of load stats. Maybe even a little “CAA Health” meter in the corner of the screen somewhere so we know when it is having a bad day and we can return on a quieter day.
Hi Ivan. When I go to cover art, the scans pop right up. I only scanned them with 600 jpg with no editing. All my other album entries work just fine. The problem is only with the above album. Would you open Picard and search for “The Best of the Girl Groups, Volume 2” then try to use the green tagger icon and see if it will download for you? Thanks.
When trying out the download speed in the web browser it may be inconsistent as it may be in your cache. Swap to a different browser and load it. You’ll see what I mean by comparing the two cover images from the two above albums.
It is not really logical though. It is just another file. Shouldn’t really matter that it is high dpi. 2MB isn’t that big on a modern connection.
I slung a copy of the cover image onto my own server a short hop away. It is obviously faster, but not enough to have caused your 30mins stalls in Picard.
I’ll try that Picard test when I get a gap in the day. I guess I need to load up a selection of files first to cheat Picard into thinking it has an album?
I didn’t realise they were your scans. Are they newly uploaded? Maybe there is something odd with the newer server? The computer really shouldn’t care if it is delivering a 600dpi or a 100dpi image as it is just data.
Thanks @Freso, interesting to see the logs, not that I fully understand them. When we were writing this post it was in the middle of those big peak on the graphs.
Haha - that is mental. I just slung a random 10 track album into Picard and did a “Lookup by Browser” and hit the Green Tagger button on “The Best of the Girl Groups, Volume 2”. And it just sat there for ever “loading album information” for ages. I put a stopwatch on it, but got bored after 5 minutes and went back to other work. (I’ll update this post if I see it end at some point…)
I was hoping to see something on the status bar - but it just stayed as “loading album 95f96fa2-blah blah”. Never saw it mention artwork. Also never saw any art appear in the %TEMP% folder as I was partially expecting a full temp to have an effect here.
Have you tested this album in Picard without having Picard download the artwork?
No, but I will uncheck artwork and try again. I’m glad it’s not just me. If it continues to “sit there” without completing the download I guess I will submit it as a bug. The only other guess I have is that I submitted a successful “remove cover art” edit as someone had downloaded the front cover art erroneously from Volume 1 instead of Volume 2. I then scanned in my artwork. Maybe this has somehow caused the glitch. I appreciate your help! I will continue to chase down the problem and let you know the outcome.
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.
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)
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.
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.
@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!
I would say because the scans have not been cropped/they show a lot of white around the image they are ‘raw’
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!)
