After a massive 'move' from an old library, artifacts were left, how to add them?

[daks]

Hello,

I started using beets again and moved all my old library from its old directory (/path/to/old) to a new one (/path/to/new).
But the old directory had a lot of the artifacts which were not imported, and were left there.

An example

tree Slint/ Ska-P/ shame/
Slint/
└── Slint
    ├── Front.jpg
    ├── Slint [EP].cue
    └── Slint [EP].log
Ska-P/
└── Planeta Eskoria
    └── cover.png
shame/
└── Songs of Praise
    └── cover.jpg

6 directories, 5 files

I am not completely sure what was my configured list of plugins when I did this operation because I modified it after.
It could have been

plugins:  fetchart embedart inline scrub missing duplicates copyartifacts lastgenre ftintitle info

with copyartifacts after fetchart.

I'm not sure if plugins order has any importance but it could, so since then I modified it to put copyartifacts at first and all subsequent imports seems to work as intended.

Now I have a bunch of artifacts that I wish to import in my collection but couldn't find how. Is it possible? And how I can do it?

[daks]

No answer? :(

[wisp3rwind]

I don't think there's a built-in feature of beets to achieve this. The order of plugins shouldn't matter for copyartifacts. However, copyartifacts has been unmaintained for a long time, and if I remember correctly has always had a bunch of problems. Maybe there's something useful at the links given in the copyartifacts README: https://github.com/sbarakat/beets-copyartifacts

[daks]

okay... I didn't know it was unmaintained, as it is still in the official documentation.
Do you know if an alternative exists?

edit: in reality I'm already using copyartifacts3 the python3 fork, but it also seems not actively developed since no commit since 3 years

[wisp3rwind]

Well, these are third-party plugins listed for convenience in our docs, we can't guarantee that they are compatible with current beets and won't eat your library. Maybe this should be noted somewhat prominently in the docs (even though they do state that these are community plugins rather than "official").

I don't know whether there's any alternative that works well. https://github.com/Holzhaus/beets-extrafiles also hasn't seen an update in a long time.

[gtronset]

@daks I've just recently updated https://github.com/gtronset/beets-filetote to work with beets v2+. Despite some personal interruptions last year, Filetote has been in active development and experiencing ongoing improvements.

[RollingStar]

Not saying this is the best option, but maybe you could move them back, enable whatever plugin(s) actually work, and then move them all at once?

[gtronset]

copyartifacts doesn't properly infer the move type from the CLI commands as mentioned in the part of code controlling file operations. That said, you may be able to have things move on beet move if you set your import config to move, e.g.:

import:
  move: yes

It looks like in the current code state that copyartifacts relies on that config setting to detect when it should move files. In all other cases, it just defaults to copying (reimport in the code is only ever False).