copyartifacts fights with fetchart for local cover art images

[howardjones]

fetchart can find covers in the local directory of the album, by looking for *.jpg files. It does this during the early part of the import, and then copies the file to its new name after all the file copies have happened.

With copyartifacts in place, that file isn't there any more by the time fetchart comes to copy it!

Moving artifact: 00-amon_tobin-out_from_out_where.m3u Moving artifact: 00-amon_tobin-out_from_out_where.sfv Moving artifact: folder.jpg Error: No such file or directory while moving /mnt/music/Incoming/Amon Tobin/Amon Tobin - Out From Out Where [2002]/folder.jpg to /mnt/music/Cleaned/SingleArtist/Amon Tobin/Amon Tobin - Out From Out Where [2002]/cover.jpg

[sbarakat]

Thanks for the report! While investigating this I have found the fetcharts plugin produces the same error if copyartifacts gets in there first and moves the file out the way.

I kind of pre-emptively thought this was fixed, but I'm still getting the error from fetchart. The commit - while a small improvement - also resolves an issue where using 'copy' would create duplicate files.

I'll see if there is another way around this or possibly submit a patch to FetchArt.

[Munger]

Actually, it's a lot more serious than that. Let's say we have a directory ~/Music/Master which contains our original music collection. We want to import this into ~/Music/Beets with 'beet import -Ai ~/Music/Master, with Move: no, Copy: yes in our config. Everything ticks along just fine with all our album art being copied correctly. However, because beets is using separate threads to handle the copy after the import, things start to unravel if the import is interrupted.

When the import is restarted, copyartifacts sees that an album is already in the library, even though the files are still in ~/Music/Master, so it performs a move rather than a copy. Net result is that the artwork files are deleted from our master copy. Not cool! copyartifacts should always perform a copy rather than a move if music files still exist in the same directory.

[juanp2p]

I'm getting my artwork files moved instead of copied when importing albums and I'm not sure if it's related to this issue. The artworks are stored under original/albumname/artworks/*.jpg and moved to imported/albumname/*.jpg The original folder also contains cover images under the name of original/albumname/folder.jpg. After the importing process the files from original/albumname/artworks dissappear and I get (right) the artworks as folder1.jpg ,folder2.jpg... in imported/albumname/. I got fetchart installed. According to https://github.com/sbarakat/beets-copyartifacts/issues/3 already put on the config file:

import:
    copy: yes
copyartifacts:
    copy: yes

but it doesn't seem to solve it. My copyartifacts config is:

paths:
  ...
  ext:log: $albumpath/$artist - $album
  ext:cue: $albumpath/$artist - $album
  ext:jpg: $albumpath/folder
  ext:png: $albumpath/folder
copyartifacts:
  copy: yes
  extensions: .cue .log .jpg .png
  print_ignored: yes

Is there any workaround to solve this? I'm running the latest copyartifacts version. Thank you.

Solved:

changing

  ext:jpg: $albumpath/folder
  ext:png: $albumpath/folder

to something different like

  ext:jpg: $albumpath/scans
  ext:png: $albumpath/scans

[nomandera]

I am surprised there are not more posts about this which makes me worry I have debugged the issue incorrectly.

I am a recent convert from Picard and if I enable the beets-copyartifacts and the fetchart plugins I see the exact same symptoms.

A quick kludge for me was to enable:

fetchart:
    remote_priority: yes

which reduces the errors to a more manage level. However I am still faced with a few hundred of these errors e.g.

Error: No such file or directory while moving /downloads/Tron 1.5/Tron 1.5 - Tron 1.5 (Original Soundtrack) - cover.jpg to /music/Compilations/Tron 1.5/albumart.jpg

which causes beets to bomb out, making an otherwise slick beets experience unpleasant and tedious.