The VideoLAN Forums

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.

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

Note: URL-encode considered as verb in the phrase

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

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.

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

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

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.

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.

Sorry I was unclear, here some examples:


Not encoded URL and local path: Encoded URL and local path:
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.

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.

Well, I get it wrong with copy paste, the was meant for the local path and not for the url, and the url was meant to be started with

...

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: OLD VLC: 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.

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.

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

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

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

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.

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?

It's defined by the URL specification.

True since ver 3, there's the problem.

Versions 2.0, 2.,1 and 2.2 wrote absolute paths. So you could only open the playlist on the exact computer that generated it, and only if you did not move your media library. This rightfully infuriated a lot of users.

Needless to say, this did not work on automative players (that OP is complaining about) any better than version 3.0.

It's defined by the URL specification.

Yes, I now realize that's the reason for this dogmatism.

Seems like the fact that Fraunhofer ages ago chose the letter "U" in their suffix have made you shut your eyes for how M3U-playslists have been used and produced since 1996. Whetether or not it was wrong of them not to use %-encoding for some cases it's a fact they did and so did many others. Including VLC until now.

If they had chosen to call their extension something like M3L (mp3 playlist) or something, this probably would never had happen. It's quite silly. Although I'm sure % encoding solves some problems it also creats others whatever you say.

Still interested though in what you said: "VLC only percent encodes where unavoidable."
Which are the cases where %-encoding is not used in ver 3?

True since ver 3, there's the problem.

Versions 2.0, 2.,1 and 2.2 wrote absolute paths. So you could only open the playlist on the exact computer that generated it, and only if you did not move your media library. This rightfully infuriated a lot of users.

This information is not correct.

If I create a playlist in VLC version 2 for files on my Wifi harddrive and then open this playlist in another computer it will work in VLC on that computer and it will also work in another software player I use on this computer. Additionally it will also work in a Sonos system (which of course qualifies as "another computer") with access to my Wifi harddrive.

If I produce the same playlists in version 3 they will not be compatible to Sonos and the other player because of % encoding.

Still interested though in what you said: "VLC only percent encodes where unavoidable."
Which are the cases where %-encoding is not used in ver 3?

For all URL-safe characters - unless they were already encoded in the source - and of course for all separators. For most characters, really.

Versions 2.0, 2.,1 and 2.2 wrote absolute paths. So you could only open the playlist on the exact computer that generated it, and only if you did not move your media library. This rightfully infuriated a lot of users.

This information is not correct.

Yes it is correct and also easily verifiable from the source code version control system.