Playlist m3u wrong encoding / chars

[oortone]

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.

I don't know how your source code can verify that I failed to use my plyalist on other computers than the one that created it but I can record a video showing that it's not the case. I can use these VLC ver 2-playlists on another computer both using VLC, other software players and Sonos hardware players.

If I move my media library your statement is true, if I don't move my media library (which is the case here, it stays on the wifi harddrive) your statement is false.
And of course this must work since absolute paths to a Wifi harddrive are always the same regardless of which computer in the network is accessing it.

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.

OK, that is trivial and will always produce %-encoding from the user's perspective.

[oortone]

I will leave this discussion now because it’s going in circles. But to summarize:

%-encoding is mandatory for URL:s So from that perspective the new VLC3-way of encoding is correct.

However the de facto standard for M3U playlists used by a vast number of systems and software is often not %-encoded and some of these systems have been around since the nineties. In the original Fraunhofer version of these playlists, %-encoding was not used for local files. %-encoding for local files breaks the functionality for many users and calling other systems ”crappy thirdparty software” doesn’t change this fact. The ’U’ in the M3U-suffix is of no importance either. The way M3U-playlists are used is a de facto standard that VLC3 partly breaks.

So from a user perspective, where the production of playlists needs to be useful and compatible (as opposed to being dogmatic) the VLC3-way of encoding local file paths is in many cases improductive and breaks workflows. From many other softwares and systems point of view, VLC3 is probably to consider the ”crappy thirdparty software” since it produces incompatible playlists.

The same goes for absolute vs. relative filepaths. None of these options is the best chioce in every situation. There are pros and cons with both.

The %-less way of encoding playlists is not a ”bug” as stated in this thread. How could it be a bug when it has been in use for decades? That’s plain stupid to say.

However, VLC is not primarily intended as a playlist generator so from that perspective it’s probably better for users to find a tool more specialized for that task. That’s what I did.

[Rémi Denis-Courmont]

I can use these VLC ver 2-playlists on another computer both using VLC, other software players and Sonos hardware players.

Only if the two systems have the same file system convention and the same mapping. This is rather the lucky exception if it works, especially on an embedded player.

And of course this must work since absolute paths to a Wifi harddrive are always the same regardless of which computer in the network is accessing it.

And this again is generally and most often not the case. It only works if you specifically used the same OS and mount points.

[Rémi Denis-Courmont]

No. Using URL is a well established practice for years on, as e.g. web radios have used that format basically since the inception of M3U. The problem is simple: you cannot have both file and URL at the same time. You can also not have both relative and absolute locations. On reading side, you can try to guess and it most often, but not always, will work. On writing side, you need to pick one - and unfortunately, it is not something that you can pragmatically have the user determine.

The goal of the playlist export is to be compatible with non-broken apps, especially VLC itself, and to be portable, all with the least loss of informations. Using file paths, especially absolute paths, utterly fails to achieve that goal since it prevents saving any non-local item and moving the playlist.

VLC 3 is still accepting all of relative URL (something VLC 2 did not do properly), absolute URL, absolute local path and relative local path (again, something VLC 2 did not do properly).

[mederi]

I forgot to mention Clipper, the VLC Extension that can save m3u playlists (absolute or relative paths). Then a saved file is encoded as UTF-8 without BOM (.m3u8 filename extension?). You can convert to ANSI in a text editor (Notepad: File > Save As... > Encoding: ANSI; Notepad++: Encoding > Convert to ANSI and then save).

[oortone]

...The problem is simple: you cannot have both file and URL at the same time. You can also not have both relative and absolute locations....

And the solution is user option but not if you are dogmatic.
Bye bye.

("Broken apps"... you are really stupid)

[jrjrjr]

Three pages of arguments on fit/form/function, wow.

We just need the old option available, as the new version BREAKS prior functionality.

oort: Dogmatic is being extremely polite.

VLC has been so well executed, it deserves it's arrogance.

But it doesn't help to foist it on the USERS.

How about an option for the old method....
or a convert option that generates the output files to a target directory ?
as that is the users' goal.

jr

[Rémi Denis-Courmont]

I still don't see how the typically user will know/understand what option to choose.

[jrjrjr]

Remi,

I can understand and applaud your effort to stabilize the wild west of M3U's.

Perhaps a few options listed, based and tagged just by compile date will get us by for now.

Your effort should be picked up by all the add on's (really follow on's) and their software needs to be updated.

I think we are all trying to achieve a Target List Output for VLC.

It would be great if VLC bypassed all the sloppy add-ons (follow on's) and generated output files from your corrected URL/ Playlist format.

I'd love to see it convert a playlist to a specific output file target and filter/convert during the process, I.E. FLAC to MP3

I think the users are just trying to download functional MP3's to many different targets, phones, vehicles, NAS storage.

We all use VLC, but sometimes it has to go to an un-flexible end use device, vehicles etc;

Thanks for your effort,

jr

[osxtom9]

Hello,

I have the same problem. Since i updated my VLC to version 3.x, my car player cannot read the new created m3u playlists. Now i have go back to the version 2.2.8. I hope it will be fixed soon. Thank you.

[Ragnaroek8]

Hi,

I have the same problem and others. I was not so firm with m3u-Files but wanted to use them with my new NAS. But the files build with VLC doesn't work. It was a frustrating experience for me, to get the NAS working with m3u and the last of many problems came from vlc. I want try to explain, how a user like me, use vlc.

I start vlc and select some songs from my NAS in playlist and hear them. Sometimes I think: "Cool playlist" and save them. So I can hear it days later again OR so I thought can hear it from my new Onkyo receiver via UPNP from my NAS.

But: It doesn't work!

Cause of this F**CK**G "%20"-WASTE in these files. Now I read in this thread the reasons why and can only shake my head.

Fact is:
VLC write m3u files correct.
Most other devices can't handle these VLC-m3u files.

Question:
Why not make a Configuration Dialog for m3u in Advanced Settings?
There are some settings, that I suggest adding in this dialog.
- m3u files will be written absolute or relative to a path.
- The using of slash or backslash.
- with or without a leading slash or backslash.

Okay. Everything not standard for m3u-Files, but it is used in the REAL WORLD from several tools and devices and it would make vlc a little smarter and wouldn't it be cool to say. "Your m3u file doesn't work? Okay, please go to "Tools-Preferences-..."

Folks.
Don't block. Be creative, open your minds. There is a problem. Please solve the problem.

Grettings

Bernhard

[Swhicket]

There is a very easy solution. Create and save the playlist then open it in notepad or anything that will do replace. Open the find replace and in the find box put %20 and In the replace type a space yes you need a space in the box even though you cannot see it. Select the replace all and then save when it is done. This replaces all the %20 with a space making the file like the old format. Hope this is clear and helps. I joined just to post this and may not ever look at this again.

[artwork01]

Why does VLC, when saving a playlist as m3u, encode a path that was once
"Singles\Tears 4 Fears - Shout.mp3"
to
"Singles%5CTears%204%20Fears%20-%20Shout.mp3"
so that other music players cannot parse that correctly?

[Rémi Denis-Courmont]

VLC does not encode entries in exported M3U. It just writes a syntactically valid URL, either absolute or relative.

[AntaresTTH]

Why does VLC, when saving a playlist as m3u, encode a path that was once
"Singles\Tears 4 Fears - Shout.mp3"
to
"Singles%5CTears%204%20Fears%20-%20Shout.mp3"
so that other music players cannot parse that correctly?

Exactly. I can't understand that it seems so difficult to understand that it is no more a correct behaviour. VLC was so good before that. Every car audio in vehicles Skoda/Seat/Volkswagen/Audi/Opel/BMW so far can NOT read it including brand new models from this year !

[beks]

You can just use a plain txt-File URL Decoder to convert VLC Playlists in a commonly readable M3U format:

Python Script: [url=https://github.com/sebibek/.idea/blob/master/URLdecode.py]Python Script[/url]
Usage: python URLdecode.py pls_in.m3u pls_out.m3u8

If you need m3u-format, just use another media player to save it back in this format...

or you could use the mentioned Clipper VLC plugin, which is somehow unintuitive, but basically works as well:
Steps:
Open VLC->View->Open Clipper
Save Absolute/Relative
Convert to UTF8-BOM via Notepad++

Manual Alternative: https://www.url-encode-decode.com/

Hint: You can convert your VLC playlists to non URL-encoded M3Us, reopen them in foobar2000 and then use its powerful Playlist Manager to move/copy/convert the linked files...

[skoehler]

VLC creates broken M3U files. That's a fact. According to the english Wikipedia [1], an M3U file can contain absolute file paths, relative file paths, and URLs.

However, when VLC writes relative files paths, VLC also applies URL encoding (e.g., it replaces a space with %20). That seems to be a bug as it is not compliant with other tools.

URLs are URLs and file paths are file paths. Why apply URL encoding to file paths?

Now you may argue that you are saving valid relative URLs. So where's the file:// prefix that tells us that it's a URL? The problem is, that relative URLs (without the leading file://) cannot be distinguished from relative file paths. An application would not know whether to decode %20 or not. However, it seems common practice to treat relative paths as file paths (without URL encoding) not URLs. Repeating over and over again, that you are producing correct (relative) URLs is not constructive. If you want VLC to be interoperable with other tools, you need to store relative file paths, not relative URLs.

[1] https://en.wikipedia.org/wiki/M3U

[Rémi Denis-Courmont]

As already noted, relative paths don't work if you move the playlist to non-local storage, such as personal cloud storage (typically served by HTTP), where there is no such thing as paths, only URLs.

VLC does not contradict the current Wikipedia article - though that's not a specification anyway. There is no M3U specification. Even the HLS specification merely refers to Wikipedia instead of a proper specification: https://tools.ietf.org/html/rfc8216#ref-M3U so arguing that VLC does or does not follow the specification is rather pointless and I'm going to ignore any further comments to that effect.

As a matter of facts, the format is ambiguous. You cannot normally mix URLs and paths. Different applications have widely different heuristics to do so and to "fix up" syntactically broken URLs when necessary (not even curl and wget agree with one another).

The VLC writer is designed to generate portable/movable playlists between file systems, protocols and encodings, and be interoperable with the VLC reader with no loss of data. Using local paths would utterly fail to achieve those goals.

[ThomasR]

I just stumbled upon this issue because VLC refuses to load (!) any of my old playlists and I tried to get behind the problem.
I understand the reasoning behind saving M3U files using URLs even for local files, even though I agree that an additional option to save it "the old way" would benefit those who are searching for it. There's no denying that there's a huge pile of software out there that can't handle URLs and being forced to take detours through converter software is... inconvenient, to say the least, especially if it used to work in the past. However, always saving M3Us with URLs takes away the ability to save relative playlists, because the file:// protocol does not allow relative paths.
Also, always saving absolute paths makes it impossible to port the playlist to other computers, which was not only easy with relative paths, it was the only way to make a playlist on the PC and copy it to a music player or your phone. Guess I have to use different software for that now.

Also, I found out that VLC can't load my playlists because they contain files with square brackets in their name and apparently, since VLC treats every entry in a playlist as URL (even though it may not be one per M3U spec), I have to escape them using %5B and %5D, which in return can't be opened in other software that doesn't support URL-encoding. I know, not your problem.

I agree that unsafe characters should be URL-encoded when the corresponding entry in a playlist is in fact a URL, but M3U can contain absolute and relative file paths that are not URLs and since it's really easy to distinguish file paths from URLs (just look for "://"), I don't get why square brackets must be encoded? Also, M3U8 files are already using Unicode, so there should be no need to URL-encode anything here... what did I miss?

(Edit) I just noticed that the entries with square brackets CAN be loaded when they're absolute paths, just not when relative. Looks like this might not be intended?

[Rémi Denis-Courmont]

However, always saving M3Us with URLs takes away the ability to save relative playlists, because the file:// protocol does not allow relative paths.

Of course, it does support them. That's why people complain: VLC writes relative URLs (for reasons outlined previously) when some other tools expect relatives file paths.

I agree that unsafe characters should be URL-encoded when the corresponding entry in a playlist is in fact a URL,

But that's exactly what VLC does - use URL-encoding for URLs. It just so happens that VLC always writes URLs (again, for reasons outlined previously).

but M3U can contain absolute and relative file paths that are not URLs and since it's really easy to distinguish file paths from URLs

No it's not easy. There are several ways that a valid URLs will not contain "://" in them, relative URLs for a start. Conversely, "://" can be found in valid file paths (at least on every OS that is not Windows).

[ThomasR]

First off, thanks for answering!

Of course, it does support them. That's why people complain: VLC writes relative URLs (for reasons outlined previously) when some other tools expect relatives file paths.

Ok, got that wrong. It's really a shame that the M3U "spec" is that ambiguous - it's just interpreted characters...

But that's exactly what VLC does - use URL-encoding for URLs. It just so happens that VLC always writes URLs (again, for reasons outlined previously).

I understand and agree, no argument here.

No it's not easy. There are several ways that a valid URLs will not contain "://" in them, relative URLs for a start. Conversely, "://" can be found in valid file paths (at least on every OS that is not Windows).

Ok, I was referring to full URLs that include a protocol. Ambiguous entries are a matter of interpretation, of course.

May I ask what the philosophy is on interpreting input data? Is it strict, like "if it doesn't conform to a clear standard, it will be rejected", or is it more tolerant, like "let's see what we can make of this"?
I'm just trying to understand how square brackets in relative file paths can cause a playlist entry to fail, whereas it works in absolute paths. Is this intended?

[Rémi Denis-Courmont]

If the entry contains non-URL characters, we try to fix them up. This works nicely for, notably, white spaces.

But you're going off-topic. This thread is not about how to read playlists, but how to write them.

[ThomasR]

If the entry contains non-URL characters, we try to fix them up. This works nicely for, notably, white spaces.

But you're going off-topic. This thread is not about how to read playlists, but how to write them.

Guess I'll just file a bug report then.
Thanks anyway.

[Edit] Nevermind, I found ticket 19567. Don't get me wrong, looks like you're technically correct. However, from my perspective as a normal user, it just looks like something is broken in VLC, while it works everywhere else.
I'm out.

[rlm]

Still an issue even today, many years later. You would think with streaming large amounts of data and playlist becoming more pertinent VLC would fix this obvious bug.

For me it cost me a bunch of time working some new streaming devices to realize that VLC is creating not compatible playlist files.

[mytril]

Still the same Problem for normal users. I wanted to create a playlist to play with kodi from my smb share. But kodi doesn't understand the playlist encode from vlc. No playlist type are working, nether m3u, m3u8 nor xspf. It is really sad that noone here listen to all the users here in the thread. We only want a fuctional playlist.

Now i have created this playlists with kodi itself and all clients can play it, also vlc. But with vlc it was simply but doesn't function.

PS: Noone need this comments: We do it right, all others are wrong". If all other are wrong. Is not vlc wrong as only one?