I have been at this all morning and can’t seem to be able to make Picard simply read the *.jpg files from my directory. I have disabled all cover art sources except from Localfiles and have not messed with the regex that searches for them. It is frustrating at the least to have to open 1500 folders and drag/drop 1500 images on the cover art to load it.
If you look at the regular expression, you see how your cover pictures have to be named:
(the blue and green test string examples will be found, the not coloured filenames will be not found)
If they are in a subfolder called \cover, you have to adjust the above regular expression or move your picture called folder.jpg in the same directory as your tracks.
But they are not in any subfolder unless it doesn’t count the actual related track directory as “root” and stays in the search/added folder parent directory searching for covers (which doesn’t sound normal).
The picture above is at Q:/Music/Add Folder(s) Chosen Directory\Leftfield\Leftfield - Dusted\Disc 1
The tracks and cover.jpg are in the same folder. The filename is consistent with the regex and foobar/mp3tag can find it and embed it to the file(s) .
Ok , the log is not empty,but still i just “Looked up” a folder that has subfolders containing flac files both with embedded and w/o embedded cover art.It still shows 0 images on the right pane.
The only error upon refreshing the album is
E: 23:59:06,274 coverart.next_in_queue:183: Failed to read '': No such file or directory (2)
If all it has is a single “E:” line, then it looks like you don’t have debug output turned on (the -d flag passed to the executable when starting it, as listed on the previously linked page). With debug output on you should have a turn of “D:” lines just from starting Picard.
Thanks a lot for the details. I could reproduce this on Windows. It is a regression introduced in Picard 2.1.3 that breaks the local cover art provider on Windows. A temporary workaround is to downgrade to Picard 2.1.2.
Thanking you so very much.I am as new as can be at picard and dealing with issue tracking and all the links is going to take a while for me…
I was reading through the bug fixes of 2.1.3 and it seems that 2.1.2 is broken in more ways than just the local cover art issue (Bugs fixed in 2.1.3) .I will just wait for the issue to be fixed. Thanks
Yes, there have been a few important fixes, but it all depends whether one affects you or not. If you want you can also use a current development build from AppVeyor
This includes the bugfix for local cover art as well as a few other fixes. But the usual disclaimer applies: Using development builds unexpected things can be broken. Right now I’m rather confident we did not break things, only fixed them, though
Thanks i will try this in the coming days!
By the way is it safe to browse /artifacts and download “Current” builds or is the one you linked me somehow “safe” ?
A sub question to this matter,is there a way to permanently “Keep Original Cover Art” or do we have to select it every time?
Sorry for the so many questions,im coming from the way back machine and discogsPone mod tagging…
Hard to answer in general. The one I linked to was the latest development build at the time, and one I am rather confident does not break anything.
We try to not introduce any bugs into what is the main development branch (known as the master branch, you can see the word “master” in the page I linked to), but during development all things can break. And some of the builds there are also for specific features in development, and those can be incomplete or even really bugged at times. So if you try any of the development builds I usually would recommend using only those that indicate being for “master”. And using the dev builds is definitely at your own risk
You mean never overwrite existing cover art? Unfortunately not at the moment, but yes, it would be good to have.
Same problem here, but with various cover filenames.
The following settings caused that any graphic file with any name in the folder was added as a cover. After updating to version 2.1.3 it stopped working.
