LMS-Community
Feature Request: User-Configurable Encoding + Line Ending Style for M3U Playlist files
My Server is running on a Linux-based network server with UTF-8 filesystems exporting the media drive to a Windows host, thereby sharing my Playlist files with Windows Media Player. I guess that this is a rather typical setup.
So it would be very nice if the Server offered some configuration option for the Character Encoding and Line Ending Style used when reading and writing M3U Playlist files. Queries like these https://github.com/Logitech/slimserver/blob/c5b615fe8e88ce1febf93afa586f9c73755d3066/Slim/Formats/Playlists/M3U.pm#L134 are not applicable in such scenarios to select an appropriate encoding.
So I propose to simply make that user-configurable with a default option of 'Auto' selecting the current behaviour for backwards-compatibility.
That line is about the filename only, not about its content. I don't think we make assumptions regarding the content. I think the setup you describe has been used by many in many years. It should "just work". In particular when it comes to content (rather than paths - which can be a pain to deal with).
Hm. I'm not sure whether I get you right. I'm just pointing out that guessing the encoding of M3U by the platform the server is running on may not be applicable in all cases and that I thus believe that it would be a benefit to make that user-configurable. For me, the current behaviour didn't work. I had to patch the slimserver source code to have DOS line endings and CP1252 encoding of pathnames in my M3U, otherwise the Windows Media Player didn't correctly load the playlist (I share the playlists between Slimserver and WMP). I don't know whether WMP would accept UTF8-encoding with BOM, I haven't tested that. But anyway, the UNIX/DOS line ending style question remains.
As you've found a hack, would you mind sharing the diff? Or even create a PR? That would give us a better idea what we're talking about.
PR: no, I can't because my hack was a very crude quick-hack... But see what I did here: https://github.com/Logitech/slimserver/commit/4c9f437c8aeaa7279550b11d266f8d7b69792131 Basically, I generally replaced writing out UTF-8+BOM by CP1252 (thereby breaking all other playlist formats than M3U) and patched writing of M3U to always have CR/LF newlines.