search

strawberrymusicplayer / strawberry

:strawberry: Strawberry Music Player
https://www.strawberrymusicplayer.org/
GNU General Public License v3.0
2.53k stars 164 forks source link

Playlist import silently ignores relative path errors #1470

Open gwern opened 5 days ago

gwern commented 5 days ago

Strawberry v1.0.23-1build3 (Ubuntu) exports my music playlists with relative file paths pointing to the music files in ~/music/abc/foo.ogg etc, to a file ~/Playlist.xspf. I export my playlists for backups and I store them in another directory, eg. ~/backups/strawberry/, so as to not clutter home with backup files. When I 'import' a playlist from there, it yields an empty playlist. There are no visible error messages or any indication of any problem besides the playlist being empty. Importing repeatedly or restarting Strawberry or re-exporting the playlist do not change anything. Is the XML corrupt, no longer supported, Strawberry doing something confusing underneath, the newly imported playlist hidden, the import command not running at all, or what...?

It turns out that if you look at the debug information printed out to the terminal and you watch during the import process, the reason is obvious: Strawberry is looking for music files relative to the XSPF playlist and not Strawberry itself, and so it looks for each file at ~/backups/strawberry/music/abc/foo.ogg. And this is because the XSPF file simply encodes the filename as a relative path like music/abc/foo.ogg, and not ~/music/abc/foo.ogg or /home/gwern/music/abc/foo.ogg or $HOME/music/abc/foo.ogg etc.

On further checking, the config settings do permit you to export with absolute paths, so that's fine, but the bigger problem here is that:

  1. it is not obvious to me that Strawberry should interpret relative paths in a playlist relative to the directory the playlist is in, rather than Strawberry itself. The playlist could be anywhere, couldn't it? Why expect it to be stored exactly relative to the relative filenames? If I am running Strawberry as normal, it is running with ~/ as its working directory, and I expect all relative paths it deals with to be relative to ~/, and not anywhere else.

  2. Regardless of that, Strawberry should not silently ignore import errors like this and simply casually import an entire empty playlist when each file fails to be found.

    This would have been much easier to debug had Strawberry popped up a big list of errors like Error importing playlist: could not find file /home/gwern/backups/strawberry/music/abc/foo.ogg, /home/gwern/backups/strawberry/music/abc/bar.ogg, /home/gwern/backups/strawberry/music/abc/baz.ogg, /home/gwern/backups/strawberry/music/abc/quux.ogg, .... Then the source of the error would have been much more transparent and the problem obvious once I opened the XSPF and easily fixed by simply doing a search-and-replace to prepend the full absolute path, or relocate the playlist files to ~/ and then import them, or looking for a playlist-relevant config option to make it absolute etc.

FeepingCreature commented 5 days ago

Looking for paths relative to the playlist is the correct behavior. Often when exchanging multiple tracks, playlists are stored together with the tracks they reference. If you store your playlist together with the music and back it up alongside, it should work.

(If the tracks were moved to backups/, but the playlist was not, there really isn't anything Strawberry can do to find them again.)

Fully agreed that there should be some feedback if opening a playlist fails to find a path.