Support M3U playlists that use %20 for spaces (like a URL)

[kbridger]

Feature request

I'm using Lollypop to manage my playlists. M3U playlists saved by Lollypop are read and work great with music servers such as Navidrome, allowing web access to my collection.

I'm trying to load such playlists into MPD, and it fails. MPD doesn't seem to parse the "%20" as spaces in the track name/location.

Here's a sample playlist.

#EXTM3U file:///media/Music/Madeline%20Goldstein/Forget%20This/09%20-%20Time%20Takes.ogg file:///media/Music/The%20National/First%20Two%20Pages%20of%20Frankenstein/04%20-%20This%20Isn't%20Helping%20(feat.%20Phoebe%20Bridgers).ogg file:///media/Music/Jonathan%20Bree/Pre-Code%20Hollywood/10%20-%20Steel%20And%20Glass.ogg

Loading this into MPD via ncmpcpp results in an error message in mpd.log

Jun 02 09:55 : exception: Bad song index

If I find/replace %20 with " " (space) then re-try loading via ncmpcpp, it works flawlessly. However Lollypop overwrites the M3U file when a change is made to it.

Could MPD more intelligently interpret %20 found in M3U files?

[MaxKellermann]

There's nothing "intelligent" about it. If MPD unescapes all %20 to a space, what happens with a file whose name really contains a "%20"? This potentially breaks existing playlists. Can you point me to the M3u specification which defines the escaping rules for the URIs contained therein?

[kingosticks]

For the URI case, the URI spec exists and defines percent encoding should be used and what to do for literal '%' characters. So if you know it's a URI then it's clear what to do.

The problem is, as Max knows, the M3U spec doesn't exist. Don't waste your time looking. You might consider RFC 8216 to be the closest thing but just using that would break some existing playlists. This is because M3U parsers generally support both URIs and bare file paths, but it's not trivial (or maybe even possible on some platforms?) to identify which you have. I think you could do something pretty sensible in most cases but maybe it's too complex.

Arguably mpd could have a "strict RFC 8216" option when parsing M3U files and treat everything as URIs. Alternatively you could post-process your M3U files but unless you can automate that it doesn't seem like a good solution.

[kbridger]

Understood the spec isn't going to help. To brainstorm:

• Could MPD try both interpretations, and use the one that resolves to a real file? Or both if it resolves to 2 files (which would be weird but possible I guess).
• Could the user specify how to interpret it?