Multiple cover art problem

I cant figure it out, how do I only save 1 version of the cover (front) image? I have selected “Save only one front image as a separate file” which I want to be called folder.jpg. After I save I end up with a folder.jpg and a folder(1).jpg. I only want the folder.jpg.

Am I dense?

https://pastebin.com/vRUsnAHh

The thing is they are all being saved to the same folder. Even the different cover art images. Now if picard finds a file with the same name but different image, it adds a number to the filename and saves it.

On a side note the default image file name is set to “folder”. Thus why you are getting folder.jpg and folder(1).jpg

I think what @helta is asking about is how he can set up Picard such that it only downloads one cover file (the first one listed in the Cover Art section as type Front) rather than downloading all image files of type Front.

This has been addressed in the latest version of Picard (v1.4), and the setting is found under Options -> Cover Art -> Cover Art Archive. The latest version can be downloaded at https://picard.musicbrainz.org/.

I hope this helps.

Looking at the log and requests, he is already on 1.4.1 and on default settings for CAA image types since it is only downloading the “front” images.

I think he is a bit confused since he is saving 2 different front covers in the same folder, which is causing the naming issue.

Is your problem that Picard is downloading a new cover art image and naming it folder(1).jpg when you already have an image called folder.jpg in the directory? If so, I haven’t tried this, but what happens if you check the Local Files box under Options -> Cover Art and then move the Local Files selection up to the top of the list? Note that you will also have to make sure that the file name under Cover Art and Cover Art -> Local Files are set appropriately to give you / use your preferred file name of “folder.jpg”. I may very well be wrong, but intuitively it seems that would use the existing file first (if it exists), and then only download a new file if there was no existing local file.

1 Like

Sorry for the late reply, I was away for the weekend. I’m not at the computer where I tag my files, but I’ll try and clear a couple of things up.

  1. I’m using Picard version 1.4.1
  2. I do not have a folder.jpg in the directory already.
  3. My issue seems to be specific to this release (although it may happen with others, I just haven’t noticed it).
  4. I have Picard set to download only the “Front” (cover) art, and to name it “folder.jpg”, and have specifically checked “Save only one front image as a separate file”.

So whats happening is when I cluster and lookup the release, Picard tells me that their are 2 cover arts available. That’s great, but I don’t want Picard to download/save 2 images. I only want 1 cover art of the best quality. Right now, its downloading the better quality one and naming it “folder.jpg”, then a lesser quality (smaller size) one and naming it “folder(1).jpg”, obviously because the name is already taken.

That is odd because that’s the way I have it set up here and it works perfectly, only downloading one cover image (the first one in the list) even if there are others available. In fact, it only shows one image as being available. This is using Picard 1.4.1 on Windows 7.

What release are you having the problem with? I can try it here and see if I can replicate your problem. The release that I’m using for testing is Oh What a Feeling because it has 5 images marked as Front… My option settings and import results are:

Settings

Result After Importing Tags

1 Like

The release I was having issues with is:

Would you try it out?

I hate to tell you this, but it worked fine – only showing and downloading one cover art file.

Strange, when I get home I will try again.

If it still doesn’t work for you, we can compare all settings (including plug-ins) and see if there’s anything else that might be causing it. The other thing that I should mention is that I’m not clustering and looking up, but am doing a lookup through the search bar and then invoking the tagger from my browser. I can’t see where that would make a difference, but who knows?

You could go into the release and remove the low res + images that don’t match the release.
In some cases we might store individual covers (eg a scan and a digital print file), but that doesn’t apply to any of those covers. Most releases should probably only have one cover image.

The problem is that with digibox packaging often there will be an image of the front cover (as type Front) along with an image of the whole digibox folded open showing the front and back covers along with the spine (and marked as types Front, Back and Spine). Are you suggesting that these images be removed, or not marked as being Front?

In the example that I was using for testing, there are 4 CDs in a box set. Each CD is in a jewel box case and each has a different front cover. Then the cover on the box set is different again. Simply removing images doesn’t seem to be an appropriate solution in that case.

Let’s face it, with the diversity in packaging there really isn’t a good “one size fits all” rule to follow. Or if there is, I have yet to find it. :grinning:

So here are my settings:

Result:

You can see in the picture the “2 images”

This is going to sound strange, but try unchecking the box marked “Download only approved images”. I started with your settings and got the same results as you. One by one I changed the settings from yours to mine, and got multiple images (sometimes as many as 4), until I unchecked that box. Then I only got the one image.

I had that box unchecked for other reasons, but it seems that it impacts more than just the use of “approved images” (which I took to mean only those images on edits that have been applied).

What about that check box that says “overwrite file if it exists already”?

1 Like

No. Like I said sometimes it’s appropriate.
But in this case it’s worth pointing out that we’re working with bad data.

It appears that also works in setting only one cover art image, based on my limited testing here. I’m not sure how that will impact the case where there is existing cover art in the directory and the Local File option is checked and has been moved to the top of the list. Sometimes (but rarely), I will do that to force the use of a particular image file with a release.

Unfortunately, the documentation for Picard hasn’t caught up to the 1.4 release version yet, so I’m not sure how the various options are supposed to work. In the mean time, it looks like we’ve landed on a couple of options that will do the trick for @helta.

1 Like

Yup, thanks for all your guys help. I figured it was something more specific to that release then an overall bug

Thanks again!