Playlist m3u wrong encoding / chars

[oortone]

That doesn't really "prove" anything since VLC did not use that URL-format with escape charactes until recently but they have called their playlists M3U for ages and so has many other applications not using that "standard".

If you are implying that VLC invented URLs in M3U, you are being ridiculous. Internet radio channels, and more recently HLS, have used that format for years and years and years.

And there is only one URL format, and it has a proper standard (IETF RFC3986).

Also the Wikipedia page you refer to have examples not using %-escape characters and it also describes URL:s, relative and absolute paths as valid for the M3U format which means that the URL in the name M3U really means "URL", they uset it in an informal fashion apparently.

M3U can contain URLs and file paths, relative or absolute. VLC follows those rules. It reads M3U playlist with relative or absolute, URls or file paths - except for a few unsolvable ambiguous corner cases. It writes M3U playlist containing "URLs or file paths" as well.

I didn't imply VLC invented URL:s, I explained why you can't refer to the 'U' (as in URL) in the word "M3U playlist" as some kind of proof why VLC should break the way it used to write M3U playlist. The URL format is apparently well defined, the M3U format is not. That's why VLC should have kept the old encoding as an option.

[oortone]

Since Winamp times there is no percent-encoding/URL encoding of paths of local files in m3u playlists. VLC could also preserve the option to save m3u playlists for local files without the special encoding, just lists of human-readable paths in simple text files (ANSI/UTF8). VLC supports/loads them, but now cannot save them. If a playlist is stored on the same drive, then relative paths should be used, otherwise absolute ones. I suggest to add another m3u saving profile besides current m3u/m3u8 profiles.

No. As explained before, this breaks if the playlist is uploaded to remote storage (alongside the files that it refers), as you cannot have relative file paths for non-file resources.

And using the % breaks other things.
Conclusion, they should have both options.

[Rémi Denis-Courmont]

As vlc 3.0 does not respect the wiki anymore, vlc 3.0 has a bug.

I don't think indiscriminate, excessive, or irrelevant examples in Wikipedia are authoritative, but FWIW, VLC uses the URL format, which is found in Example 4. So it does "respect the wiki".

[Rémi Denis-Courmont]

And using the % breaks other things.

There is a difference between breaking a legitimate use case, and exposing a bug in another software.

Conclusion, they should have both options.

I doubt that the option can be explained in understandable fashion to users. But patch welcome.

[pepi01]

Hello,

I understand the context, however would be possible have an option to choose the encoding method for the M3U ? mostly because the new encoding break the functionality for creating playlist and in my case the car doesn't recognize any of them among other devices i've

Maybe can be a feature request?

[Rémi Denis-Courmont]

Technically the choice can of course be given. But I don't really know how to explain or describe the two different options in the GUI.

[ale5000]

I think that just a checkbox is enough: URL-encode urls in M3U generated playlists

Note: URL-encode considered as verb in the phrase

[mederi]

URL encoded
Encode to URL encoded (Percent-encoded) format

[aitte]

LoL I hope you where just making fun of him.
I guess:
"Percent-encode local files in M3U Playlists x"
would be ok. Somewhere buried in the advanced settings and ticked by default.

[ale5000]

In my opinion percent encoding is ugly, URL encoding is better.

[Rémi Denis-Courmont]

The question is not whether to use URL-encoding. The question is whether to write local file paths, or URLs.

[ale5000]

The option can apply to both urls and local paths, enabled by default (both local path and url are encoded) to respect the standard but can be disabled (bot urls and local paths not encoded) for compatibility with broken devices.

[Rémi Denis-Courmont]

You are not making sense. Paths cannot be encoded or they are no longer paths. And there is no such a thing as unencoded URLs.

[ale5000]

Sorry I was unclear, here some examples:


Not encoded URL and local path:

Code: Select all

../my folder name/file name.ext www.site.com/path name/file name.ext

Encoded URL and local path:

Code: Select all

../www.site.com/path%20name/file%20name.ext my%20folder%20name/file%20name.ext

On Wikipedia there aren't exact info of what need to be encoded in M3U, so it was just a guess.
But on a web browser also local paths are URL encoded.

[Rémi Denis-Courmont]

Sorry I was unclear, here some examples:


Not encoded URL and local path:

Code: Select all

../my folder name/file name.ext www.site.com/path name/file name.ext

No. Neither of those two lines are valid URLs.

Encoded URL and local path:

Code: Select all

../www.site.com/path%20name/file%20name.ext my%20folder%20name/file%20name.ext

Those can be both parsed as paths or URLs, but with different incompatible meanings.

[ale5000]

Well, I get it wrong with copy paste, the

Code: Select all

../

was meant for the local path and not for the url, and the url was meant to be started with

Code: Select all

http://

[oortone]

...

[oortone]

And using the % breaks other things.

There is a difference between breaking a legitimate use case, and exposing a bug in another software.

Conclusion, they should have both options.

I doubt that the option can be explained in understandable fashion to users. But patch welcome.

If you believe the old format of M3U:s is a bug it seems like there's something you dont understand here or else you are extremely dogmatic.

Of course it would be understandable to users who needs it. If they suddeny notice their new playlists doesn't work and see there's an "old" option they will try it and then it will work. But surely many who fail to create working playslists with VLC have aldready jumped ship now so it's probably too late for VLC to fix it. Myself, I use Decibel https://sbooth.org/Decibel/.

NEW VLC:

Code: Select all

#EXTM3U #EXTINF:149,Pink Floyd - The Thin Ice file:///Volumes/XYZ/SonosMusikbibliotek/Hifi%20%40TTS/CD/Pink%20Floyd/The%20Wall/1.2%20-%20The%20Thin%20Ice.flac

OLD VLC:

Code: Select all

#EXTM3U #EXTINF:149,Pink Floyd - The Thin Ice /Volumes/XYZ/SonosMusikbibliotek/Hifi @TTS/CD/Pink Floyd/The Wall/1.2 - The Thin Ice.flac

There's no bug here. There's a compability issue created by the fact that VLC suddenly abondoned the old encoding with no user option. M3U is not standardized, it's not owned by VLC and changing the way it works overnight like this is of course bound to create problems and it has nothing to do with bugs.

[Rémi Denis-Courmont]

The use of URLs in M3U is very old - at least as old as web radios, so more or less as old as M3U itself. The U in M3U stands for URL afterall. It is also the only format that supports all VLC playlist entries, and can be moved/stored outside the local file system.

As I said, I have no objections to adding another option for writing playlists with file paths (as long as it's not me doing it on my free time). But it cannot be the default, and thus users will not know when to use it and thus it will not really address the concern here that some crappy third party software cannot parse URLs.

[pepi01]

Hello Rémi,

I agree and fully understand your approach.
For me looks fine add an option like "Legacy M3U Export" or something similar under using advanced settings, so far when I need to edit M3U playlist for the car i use a portable version of VLC 2.2.8 so I can survive with this workaround, but ofc if it's implemented on the next release would be quite good

[oortone]

The use of URLs in M3U is very old - at least as old as web radios, so more or less as old as M3U itself. The U in M3U stands for URL afterall. It is also the only format that supports all VLC playlist entries, and can be moved/stored outside the local file system.

As I said, I have no objections to adding another option for writing playlists with file paths (as long as it's not me doing it on my free time). But it cannot be the default, and thus users will not know when to use it and thus it will not really address the concern here that some crappy third party software cannot parse URLs.

OK, I see your point but still your reasoning is a bit strange. I mean, you say "it cannot be the default", well it was default for a very long time. Even in VLC and unless you can point me to a thread where you had objections to this a long time ago, then you too accepted the old format of M3U that VLC used to produce.

So it's very strange to talk about "crappy third party software" as if VLC was never a member of that club. This exactly why there's a problem to change things overnight regardless if you can argue that it's a better idea because the way URL:s are standardized. VLC has been on board the ship producing "crappy third party" playlists for a long time too. By the way, in relation to what company/organisation is it "third party"?

[oortone]

Seems like Fraunhofer where the original developers of M3U and URL:s with the %-encoding where not mandatory. I'm not sure it was even invented back in 1997. So it should be in relation to Fraunhofer we call everyone else "third party", including VLC.
https://ipfs.io/ipfs/QmXoypizjW3WknFiJn ... i/M3U.html

[Rémi Denis-Courmont]

URL are not defined by Fraunhofer. Unlike M3U, they are formally and well defined by IETF standard number 66 (a.k.a. RFC3986).

%-encoding is the only way to represent non-URL-safe characters. VLC only percent encodes where unavoidable.

[oortone]

URL are not defined by Fraunhofer. Unlike M3U, they are formally and well defined by IETF standard number 66 (a.k.a. RFC3986).

%-encoding is the only way to represent non-URL-safe characters. VLC only percent encodes where unavoidable.

True since ver 3, there's the problem.
And the fact thet M3U is a de facto standard, not completely defined but used by many.

Did I write Fraunhofer invented URL or M3U?
Do you misinterpret what I write on purpose?

Anyway, there's one piece of new information here. You write VLC "only %-encode where unavoidable".
How is that determined? Can you give an example where there would not be % encoding in the new version?

[Rémi Denis-Courmont]

It's defined by the URL specification.