Problems reading square brackets in existing/external m3u playlists

[RobAtx]

Hello folks,

It seems like VLC (Android) has a problem with the characters "[" or "]" in the file structure or the track name ... for example album "[2009]"!

Is this a bug or is there a solution?

I don't necessarily want to recreate my entire database and eliminate these characters including playlists etc. and I don't really want to do without VLC!

It also seems like several people have problems with "missing records" or the like, that could be their problem too!
If I replace the characters with parentheses or spaces whatever, the entries appear them all over again.

Please provide information, thanks in advance!

(Android-App / f-Droid / latest Ver.; 3.4.2)

[evadedave]

VLC 3.4.2 from F-Droid as well here. Added an MP3 with square brackets in filename and folder name both, and it shows up fine after indexing. No problem with similarly named video in same folder too.

[Spike1]

Remarkable, same version, different behavior! Were the files in internal memory or on micro-SD (which uses a different file system)?

[RobAtx]

First of all, thank you for your quick answers!

I have several devices in use ... one thing in common is that the official version is installed on all Lineage.

For reasons of space, the music data are mainly on SD cards which have been specially formatted by Android and now also belong to the internal memory on some devices.

Android versions 9-11

The Lineage pre-installed music player has no problems with displaying or playing music tracks stored in playlists in folders containing, for example, [UK] or [2009]!

“Vanilla music” also works flawlessly.

Only VLC simply reads out such titles in playlists, for example ..... annoying!

After various re-saving of the data and re-reading, I now have the problem mainly only with entries in playlists!

Thank you in advance for suggested solutions!

[RobAtx]

Additional possibly important INFO to solve the problem !!!:

Another device just tested and it affects playlists of some complete CDs again! (Samsung Tablet / OfficialLineage 11)

If you let VCL play the music from a file explorer, it will play it back without any problems, but instead of the title / artist only, for example, “fd: // 86 - Unknown artist” is displayed!

But if you are looking for the album yourself via VLC, eg via artist
is this displayed, played with all correct information and then also displayed with all information, strange somehow ...

I uploaded all data to all devices again and are the same everywhere!

It seems as if VLC has a problem reading the file structure correctly and then thinks the title, whose storage location is exactly as it is described in the m3u file, does not exist and therefore does not even show it in the playlist ...

But he knows that the album exists in principle and then apparently also where it can be found, otherwise he would not be able to display and play it after a manual search! Strange!

I think only a programmer from VLC can answer why he does that, right?

[evadedave]

The fd:// issue is a known one and is an Android limitation, although I agree with Spike that VLC's behavior is not ideal and it really ought to do a better job instead of confusing users unnecessarily with cryptic filenames.

After various re-saving of the data and re-reading, I now have the problem mainly only with entries in playlists!

So VLC is only skipping Playlist entries for filenames containing square brackets, but it's indexing them fine so that they show up in the Audio tab?

[RobAtx]

The fd:// issue is a known one and is an Android limitation, although I agree with Spike that VLC's behavior is not ideal and it really ought to do a better job instead of confusing users unnecessarily with cryptic filenames.

After various re-saving of the data and re-reading, I now have the problem mainly only with entries in playlists!

So VLC is only skipping Playlist entries for filenames containing square brackets, but it's indexing them fine so that they show up in the Audio tab?

Correct!!!

An example:
An album with [UK] in the name of the songs, can be found in the search for album or artist!
But, I have previously created an M3u file with songs from this album, this playlist is simply not displayed in contrast to all others!
If only some songs have such an additional name, it may be that the playlist appears, but without the songs with [] in the name....

Or in other words:

VLC can read and display the album with the name "Greatest Hits [UK]" correctly.

VLC can also create playlists from this album by itself!

But if VLC reads an external m3u file, in which exactly this album appears (or even only one track in it with "[ ]" in Name), VLC can't read the characters "[" or "]" correctly!
With all other m3u lists without "[ ]" VLC has no problems at all....

Finally:
That is apparently the only problem in my opinion .... Reading problems from [] in existing m3u files, nothing else ......

[Aza]

Could you please share this .m3u file?

[RobAtx]

Could you please share this .m3u file?

Thank you for your interest!

That's just a lot of different lists with entries like [UK] as I said!

Nothing spectacular, except maybe that I use relative paths because of compatibility of lists in different devices.....
Normal textfiles saved with .m3u instead of .txt, nothing else!

Typical entry of a line showing my folder structure is:

../320kbs NEU/LP`s (nach Interpreten)/David Bowie/Legacy [Disc 2]/01 Under Pressure.mp3

Nothing else to see in it, just the paths. No heading or signature, nothing!

Modified in:
../320kbs NEU/LP`s (nach Interpreten)/David Bowie/Legacy Disc 2/01 Under Pressure.mp3
or:
../320kbs NEU/LP`s (nach Interpreten)/David Bowie/Legacy (Disc 2)/01 Under Pressure.mp3
Works!

But I can't change thousands of folders and album names (incl. the playlists) just to make them compatible for VLC...
Besides, the entries in the ID3-tags would no longer match the foldername, that wouldn't be so great!

[RobAtx]

Can it be that VLC, in m3u files, can not correctly recognize/assign the relative paths by entries with "[" "]"?

[Aza]

It's probably an encoding issue. That's why I need a sample file to verify that.

[RobAtx]

It's probably an encoding issue. That's why I need a sample file to verify that.

Please excuse my inexperience, but I can of course now create a text file on my Linux computer, save some of these lines "../320kbs NEU/LP`s (nach Interpreten)/David Bowie/Legacy [Disc 2]/01 Under Pressure.mp3" under each other in it, rename it to .m3u and then send it to you!

But, what added value has this process compared to all my explanations that I have done so far?

As described I have rewritten the m3u file with Linux (Does it make a difference with which operating system I did it and if not, then why send a file, because you can to it with your device also?) in ->

"../320kbs NEU/LP`s (nach Interpreten)/David Bowie/Legacy (Disc 2)/01 Under Pressure.mp3"
and it works without problem!

So it can not be the text file itself, it's just the entry [ ]!

[Aza]

If it's an encoding issue and I create the file with another editor that uses a different charset, I may not be able to reproduce the issue. That's why I ask for your exact file. You can share it with the sharing service you prefer (Google Drive, Dropbox...).

[RobAtx]

If it's an encoding issue and I create the file with another editor that uses a different charset, I may not be able to reproduce the issue. That's why I ask for your exact file. You can share it with the sharing service you prefer (Google Drive, Dropbox...).

Okay, thanks for the explanation, but I don't use any of these cloud solutions!

[RobAtx]

I will therefore test myself, if I have time, whether that makes a difference!

But I think not, my lists are partly created by Android itself or Vanilla Music or with my Linux computer, that makes no difference!

[RobAtx]

Have now tried the following:

had m3u file created by vanilla music under lineage 9 with relative paths, and copied to usb stick....

same datasets created under Windows, then .txt converted to .m3u and copied to usb-stick...

same datasets created under Linux, then .txt converted to .m3u and copied to usb-stick...

Then copied these 3 m3u files via usb-stick to a Samsung tablet with lineage 11 and VLC from F-droid....

Then copied these 3 m3u files via the usb-stick to a Samsung Note 10lite with original software and VLC from Playstore....


On both devices VLC had produced the same error!

Entries with [ ] were simply omitted, this must also be easy for you to reproduce!

[Aza]

Here is why I ask for a file:

I created a .m3u file with VLC desktop with the following folder / files:
- toto/without.mp3
- [toto]/With bracket in folder.mp3
- [toto]/[With brackets in file name].mp3

Generated playist: https://pastebin.com/n4MiQJQH

Result in VLC for Android:

So I am not able to reproduce.

[RobAtx]

Here is why I ask for a file:

I created a .m3u file with VLC desktop with the following folder / files:
- toto/without.mp3
- [toto]/With bracket in folder.mp3
- [toto]/[With brackets in file name].mp3

Generated playist: https://pastebin.com/n4MiQJQH

So I am not able to reproduce.

Thank you for your efforts!

I use, as already posted several times, the following folder structure and use relative paths!

../320kbs NEU/LP`s (nach Interpreten)/David Bowie/Legacy [Disc 2]/01 Under Pressure.mp3

I can not see in your test file these relative paths as I use them, sorry....

please try a path like this:

../Folder/Folder(3)/Artist-folder [Disc 2]/01 Title [UK].mp3


This path must then of course also really be present on the test device, otherwise this makes no sense!

In my opinion, VLC then looks whether he finds this title in the path and don't recognizes these (relatively specified) paths, because of the characters [ ]

Therefore, it simply hides the playlist, or the titles contained therein with [ ]

VCL has already read the path correctly, otherwise you could not find and play the album, but the description of the (relative) path obviously does not match with its self-determined data paths, for whatever reason.

[Aza]

This is once again probably an encoding issue on your part.

I once again tried with a generated m3u file from VLC with a path looking like yours and here is what I got:

Generated by VLC desktop, working:

Code: Select all

#EXTM3U #EXTINF:45,With brackets in folder ../Folder/Folder%20(3)/Artist-folder%20%5BDisc%202%5D/01%20Title%20%5BUK%5D.mp3

Generated by hand, not working:

Code: Select all

#EXTM3U #EXTINF:45,With brackets in folder ../Folder/Folder (3)/Artist-folder [Disc 2]/01 Title [UK].mp3

These characters need to be escaped. BTW, the second one doesn't open on VLC desktop either.

[RobAtx]

This is once again probably an encoding issue on your part.

I once again tried with a generated m3u file from VLC with a path looking like yours and here is what I got:

Generated by VLC desktop, working:

Code: Select all

#EXTM3U #EXTINF:45,With brackets in folder ../Folder/Folder%20(3)/Artist-folder%20%5BDisc%202%5D/01%20Title%20%5BUK%5D.mp3

Generated by hand, not working:

Code: Select all

#EXTM3U #EXTINF:45,With brackets in folder ../Folder/Folder (3)/Artist-folder [Disc 2]/01 Title [UK].mp3

These characters need to be escaped. BTW, the second one doesn't open on VLC desktop either.

Ok, so you can see here very nicely that VLC stores the characters wrong!
He makes internally from empty characters "%20",from "[" -> "%5" and from "]" -> "%5D"
That can't work then, if it compares these in the format with the data in the lists!
This is obviously a malfunction, do you see it differently?

No other program does this obviously, otherwise not all other apps, car radio, Android etc. would work with the lists and it would not e.g. "vanilla music" the lists differently output, as I use them, namely quite normal, unmasked!

"These characters need to be escaped. BTW, the second one doesn't open on VLC desktop either."
Do you mean by this sentence that it's ok to give VLC as the only music player the playlists in a modified format, but you still don't see this as a malfunction of VLC?

[RobAtx]

Just to understand better:

VLC reads a file structure that looks like this:
../Folder/Folder (3)/Artist-folder [Disc 2]/01 Title [UK].mp3

And then saves it internally as follows:
../Folder/Folder%20(3)/Artist-folder%20%5BDisc%202%5D/01%20Title%20%5BUK%5D.mp3

Have I understood that correctly?

And if I then describe this path correctly or tell the program correctly, as the file structure is (../Folder/Folder (3)/Artist-folder [Disc 2]/01 Title [UK].mp3) and the program cannot do anything because it was stored incorrectly internally, is that a problem on my part?

Or in other words:
Other programs on android output the paths as I see them, I also see them correctly on my desktop PC!
Other programs work correctly on android, also Car-Musicplayer etc. all with these unmasked path information and yet the problem is not with the only program that causes problems, namely VLC, but with my devices, software or whatever?

[evadedave]

These characters need to be escaped. BTW, the second one doesn't open on VLC desktop either.

Aza, I suppose the question is, do these characters really need to be escaped? According to Wikipedia there's no formal format spec for M3U; it's just a de facto format with ASCII encoding specified for M3U and UTF-8 for M3U8 file extensions. However the Wiki and Winamp's "Unofficial M3U and PLS file specification" both include examples where spaces in file paths for example are not escaped as %20 (which presumably holds good for square brackets and other such chars as well).

So is there a case for VLC to be able to read local file paths without character escaping also?

[RobAtx]

These characters need to be escaped. BTW, the second one doesn't open on VLC desktop either.

Aza, I suppose the question is, do these characters really need to be escaped? According to Wikipedia there's no formal format spec for M3U; it's just a de facto format with ASCII encoding specified for M3U and UTF-8 for M3U8 file extensions. However the Wiki and Winamp's "Unofficial M3U and PLS file specification" both include examples where spaces in file paths for example are not escaped as %20 (which presumably holds good for square brackets and other such chars as well).

So is there a case for VLC to be able to read local file paths without character escaping also?

Thanks also to you, for your comment!

There is still a little thing that strikes me!

As described in my examples, you only need to replace the square brackets with round and VLC takes over my lists without problems!

The spaces in between don't seem to bother VLC, although it stores both characters, spaces and brackets differently!
the problem can not be only at this point, or am i missing something?

Why it can the "error" %20 instead of blank, apparently internally correct, but the square bracket then again not?

Apart from that, square brackets in music titles are not really unusual! I would probably never have considered them on my own, but insert different cd's into the computer and wait for the automatic CD information!

terms like "Album [2010]" or "[UK]" are rather the rule than the exception here...

And that one would have to rewrite "standard designations" afterwards or also hide, I do not find very user-friendly!
Also as I see I do not have to do so anywhere else, compatibility would then also disappeared, because I would have to create extra lists only for VLC that can not be the solution!?

[Spike1]

At least on the microSD (using the FAT file system), originally (Parentheses) were allowed in filenames. [Square brackets] and other characters that were commands to the operating system, were not allowed. (A long time ago, even spaces were not allowed.) Eventually people wanted to be able to use any character in filenames, so new versions of the file system used an "escape" character to indicate that the following character is to be used verbatim, or is encoded in hexadecimal.

It seems like a valid request for future work that all parts of VLC decode these renderings of characters.

[Aza]

Sorry for the late answer, I've been quite busy these last days.

To be honest, it's not the part I know the most / I work on. I will move this discussion in the general section as it's relevant for all VLC's ports.