[F] playlist files: path length

Hi

I'm using mp3tag 2.84a to save (m3u8) playlist files with relative paths.
The files are properly saved and structured; foobar2000 is able to read them.
But when I try to reopen them in mp3tag, "long paths" seem to be unreadable (german: "Auf die Datei kann nicht zugegriffen werden").
For absolute paths there is no problem.

fails: ....\Komponisten\Saint-Saëns, Camille (1835–1921)\Symphony No.3 C minor, Op.78 »avec orgue«\Boston Symphony Orchestra · Charles Munch, Conductor · Barj Zamkochian, Organ (RCA Red Seal 1959)\01 · I. Adagio – Allegro moderato.flac

works: F:\Klassik\Komponisten\Saint-Saëns, Camille (1835–1921)\Symphony No.3 C minor, Op.78 »avec orgue«\Boston Symphony Orchestra · Charles Munch, Conductor · Barj Zamkochian, Organ (RCA Red Seal 1959)\01 · I. Adagio – Allegro moderato.flac

Is there an a priori limit on realtive path length on (m3u8) playlist files?
If not, please fix.

Thanks
Klaus

The problem might be situated at the beginning of the pathnames.

relative path: ..\..\Komponisten

absolute path: F:\Klassik\Komponisten

Do these path statements actually point to the same starting folder?
Which folder is the starting folder for the relative path?

The relative path version points to two folders above the folder "Komponisten".
The absolute path version has only one folder above the folder "Komponisten".
???

DD.20171009.1122.CEST

Hi Detlev

No, that's not the problem. Remember:

  1. mp3tag itself has created the playlist
  2. foobar2000 is able to locate all files in the playlist
Actually the playlist is stored in a folder F:\Klassik\Alben\, so the two steps towards the root of the drive are required.

And with the same playlist location and some shorter file name in the same target directory (e.g. test.flac) also mp3tag manages to locate the file.

Best regards
Klaus

Maybe there is some tricky thing envolved, which I did not detected yet for sure, but I'm afraid you do not know the meaning of "relative pathname".

When loading the playlist, having the relative pathname, then Mp3tag gives an error message, when the file cannot be accessed via the relative pathname, this looks fully ok for me.

You can check out the Mp3tag setup definition within "Mp3tag Options/Directories/Subdirectories/Favorite directory".
Maybe you have to define or setup a different favorite directory, ...
or you have to define a different relative pathname within the playlist file.

Note:
Your example path is not long enough to become a "long path".
A long path is defined as a pathname longer than 256 characters up to the internal Windows limit of 32000 characters.

DD.20171009.1719.CEST

You can be absolutely sure that I know what a relative path is, so please take your time and check the trickier things ...

Attached please find a sample directory structure with two small mp3 files and an m3u8 playlist file pointing to these files.
The playlist file was created by mp3tag using "make playlist from all files" (Ctrl+P) and with "Options > Playlist > Entries relative from work directory" checked.

If you load the playlist using "Load Playlist/Cuesheet", mp3tag will successfully resolve the path to "test.mp3", but not to the other mp3 file in the same directory.

test.zip (41.1 KB)

I get the error message
The file C:\Downloads\test\Alben\Living Stereo 60 CD Collection....\Komponisten\Saint-Saëns, Camille (1835–1921)\Symphony No.3 C minor, Op.78 »avec orgue«\Boston Symphony Orchestra · Charles Munch, Conductor · Barj Zamkochian, Organ (RCA Red Seal 1959)\01 · I. Adagio – Allegro moderato.mp3 could not be accessed.

I doubt that an absolute path with 2 .. in it is a valid one.

Also, when I try to remove that folder tree, I get the error message that for some objects the filename is too long for the recycle bin and whether I would like to remove them straight away.
So there is something wrong with the file names in respect to the DOS code page.

Your test files package is helpful to open the view to the situation.
There has been similar problems ...
/t/4623/1
/t/10690/1
... and explanations ...
https://support.microsoft.com/en-us/help/17...eeding-max-path
https://support.microsoft.com/de-de/help/17...eeding-max-path

Hmm, I gave your example a try and can confirm, ...
when loading the m3u8 playlist file, then Mp3tag cannot load the file ...

01 · I. Adagio – Allegro moderato.mp3

... but the other file will be loaded ...

test.mp3

A new test file within the m3u8 playlist file, having the relative path ...

..\..\Komponisten\Saint-Saëns, Camille (1835–1921)\Symphony No.3 C minor, Op.78 »avec orgue«\Boston Symphony Orchestra · Charles Munch, Conductor · Barj Zamkochian, Organ (RCA Red Seal 1959)\01 · I. Ad.mp3

... will be loaded too.

For such problematic case of not respecting such long path names ...
I have a Mp3tag tool defined, named as "Load this folder in Mp3tag", ...
Path: <... the path to mp3tag.exe ...>
Parameter: '/fp:"'%_folderpath%'"'

Pointing the cursor to the succesful loaded file "test.mp3" and applying the tool will load all files from the folder.

I do not know whether there is a way to implement a similar method into Mp3tag to respect such cases when loading a playlist file.

DD.20171010.1246.CEST

Hi Klaus,

many thanks for the error report. There is a limitation to 260 characters for the full file path, which in your case was only triggered by the relative file path from the m3u8 file.

I'm now canonicalizing the directory and filename parts individually so that those edge cases are prevented.

You can try it with this unofficial test version
http://download.mp3tag.de/support/C247707B...gv284csetup.exe

Kind regards
– Florian

Hi Florian

Many thanks for your work and in particular for this fix!
The test version solves the problem I described.

If it's not too complex, can you please explain what the remaining limitations are?

Best regards
Klaus

Hi Klaus,

Many thanks for testing and confirming the fix. The remaining limitations is basically a 260 characters limit for the complete path. There are some areas in Mp3tag which can handle longer paths (via a special prefix that is interpreted by some Win32 API functions), but the area which triggered this issue uses some Win32 API functions that are limited to MAX_PATH characters, where MAX_PATH is 260.

There are newer versions of those API functions, but those are only available in newer versions of Windows, e.g., Windows 8.1.

Hope you're not too often running in the limitation. I'm aware that especially when working with classical music, it's quite difficult to not exceed this limit.

Kind regards
– Florian

P.S. The fix is now included in the current Development Build Mp3tag v2.84d.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.