Playlist import silently ignores relative path errors

[gwern]

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]

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.

[jonaski]

I agree that better error messages should be shown, I'm working on some improvements to the handling of errors.
But I'm not sure what you mean by strawberry itself, do you mean where the strawberry executable is, or do you mean where the collection directory is located?

[FeepingCreature]

Presumably the cwd of the process?

I think @gwern is coming at this from a commandline perspective, where Strawberry is started as a command from a shell, whereas Strawberry is designed as a GUI program first and foremost, so cwd is generally irrelevant cause you'll open it from the menu or runner.

[gwern]

Yes, but if you don't specify a directory, you would expect it to launch with ~/ as the cwd. What else could it possibly be? /?

[FeepingCreature]

My point is that the idea of a cwd is a commandline concept to begin with. I wouldn't expect a graphical program to even care about it, even more one that's usually started only once.

[gwern]

Oh, a graphical program still needs to care about it at least a little. As long as that GUI program is running on a system with a hierarchical file system, it has to care. It may not be interested in directories, but the user is. Consider the 'Open File' GUI dialogue - say, 'load a music file' or 'load a playlist'. Where does the filepicker browser open at? It would be inconvenient to make it not open 'at' anywhere, and require the user to type in a directory from scratch, and GUI programs like Strawberry would not do that: they will instead open up a logical directory somewhere and the user navigates GUI-style from there.

So, where? A decision has to be made, the knowledge has to be somewhere. Where they open at will depend on the specifics. (An existing Strawberry installation will probably want to open at wherever the music library has been specified to be. A new ignorant installation will want to open at ~/, while to be clever, it could try to guess and look for common prefixes like ~/Music/ or ~/music/ and default to opening at those until the user tells it where the music library really is.)

But the Linux user's expectation is that if they haven't set a target in some way and there's not an obvious one that the program would know about and which is obviously superior to ~/, then all operations will happen relative to ~/.

[guprobr]

The argument about home directories in POSIX has some flaws:

Not Everyone Gets a Home Directory: It's true that POSIX doesn't mandate a home directory for every user. System accounts like "nobody" or "ftp" might not have one. So, relying solely on ~ for user-related operations can break in specific scenarios.

Multiple Accounts, One Machine: A single machine can have multiple user accounts. Opening a file picker in ~ for a specific user might not be helpful if you're working with another account's files. Applications should consider the context of the current user.

Shared Workspaces: In collaborative environments, users might share workspaces outside their home directories. Opening a file picker directly in ~ wouldn't be intuitive if the user expects to work on files in a shared project directory.

Defaulting to Current Directory is More Flexible: A more user-friendly approach might be to default the file picker to the directory the user was previously working in. This provides context and avoids unnecessary navigation.

Here's a better approach:

Context-Aware Defaults:
For new users, consider ~/ or a system-defined default location for common file types (e.g., ~/Documents for text files).
For existing users, prioritize the directory they were last working in.
User Preferences: Allow users to configure their preferred starting directory for different file types or actions.
Breadcrumbs and Navigation: Provide clear navigation tools within the file picker, allowing users to easily jump to their home directory, shared folders, or frequently used locations.
By following these practices, applications can cater to a wider range of POSIX system configurations and user workflows.

[gwern]

I hope ChatGPT didn't write your comment... Most of these points don't make sense to me.

"nobody" and "ftp" may not have home directories - but you had better not be running Strawberry under those! That is not what they are intended for, they would likely break Strawberry in other ways, probably should break Strawberry (eg. I can see no reason either of those users should have any access to audio hardware), and expose Strawberry to bad things (those exist in part to confine remote attackers - so why would you want to expose your music player to attackers?). So it doesn't matter.

Opening up another user's music files is highly unusual and an edge case not worth considering, and it's hard to see how Strawberry could in any way a priori know that user A would want to start spelunking around /home/user-B/ instead of his own ~/.

I have no idea what usecase ChatGPT expects Strawberry to be opened up in a shared workspace outside homedir. (What is a 'shared workspace' to begin with?)

Defaulting to 'current directory' is meaningless. There is no 'the directory the user was previously working in'. I could have a hundred terminals and shells and GUI programs all open with different current-working-directories. Which one was I 'previously working in'? If this means the last directory the Strawberry GUI picker was open to, then sure - in fact, checking right now by opening a music file from a random directory and then re-opening a music file, Strawberry does just that, like it should. But obviously that doesn't answer the question of where Strawberry would default to.

And the context-aware defaults section mostly just reiterates what I already said: if there is no user setting or a sticky location, then a music app could try to default to a desktop or standardized location like ~/Music/, and if there is no such directory there either, then it would be expected to default to ~/.

[FeepingCreature]

(And I continue to think this is all irrelevant because playlists have to resolve relative paths relative to the folder of the playlist anyway. Playlists in the same folder as a bunch of music files are far too well established a usecase.)

[guprobr]

I was trying to explain to you some points about best practices in POSIX environments, and yes I did use Google Gemini for better english than mine. I'm sorry for trying to share knowledge with you. Thanks.