You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My music collection is in /home/shared/music on my primary workstation. I have
a symlink in ~/music pointing to that directory. My ~/.beetsconfig (which
itself is a symlink to ~/music/.beetsconfig) contains:
[beets]
library: ~/music/.beetslibrary.blb
directory: ~/music
...
Problem #1: When I'm importing music, depending on whether I happen to be
located in ~/music or in /home/shared/music, the database's item.path for the
imported entries will either start with "/home/johan/music/..." or
"/home/shared/music/...". This causes problems if I later try to
re-import/autotag the same music, because it will now try to move it e.g. from
/home/shared/music/foo/bar/baz.flac to /home/johan/music/foo/bar/baz.flac.
Since these two path reference the _same_ file, it somehow ends up _deleting_
the file!
Problem #2: I'd like to copy (or rather periodically rsync) my entire music
collection (including the beets database) to my laptop. However, it has a
different directory structure, so the absolute filenames would not resolve
there.
Proposed solution for both problems: Would it be possible to store paths in the
database as relative to the value of the "directory" setting in .beetsconfig?
Then one copy/move the music folder somewhere else, and beets would still work
(as long as the beets.directory config was updated accordingly). Also, for the
above different paths that (via symlinks) actually refer to the same file,
beets would not attempt to move one to the other, because their relative paths
(relative to the root of the music collection) would be identical.
Original issue reported on code.google.com by [email protected] on 30 Aug 2012 at 12:17
The text was updated successfully, but these errors were encountered:
Original issue reported on code.google.com by
[email protected]
on 30 Aug 2012 at 12:17The text was updated successfully, but these errors were encountered: