Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Presumably one of the not so rare upgrades changed the parsing of m3u files

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Had a playlist with some file names containing #, like this (in the m3u)

	06 - Bagatelle #2.flac

Loaded playlist to play the whole album.

   * What was the outcome of this action?

Failed to play all and only the files with # in their name.  Reported
unable to open mrl and gave full path that ended where the '#' would
go in the popup dialog.  Like this:

	.../06%20-%20Bagatelle%20

The truncated names also appear, without the URL escaping, in the track
information in the UI with the "#2.flac" omitted.

   * What outcome did you expect instead?

For the playlist to work as it has for many years (happened in an album
that has file dates from 2012) and play all the tracks.


Sanity check: if the track is added by "add file", the filename is not
truncated (in information from the UI) and plays.

*** End of the template - remove these template lines ***

Still present in Buster (vlc 3.0.8-0+deb10u1).

There are other characters that are mishandled by either the m3u
parsing or the path handling (as the path is built from local names in
the m3u), but apparently I didn't report them as they were discovered
and I have no notes with details.  It was more useful to me to rename
things as I came across them, I'm afraid.  :-/

Control: tags -1 + wontfix

Hi,

The hash in a URL is the anchor separator, so what VLC does here is very much intended. If you need a hash in a file name in a M3U, you should encode it as %23 so that there are no ambiguities.

Br,