Support relative paths from playlist file to media files about playlist-manager-smp HOT 11 CLOSED

Wow, thanks, that was fast! I will definitely check whether this works out-of-the-box for my setup, where the playlists folder is a subfolder of a monitored directory.

from playlist-manager-smp.

That's an interesting feature. Although it requires a bit more of complexity to make it work for all use-cases:

• What about files being on different disks? Your approach just replaces 1 path. And you can not have files relative to different disks at the same time. i.e. it works for you because you have all files on 1 place, but for other users, it would simply break the playlist as soon as they mix files from disk A and B on the same playlist.
• What about people not tracking the folder where the music resides? Then the playlist would be created with right relative paths but being placed in the wrong folder.
• What about mixing playlists with relative and absolute paths? Once you change that setting, it applies for all.
• What about users having really low notions of TF, how these things work, the scripts, etc.¿

So while I would like to add relative paths, I need to think more about it.

• It should be easily configurable (like clicking on a playlist and using a menu "Convert to relative paths")
• Some checks should be done against the current file paths of the playlist to be sure they are all relative to the same disk (and then also a warning with a popup for the user to not add files from different disks).
• There could be another option to just make all new playlists use relative paths. Then you could just use a panel for relative playlists on folder XXX, and another panel for playlists with absolute paths.
• In any case popups with warnings about how it works should be shown.

There is a collateral problem, if you check 'loadTracksFromPlaylist' on the same helper, you will see it's used to load m3u playlists comparing the paths to the ones on the library to load those files as fast as native playlists. Changing absolute to relative paths totally breaks that part (so you may have experienced slower loading time as soon as you load big playlists), but maybe I could just skip the disk letter there and compare the rest (it would not be 100% precise in all cases)

from playlist-manager-smp.

Have added a first implementation of the feature in the latest commits, you can check it. The readmes and change-logs have been changed to reflect the changes, and some popups should appear when trying to change the config, so they should be pretty self-explanatory. Instead of using a configurable TF, I simply use the current tracked folder since playlist folder and music folder should be in the same path to work. That means you must set the playlist folder right to use relative paths, that's the only limitation.

Feel free to add any feedback.

from playlist-manager-smp.

Let me know if anything can be improved :)

from playlist-manager-smp.

Closing it, if you find new problems reopen it or create a new issue.

from playlist-manager-smp.

So, finally I got back to my music collection. After some hick-ups (I had to fully reset the panel), I managed to get the relative paths feature active. Unfortunately, it does not seem to work for my layout: my music has a shared root (Z:\Music) with my playlists folder (Z:\Music\Playlists); the music is not stored as a subfolder within, but in sibling folders (Z:\Music\Albums and others). So by default, even with the option "Save paths relative to folder" set to "Yes", I get absolute paths.

The reason seems that relPath is set to this.playlistsPath, not the library root, which is not part of the music filename. The current form would only work if my music would be located within the Playlists folder, or if I set the playlists folder to Z:\Music.

For a fully general solution, savePlaylist would need to determine whether relPath and path have a common base folder, and determine the correct relative path from there. If desired, I could provide you with a function that does only that and which could be used instead of the $replace(...) TF string. (nodejs's path.relative might be a good inspiration; maybe not that general)

from playlist-manager-smp.

Yes, by design the music folders must be on the same root than the playlist path... I may add a configurable library folder, so relPath could use that instead of the playlist path, thus being equivalent to full relative path handling. (at least within foobar). Simple but would work in your case. Also note the library root can not be retrieved automatically, so it's either a configurable thing which must be input by the user or full rel. path handling. There is nothing in between. And lets not talk about libraries which are split in multiple places...

The general solution is more complex, although I like it. I discarded it because it easily becomes a mess as soon as you take the other tools into consideration.

For ex. loading the tracks is done by comparing the paths at the playlist file against the paths reported by foobar library. To find both absolute and relative paths I'm already checking 3 cases (full path with disk letter, relative path without '.', and relative path with '.'). And to do that you have to replace back the corresponding relative path with an absolute path according to the current tree. If I don't do that, then playlists would be loaded using native foobar methods, which is up to X1000 slower. It is not the saving part the problem (which I may implement myself or using other implementations as you noted) but the loading part and finding matches on the library.

Let me think about it some days, probably I could do it using regexp, thus replacing only the part of the tree needed.

from playlist-manager-smp.

Please take a look at the new branch. It should create playlist files with proper rel. path handling now. (try on new playlists or re-saving previous files).

The tools at 'Check playlists consistency...' should all work too. Also the copy/export tools when L. clicking on playlists. Note export with tracks will modify paths on the exported playlist even if it has relative paths, but that's intended.

Also 'Force relative paths' is meant to transform any playlist into '.\FILENAME' format, not for converting absolute paths into relative paths according to your playlist path. As far as I have checked it works fine, let me know if it works for you and I will merge the branches before next release.

from playlist-manager-smp.

Yes, branch RelPathHandling (f391c1a) creates working relative paths, e.g.

..\Albums\Professor Kliq\The Scientific Method, Vol. III\01 Bayreuth.mp3

from playlist-manager-smp.

Great, closing it. Already merged with main branch. Also fixed and improved some things related to path handling on the process.

from playlist-manager-smp.

Love to read that kind of teamwork to add features to a great feature set to make it even better, good job

from playlist-manager-smp.