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

[kbridger]

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

[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?