Instead of parsing the template at each call to destination(), it's now possible
to parse them *once*, a priori, and re-use the resulting template object. This
is analogous to the re module's compiled expressions.
Previously, all files would be moved/copied/deleted before the corresponding
Items and Albums were added to the database. Now, the in-place items are added
to the database; the files are moved; and then the new paths are saved to the
DB. The apply_choices coroutine now executes two database transactions per task.
This has a couple of benefits:
- %aunique{} requires album structures to be in place before the destination()
call, so this now works as expected.
- As an added bonus, the "in_album" parameter to move() and destination() --
along with its associated ugly hacks -- is no longer required.
At this point, everything's in place except for the import workflow. Album
directory uniquification works if you import two identically-named albums and
then immediately execute "beet move". Currently, however, a couple of things
prevent this from working as expected during the normal import process:
- The tmpl_aunique method expects the item to be associated with an album in the
database before it is called. This is currently not the case.
- With the multithreaded importer, it's possible for both duplicates to have
their destinations calculated before either is added to the database. This
means that neither will detect a duplicate at the time of the move/copy.
- Even if the above issue is resolved, it will be the case that only the second
album to be imported will have a uniquifying string added. If we want to add
the string to the old album, we'll need to explicitly move it.
Also, documentation on this feature is still forthcoming.
For a less cumbersome uniquifying string, only a single field value is now used
instead of a prefix of a list of fields. The old semantics had two problems that
made it both unnecessary and insufficient:
- In the vast majority of cases, a single field suffices (year OR label OR
catalog number, for example) and forcing the string to include many identical
fields is unnecessary.
- If the albums are very similar, a prefix may be insufficient; a better
solution may be found with an arbitrary subset. (Of course, we can't afford to
search the whole power set.)
So we're going with a single field for now. This should cause far less
confusion.
Silently skip loading readline when it's not available (e.g., on Windows).
Readline behaves strangely when a "print prompt," is followed by "raw_input()",
we're moving back to "raw_input(prompt)". This has caused problems with ANSI
colors in the past, so these might recur now.
- Copying and moving are mutually exclusive. Moving overrides copying so the
user only has to add one line ("import_move: true") to disable copying and
enable moving in its place.
- Deleting is only possible when copying.
- Deprecating the "delete" option (moving is almost always better).
- Removed command-line switch for moving. It's somewhat "unsafe", so this
removes some potential for accidental irreversible changes.
- Changelog & thanks.
- Update docs to refer to import_move instead of import_delete as the
correct solution for ending up with only one copy of the file.
User can specify a fixed name (eg *import.m3u*) by setting the `m3u_fixedname`, otherwise a dynamic m3u filename will be generated base on the imported items (album/track title).
The new fields are:
ALBUM: mb_releasegroupid asin catalognum script language country albumstatus
media albumdisambig
TRACK: disctitle encoder
These are not yet parsed from MusicBrainz responses (just added to MediaFile
and the database).
