Use paths relative to music directory

[ghost]

This issue was automatically migrated from Google Code. Original author: jherl...@gmail.com (August 30, 2012 00:17:11) Original issue: https://github.com/google-code-export/beets/issues/432

[alucryd]

I'm also very interested in relative paths. I have my library on a NAS and share it across several computers; while the path is the same on all computers, it differs from the path on the NAS. Ideally I would use only one beets installation on the NAS, but it has an old ppc cpu, so it's not ideal to compute replaygain info. Also getting gstreamer to compile on it is quite an ordeal.

[PierreRust]

I also like beets to store relative path in the database (starting from the library path from the config file). I had to relocate my Music directory sevral times and I haven't found a good way to do this yet as the full path are stored.

As a side effect, it would also probably reduce the size of the database a bit and make network-shared library easier.

[maxammann]

+1

[barsanuphe]

Also interested in this. I recently had to dismantle my NAS, and add its hard drive (with the beets library) on my computer, ie on a different path. I had to import it all again. Looking back, I should have done a beet move before switching the hard drives, but I had assumed only relative paths were used, since beets knows the library path.

[danlamanna]

Also interested in this, was surprised to find out this wasn't the default.

[ghost]

@sampsyo : what's your opinion here?

[sampsyo]

Relative paths would probably be good idea. The problem is that this would be a deceptively large change -- path handling is extremely pervasive in beets, so the changes would not be localized. It's possible the transition would be easier if we did #1409 (pathlib) first.

[naggie]

This would be great, I use syncthing to share music between 4 devices, each with a different directory. It would be nice to be able to share the config and library database.

[awenny]

While it's simple (if you understand SQL) you can change your path like this:

update items set path = '/Newpath' || substr(path, <startposition>) where path like '/Oldpath%' if opening your library file with the CLI sqlite3 (or other sqlite client). Also for the artpath: update albums set artpath = '/Newpath' || substr(artpath, <startposition>) where artpath like '/Oldpath%'. First check, if what you're updating to is what you intended: select path, '/Newpath' || substr(path, <startposition>) from items where path like '/Oldpath%'. The percent sign (%) acts like an asterisk (*) in the file system. Unfortunately, this is only a one-time task. Or you need to run it every time before you execute beets with a different path configuration.

But it would really be great to have relative paths stored.

[GuilhermeHideki]

I think I used a docker container one time to have a "relative path", when organizing the music on a external usb drive, on two computers. The idea was having a layer between the beets and the data. For example, on Windows, the path was /music = D:\music, but on Linux was /music = /mnt/music

[ghost]

Just ran into this issue after moving to a new computer. Ran beet update and proceeded to have my library database completely wiped as everything was removed. This would be a very welcome change that would make libraries much more portable.

[dbogdanov]

Really surprised to find out that relative paths aren't supported, now as I stumbled at this portability issue myself.

[maxammann]

Since I first noticed about this a few years back I just put all my music at "/media/music/library". Its kind of a pain, but I think switching to relative paths could be quite difficult :/

[austinbutler]

Another possibility might be a second directory config option (let's say server_directory) that is the remote path that maps to the local path (for example local directory might be /mnt/music and the remote or server directory /home/myuser/Music). The DB could still store the path where the files ultimately reside, but could translate that for using beets on a "client" where the DB is on a server. Not sure if that's more or less painful than changing to storing relative paths though :yum: .

[austinbutler]

What has worked for me at the moment is this (make a backup of the DB first of course):

sqlite3 ~/.beets.db "UPDATE items SET path = replace(path, '/mnt/old_folder', '/mnt/new_folder');"

[cbe]

What has worked for me at the moment is this (make a backup of the DB first of course):

sqlite3 ~/.beets.db "UPDATE items SET path = replace(path, '/mnt/old_folder', '/mnt/new_folder');"

If your albums also point to externally stored cover art you can update these with

sqlite3 ~/.beets.db "UPDATE albums SET artpath = replace(artpath, '/mnt/old_folder', '/mnt/new_folder');"

[bphenriques]

Is there any recommended way on how to have the music and the library stored in the NAS?

For now, I am will try to store the music in the NAS and having the db file in my machine.

Edit: I think I was able to have the db on the NAS well, however I think it is only manageable as long as the absolute path matches. It works in my case as I only manage my music in a single machine.

Edit 2: db file in the NAS leads to intermetient lock issues.

[artemist]

While changing the database does work, it's not a great solution for synchronizing a library between machines, especially when they have different OSes or usernames.

I hacked together a fix by modifying the beets.library.PathType type to transparently store paths as relative when storing in the database and reversing when taking it out of the database. Unfortunately, the beets util path handling code looks fairly fragile so I suspect there are edge cases where this won't work right.

I would be a lot more confident in code working if we were using pathlib for paths, instead of handing around bytes and strings.

(my "quick hack", probably buggy: https://github.com/artemist/beets/commit/a53fe00fe6026caf223d905960891cda60251ce9)