Update scanning an existing beets database

Help
1

Yesterday I set beets up to import my complete library without doing any matching against musicbrainz, acoustid etc, thinking I’d first get the inventory populated and then incrementally turn things on and run analysis as I need them and also incorporate new albums by having Beets scan the same library picking up only additions / deletions and modifying its database accordingly when the need arises.

My config.yaml looked like this at time of import (assume correct spacing which Discourse removes):

directory: /mnt/alib/
library: /home/x/beetsdb/beetsdb.blb
import:
copy: no
write: no

plugins: chroma duplicates

chroma:
auto: no

duplicates:
album: yes

Import was run using:

beet import -A /alib

This morning I added a few albums and looking for the option to rescan looking for changes I noticed there’s no option to do so, only reference to incremental as follows:

If you want to import only the new stuff from a directory, use the -i option to run an incremental import. With this flag, beets will keep track of every directory it ever imports and avoid importing them again. This is useful if you have an “incoming” directory that you periodically add things to. To get this to work correctly, you’ll need to use an incremental import every time you run an import on the directory in question—including the first time, when no subdirectories will be skipped. So consider enabling the incremental configuration option.

I wish I’d known about the need to “use an incremental import every time you run an import on the directory in question — including the first time” - it took near on 24 hours to import my library without doing any matching. :grimacing:

In any event, given my import options I’m assuming beets hasn’t skipped any subdirectories in its initial import? To see whether there are any changes to what’s written to the beets database with the incremental directive on or off using the configuration and import command as shown above I renamed my database and reran the import with and without -i, but pointed to a folder with two subdirectories. Looking at the two databases I don’t see any difference in what beets has written with and without the -i directive.

Before I invest further time updating my initial database I have three questions:

  • are my assumptions sound regarding the above-mentioned configuration and import options not being affected by the -i directive being present or absent?
  • how do I then get beets to rescan the library adding only new directories and deleting any that may no longer exist?
  • how does beets handle pruned and/or grafted subdirectories (representing albums) that have been moved around or deleted within the directory structure?
2

It’s true—beets doesn’t keep track of the incremental-import state in the database. Instead, that goes in a special file on the side, called state.pickle, in the beets configuration directory (usually ~/.config/beets).

Beets actually has two different answers to these two questions:

  • For new music, that’s what incremental import mode is for. However, it can get a little confusing when you’re importing to the same directory you’re importing from. That’s why the Getting Started guide recommends keeping the “inbox” separate from the “library” to keep this straight. But it should still probably work, most of the time, for in-place imports!
  • For deleted music, that’s (half of) what the update command does.

Beets does not really have an answer for this beyond just letting you remove them and then import them again in their new location. This is because I think a good solution to tracking “moves” would be impossible! The filesystem doesn’t actually keep track of moves & renames—it just looks like one file disappeared and a new one appeared. So beets could try to do something like scan for files that have identical contents, but that would require (a) merely guessing about what moves happened in the past, and (b) computing, storing, and keeping up to date hashes of the contents, which would be extremely costly in the “common case” even when it’s never used.