Simple file migration

[simonbun]

Hi,

I set up and configured LMS for my brother about 6 weeks ago, and he's really enjoying it.

He's new to Linux and seems to be coping well. The only issue is that he has a folder with an ampersand in the name, which is causing him problems with navigation and scripting. So, he decided to rename it.
I was away at the time, so I told him to change the library assignment - hoping that would be enough to reestablish the links for favourites/playlists etc - but it didn't work.

When I got back I looked through the database and noticed that a number of tables (directory, image, media_library, track etc) contained absolute paths, so all needed to change.

I'm sure there are good reasons (probably performance) why you have so many instances of path in the database (track contains absolute and relative file paths and a link to the absolute folder path in another table), but wouldn’t it make sense if they were relative to the media_library root? That way, if you ever need to do a simple file migration you’d just have to tweak the library assignment in the web UI (or the media_library table).
Alternatively, assuming they're there for performance reasons, offer to handle the update when editing the library assignment.

[epoupon]

Hello!
Indeed, today, folders, music files, etc., are associated with a media_library_id, but this ID can temporarily be set to null during library editing. This was done to allow users to reorganize their libraries as they wish.

For example, a user might switch from having /music/foo + /music/bar to just /music, or vice versa. In this case, the media_library_ids are simply reassigned, and everything is preserved.

What you're suggesting is that a media library should be permanently associated, with only the root definition changing.

That being said, when a new file is discovered, LMS checks whether the file has been moved (using only the MusicBrainz track_id). I had planned to improve this by searching based on metadata and file size, which likely would have fixed your brother’s migration issue.

[simonbun]

Indeed, today, folders, music files, etc., are associated with a media_library_id, but this ID can temporarily be set to null during library editing. This was done to allow users to reorganize their libraries as they wish.

It doesn't allow you to reorganise your library (tracks/playlists), only media_library.path, which must still point to a parent of the existing tracks otherwise they'll be removed. What if I moved them to /media/music?

What you're suggesting is that a media library should be permanently associated, with only the root definition changing.

Yes the relative location of tracks/playlists are associated with a media library, which can then be changed freely e.g. If I were to move from docker to apt I would currently have to mount my library to /music. If tracks/playlists were relative to the media_library then I'd just point LMS to my current root e.g. /media/abc/def/ghi

That being said, when a new file is discovered, LMS checks whether the file has been moved (using only the MusicBrainz track_id). I had planned to improve this by searching based on metadata and file size, which likely would have fixed your brother’s migration issue.

It's reassuring to know that you're going above and beyond to ensure the integrity of ratings/favourites/playlists etc. I wonder how many other servers do that.

It was just a thought, so feel free to ignore :)