Topic: Playlist filepath problems

[Rah'Dick]

Hey!

I found a couple of issues while trying to prepare playlists for VLC on Android and my Rockboxed Sansa player.

Issue #1
I noticed that when you save a M3U or PLS, all the filepaths are using backslashes (naturally, since this is the default on Windows). However, many other players and devices such as VLC on Android or Rockbox can't read these filepaths - they work fine when you replace all \ with /. The funny thing is that XMPlay reads playlists with forward slashes just fine and VLC for Windows/Linux also doesn't care. Because of better compatibility, I would like to propose an option to use forward slashes while saving playlists.

Issue #2
Assuming you have a directory structure like this:

Code: [Select]

+ Music
   + Playlists
      - test.m3u
   + SomeArtist
      - SomeFile.mp3
When saving a relative playlist to "test.m3u" that only contains "SomeFile.mp3", the path looks like this:

Code: [Select]

\Music\SomeArtist\SomeFile.mp3
although it should be relative to the playlist file:

Code: [Select]

..\SomeArtist\SomeFile.mp3
Even when switching backslashes to forward slashes, other players can't find the files like this. Using ..\ it works, though. Is there a specific reason for the current behaviour?

[Ian @ un4seen]

Here's an update with relative paths that use ".." and a "forward slashes" option for you to try:

   www.un4seen.com/stuff/xmplay.exe

Was actually planning to release XMPlay 3.8.5 very soon, so please give the playlist saving a good test and let me know if you find any problems as soon as you can

[Rah'Dick]

Fantastic, thank you!
A first test was successful, but I'll try it thoroughly tonight, both on my phone and Rockbox. This makes stuff so much easier! <3

[Edit]
I've tried loading the "new" playlists on VLC for Windows, Linux and Android, my Rockbox player (Sansa Clip Zip), Linux Mint default movie player "celluloid" and my favourite Linux music player "Exaile". They all successfully loaded the playlist!

Thank you very much, these changes finally allow me to create playlists and just copy them everywhere, instead of having to edit every single one of them first!

[Edit 2]
Ok, found a little issue with Rockbox, but I can live with that: Rockbox prefers the format to be UTF-8-BOM with LF line endings (.m3u8), otherwise it won't load files with exotic characters, e.g. cyrillic. Rockbox doesn't support PLS and EXTM3U doesn't make a difference, but I think it's actually the byte order mark.

[Edit 3]
I found out that Rockbox is completely happy with XMPlays .m3u files, if I just rename them to .m3u8 - no BOM or line ending conversion necessary! 
Ian, could you possibly adjust the M3U save dialog filter to show .m3u8 files, too? That'd make things even more comfortable.

As always, thanks for your effort!

[Ian @ un4seen]

Thanks for the prompt testing. The .m3u8 extension has been added to the file selector's "M3U playlist files" filter (and the "Associated filetypes" options list) for the 3.8.5 release, which is up on the XMPlay page now!

[jyoun]

Relative paths working except for subtrack listings, like this:

Legend of Zelda, The (1987-08-22)(Nintendo EAD)(Nintendo).nsf::NSF,$00,Title,1:26,1,10

when saved to playlist it gets turned into a fullpath:

file1=C:\Users\User\Documents\music\vg\nes\Legend of Zelda I, The\Legend of Zelda, The (1987-08-22)(Nintendo EAD)(Nintendo).nsf::NSF,$00,Title,1:26,1,10

[Ian @ un4seen]

XMPlay currently won't store a relative path if there's a ":" in the filename (like in your example). Here's an update that should allow them, for you to try:

   www.un4seen.com/stuff/xmplay.exe

Let me know if it still has trouble with your playlists.

[jyoun]

Yes, that update is now saving ":" entries as relative

[Rah'Dick]

Hey again!

I've recently noticed that VLC on Windows and Android now refuse to play any playlist that XMPlay can produce. Turns out, Rémi Denis-Courmont, the main developer of VLC, now insists of URL-encoding paths in playlists, stubbornly brushing off legit criticism that this behaviour not only breaks compatibility with most playlist-capable music players out there, but also with older versions of itself.
And of course, playlists generated by newer versions of VLC (on Windows) don't load in XMPlay anymore, because they are all URL-encoded.

I could not care less about broken third party software.

- Rémi

I can't express how much I HATE this kind of attitude. I'm seething right now.

[Edit] Further experiments have shown that VLC does load M3Us from XMPlay, but only when using backslashes AND full paths, breaking relative playlists or ones that have been saved for Linux. WHY WOULD YOU DO THAT.

[Edit 2] After calming down, I set up a couple of test cases and noticed, that VLC refuses to load relative paths that contain square brackets... absolute paths with square brackets work fine. WTH.

[Rah'Dick]

I looked a bit more into the VLC playlist debacle and it really looks like the developer, Rémi, is one of those technical-stubborn types, who adheres to specifications, even if literally everyone else has agreed on a de-facto way of doing things. Ian, I'm SO GLAD that you've been so flexible and communicative over the years.
I just wish XMPlay would exist on Linux and Android Then I wouldn't have to use VLC (for music) anymore, because, frankly, it sucks for music.

*takes deep breath* ANYWAY... would there be any chance to get decoding of VLC-style-URL-encoded M3U entries into XMPlay? At least you'd be able to open the crap VLC exports nowadays...

[Ian @ un4seen]

Here's an update for you to try:

   www.un4seen.com/stuff/xmplay.exe

It will currently only try to decode playlist entries that begin with "file://", so you shouldn't use relative paths in the playlist if they're encoded too. The problem with trying to decode all entries (inc. without "file://") is when there happens to be a file that actually has a percent encoded filename, eg. perhaps downloaded from the internet without decoding the filename.

Let me know if you encounter any trouble with it.

[Rah'Dick]

I'd first have to find out how to make VLC save relative paths with file:// prefix... probably only, if I don't save the playlist in the same directory as the music. Dunno, gotta test...

The problem with trying to decode all entries (inc. without "file://") is when there happens to be a file that actually has a percent encoded filename, eg. perhaps downloaded from the internet without decoding the filename.

Would checking the entry with stat() or fopen() before decoding the characters help? If it doesn't exist, decode the filename and try again - I know, that would introduce additional speed cost, but you could also wrap the check in a strchr(str, "%") call to see if it needs decoding at all. Not sure if that check would actually save time or introduce additional slowdowns... Then again, I'm not a C developer.

Thanks anyways for always reacting that quickly - you're really setting the bar extremely high in terms of user service! :-)