Code: Select all
../my folder name/file name.ext
www.site.com/path name/file name.ext
Code: Select all
../www.site.com/path%20name/file%20name.ext
my%20folder%20name/file%20name.ext
No. Neither of those two lines are valid URLs.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
Those can be both parsed as paths or URLs, but with different incompatible meanings.Encoded URL and local path:Code: Select all
../www.site.com/path%20name/file%20name.ext my%20folder%20name/file%20name.ext
Code: Select all
../
Code: Select all
http://
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.There is a difference between breaking a legitimate use case, and exposing a bug in another software.And using the % breaks other things.
I doubt that the option can be explained in understandable fashion to users. But patch welcome.Conclusion, they should have both options.
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
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
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.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.
True since ver 3, there's the problem.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.
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.True since ver 3, there's the problem.
Yes, I now realize that's the reason for this dogmatism.It's defined by the URL specification.
This information is not correct.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.True since ver 3, there's the problem.
For all URL-safe characters - unless they were already encoded in the source - and of course for all separators. For most characters, really.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?
Yes it is correct and also easily verifiable from the source code version control system.This information is not correct.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.
Return to “VLC media player for Windows Troubleshooting”
Users browsing this forum: Google [Bot] and 68 guests