with Picard and the Tango.info plugin I often get the date of recording of the old tango shellacs. Picard stores it in DATE. I am using flac files. The values are stored in the flac vorbis comments. I controlled it with VLC. But they don't show up after a "beet up".

beet up always worked when I change a tag in EasyTag but with Picard it does not work.

Can you clarify what's going on with an example? For instance, maybe you can show the output of beet info or another tool that lists the data you want to pick up, and then show a beet ls -f '...format...' command that you wish produced the same value.

Eventually, I copied the file to the Musik-folder, because this is the location for my dj files. I did this with beet move -c -d.

I guess that beet now thinks the file has to be in this folder. My understanding was that it only copied the file and recorded this in the database as a convert or export command. But I fear that beet now treats the copied file as the canonical file of its library.

This behaviour seems consistent to me if I had moved a file into another folder. But after a copy command I would think that beet signals to me that there is a duplicate in the library and ask which one it should treat as the canonical file defaulting to the file in the configured library folder.

So what is the best way to skip all files in ~/Musik and update the database from the files in ~/beet which were altered by Picard.

Hmm... if you have some items in your library that you don't want there, beet rm is what you want; and if you have a directory of files you want in your library, you can import them. So perhaps you just need to remove old files and add the new ones?

Great! I'm glad you're enjoying beets. I can see how the beet move -cd command was confusing—it changed the path in your database too, which is probably not what you ever want. We should consider changing that default. In the future, until we make that change, it might be better to try the convert plugin instead. As for cleaning up the mess: the best way to rectify things, unless you have a backup of your database file before the move command, would probably be to use beet import -AC to scan…

And I removed the unwanted files with

beet remove -f path::^/home/juh/Musik

Now all is consolidated.

In the future I might split the path up again, so that I can easily use certain files with my dj software in a special path. But for now I will leave everything under ~/beet/.

Ah yes, good point—we don't currently have a date field in the beets database; the release date is stored separately as $year, $month, and $day. It shows up in the info output (without -l), however, because we do have a file-level abstraction for it.