Author Topic: Relative playlist paths are flawed  (Read 1022 times)


  • Posts: 20
Relative playlist paths are flawed
« on: 6 Jun '22 - 22:23 »
I am currently comparing XMplay (using right now) to Audacious for Linux. The latter is really bad with hotkey config (like other apps on Linux, too), but I don't want to go into detail unless requested. (rant risk)
Audacious has a compatibility mode for Windows where it can interpret \ in the playlist as /. (I am testing with PLS files. I assume it is similar for other formats.) XMPlay does it, too, without pointing it out as an option. So this would, in theory, allow interoperability of playlists between two such systems.
But the problem is that neither can save playlists properly for this purpose:

If you save the playlist to D:\MUSIC\FOLDER1, it saves paths for files in there without folder structure of course, starting right with the filename:
But if that playlist also contains files from FOLDER2, then it bases the path on the root instead of a truly relative path.
What it does: \MUSIC\FOLDER2\song.mp3 (This does not work on Linux then, because it embeds Windows partitions differently in its directory structure. XMPlay omits the drive letter, so it goes half the way.)
What it should do: ..\FOLDER2\song.mp3 (Which is actually less interpretative effort and a truly relative path. And since compatibility/flexibility is the whole point of relative paths, this is how it should be doing it.)

Furthermore, this could even be considered a privacy / information disclosure issue, if you are really pushing the correctness. Such a playlist potentially exposes additional folder structure that is of no concern to it.

Audacious does the same, just that it adds its own directory structure in front, which contains Linux-exclusive elements.
Which is actually doubly frustrating, because it means even if XMPlay does this properly, then sharing and updating the playlist still only works one way. (And I CBA to see whether I can conveniently contact the Audacious devs to suggest such a change.)

Considering both players do it this way, I am wondering whether there is a really good reason why dotted paths are not used.
« Last Edit: 6 Jun '22 - 22:34 by Dowlphin »

Ian @ un4seen

  • Administrator
  • Posts: 24687
Re: Relative playlist paths are flawed
« Reply #1 on: 7 Jun '22 - 16:25 »
This issue should be fixed in XMPlay 3.8.5. Please try upgrading to that and see if you still have the problem then.


  • Posts: 20
Re: Relative playlist paths are flawed
« Reply #2 on: 7 Jun '22 - 16:41 »
This issue should be fixed in XMPlay 3.8.5. Please try upgrading to that and see if you still have the problem then.
What a pleasant surprise! I just love XMPlay! :-)
I noticed it even has an option to save with forward slashes in the save dialogue. Excellent.

It's kinda typical that the popular Linux equivalent is lagging behind with this, I guess. Recently I am heavily focusing on configuring my new Kubuntu installation towards power user usability and I run into unnecessary to silly obstacles at every step of the way. Part of it is probably the modern methods of software design that cripple everything. In any case, stuff is so wonderfully simple and straightforward on Windows 7, that's why I am still using it. And this is also one reason why I love XMPlay. It offers so many ways to tailor it to one's needs. (The only other app that spontaneously comes to mind now that was like that is Miranda IM.)

Meanwhile on Linux it seems I have to edit some theme config files to stop the taskbar from being translucent. (I already tried other ways which didn't work.) Meanwhile on Windows 8 I have to run high contrast theme mode to be allowed to use any color as window background. Choosing my own NTP server also has to be done via textfile editing ... on KDE!

The best we can do is counter these trends with better examples.

EDIT: I just tried the latest Windows version of Audacious, and at least on Windows it seems to respect the original paths from the playlist it opened and saves them in the same way, with the ".." again. Maybe this works on Linux, too, then.
« Last Edit: 7 Jun '22 - 17:07 by Dowlphin »