I imported a large set of albums in beets, using the “skip” feature, whenever I could not get a good tagging result quickly, just assuming that I could re-do these lateron. Seems that I have misunderstood the feature.
Now beets skips over all albums on a new iteration, previously imported or not.
How can I force beets to import previously skipped albums?
I’ve been thinking about a method for tracking imports that is a bit more robust than the current incremental feature. The two main items I’d want include:
Record original directory name
Ability to do initial (timid) import without intervention, and return later to worry about the hard cases
The first you could do by setting a custom flag during import. I’m not super familiar with the beets codebase, but my understanding is that the DB has either albums or items, and I think to do the second you’d have to add a table for imports.
There is indeed no out-of-the-box feature like this, but the place where it’s stored is ~/.config/beets/state.pickle (by default). This is a Python pickle data file. If you open that up by unpickling it, you’ll find a taghistory list of all the directories marked as “done” in incremental mode. This includes all such directories—skipped and imported alike.
That sounds cool! There’s a similar thread here, about the idea of keeping import state persistent:
It could be a cool project that might solve all sorts of problems, including how to add non-CLI interfaces to the beets importer and how to elegantly handle interrupted imports.
Interesting discussion there. I’d say using redis or anything is overkill - a tasks table in the database seems perfectly suitable for now. And contrary to the poster ab632, I think having the task history associated with an album would could be useful.
You could probably drop in a simple tasks table to track imports and add a flag to that command easily enough, but that’s not a super extensible option. Pretend instead that the work is done to implement a tasks system, and the code is refactored so that all CLI commands get translated into tasks (similar to how you refactored the DB code for flexattrs), some of which are interactive and some of which are asynchronous. When do you run the async tasks?
A background process, with a data store and workload management system, and a command line tool for interacting with it… At some point you might find yourself extending AURA to include library management endpoints and refactoring the CLI to just be an API client.
The “return later to worry about the hard cases” use case is probably a rather common one when importing larger batches. At least that was what I was doing.
Next to “Skip”, the importer could offer an “Ignore” feature, one being persistent and one not remembering state.