File Export -> m3u / m3u8 should export as "SFN"

[therube]

File Export -> m3u / m3u8 should export as "SFN"*

"SFN"*, being as drag&drop currently works, shortening names when needed.



is m3u LIMITED to a fullfilename (a "line") LEN <= 260 chars ?
a media player is LIMITED to a fullfilename LEN <= 260 chars ?
many Windows dialog boxes (File | Open) are LIMITED to a fullfilename LEN <= 260 chars


- on Export to .m3u8, should "LFN" be exported at "SFN" - as needed?
(& as is done with drag&drop)


as it is, any fullfilename > 260 chars in a .m3u / .m3u8 is simply ignored
(by media players, best i can tell. ignored at best, breaking the the playlist in other cases.)


Wiki: M3U

[void]

There's no real specification on the maximum filename length for m3u files.

The next alpha update will use short names as I couldn't find a media player that supported very long filenames from m3u files.
Short names will only be used if the very long filename exceeds 259 characters and you enable shell_short_path (enabled by default).
If you also enable shell_max_path (disabled by default) and the short path also exceeds 259, then the filename is ignored.

Thank you for the suggestion.

[therube]

Oh, & will this then automatically be picked up by ES (ES -export-m3u8) ?

[void]

Only Everything at this stage.
I will put this on the TODO list for ES.

[therube]

I suppose that something like -double-quote also might also need to be taken into consideration?
Like if adding the 2 quotes might happen to change a fullfilename from SFN to LFN, at which point you then might want to shorten it again (to 8.3) - maybe?

[therube]

If you also enable shell_max_path and the short path also exceeds 259, then the filename is ignored.

Explain ignored?
Ignored, as in it will not be shortened?

If that is so, aren't you then apt to still run into issues "outside of Windows" itself?

To enable the new long path behavior per application, two conditions must be met. A registry value must be set, and the application manifest must include the longPathAware element.
...
Understand that enabling this registry setting will only affect applications that have been modified to take advantage of the new feature. Developers must declare their apps to be long path aware, as outlined in the application manifest settings...

https://learn.microsoft.com/en-us/windo ... n?tabs=cmd

So similar to /LARGEADDRESSAWARE (for a 32-bit program to be able to use >2GB of RAM), longPathAware needs to specifically be "enabled" in a particular program for it to work (in that program). So if IranView or VLC or mpv or ... have not specifically enabled it...

[void]

I suppose that something like -double-quote also might also need to be taken into consideration?

ES will not count the double quotes.
Third party programs should remove the double quotes.
Otherwise, the filename would be invalid anyway..

If you also enable shell_max_path and the short path also exceeds 259, then the filename is ignored.

Explain ignored?
Ignored, as in it will not be shortened?

When enabled, LFNs will not be added to the m3u file.
shell_max_path is disabled by default.
You may wish to enable this if your media player crashes when opening LFNs.

If that is so, aren't you then apt to still run into issues "outside of Windows" itself?

Most modern programs will handle really long filenames fine.
Some will fail to open the file.
Some will crash.

To enable the new long path behavior per application, two conditions must be met. A registry value must be set, and the application manifest must include the longPathAware element.

This only applies to low level win32 APIs.
The Windows shell is still mostly limited to 259 characters.

Windows Explorer calls the shell with paths longer than 259 characters.
Everything will do the same by default. (shell_max_path)

[void]

Everything 1.5.0.1384a will now use short paths in m3u/m3u8 files when the filename exceed 259 characters.

To disable this functionality and always export using the long filename:

• In Everything 1.5, from the Tools menu, click Options.
• Click the Advanced tab on the left.
• To the right of Show settings containing, search for:
  shell
• Select: shell_max_path
• Set the value to: false
• Click OK.

[therube]

i exported <search> path:len:>252 (252 is a "magic number" for some programs) to .m3u8
& a handful of files failed to translate from lfn (Full Path > 259 chars) to sfn

Code: Select all

< 260 chars=OK
H:\H\HHHH\HH\HHHHHH~1\HHHH-231_HHH  HHHHH HHHHHHH - HHHH   HHH HHHHHHH  HHH HHHH HHHHH, [HHH HHH-033], HHH-025 HHHHH HHHHHH, HHHHH HHHHH, HHHH HHH-027, HHH-037 HHH [HHH HHHH-134H HHHHH HHHHHH   HHHHHHH] HHHHHHHHHHH-H95440989~HHHHHHH417 (HHHH 423, 1.56.16).mp4
^---OK             ^---sfn part

v---below sorted in line length order (source .m3u was sorted ascii)
v---too long, no SFN in here at all, not path, not name
H:\HHH\HHHHHHH.HHH\HHH\HHH HHH HHHHHH'H HHHHHHHH       (360H, H HHHH .HH., HHHHHHHHHH HHHH.2.HHHH HHHHHHHHH) - HHHHHHH.HHH - [HHHHHHHHHHH] HHHHHHHHHHHHH HHHHHHHH HHHHH HHHHHH HHH (HHH 1972, HHHHHHHH, HHHHH HHHHHH, HHHH HHHHHHH) (360)-H2[HHHHHH4HHHH].480H-661.mp4
H:\HHH\HHHHHHH.HHH\HHH\HHH HHHHHH HHHH H 24 H-HHHHH HHHHH       [HHH] (HHH H2 - HHHHHHH HH 16.9, HH H HHHH, HHHH 2.HHH HHHH HHHH - HHHHHHH HHHH, HHHHHHH, HHHHHHHHHH) - HHHHHHH.HHH - [H45HH9HHH2H] HHHHHH HHHH (1981,HHH,HHHHHHH HHH HHH,HHHHHHHH HHH) (360)   HHHHH.mp4
H:\HHH\HHHHHHH.HHH\H\HHHHHHH HH HHHH       (HHHHH) - HHHH HH HHH HHHHH, HHH HHHHHHH, HHHH HH HHH HHH HHHH, HHH, HHHHHHH HH HHH HHHHH HHHH, HHHHHHHHHHHHH HHHHH HHHHHHH, HHHHHHH.HHH - [HHH8HHHH3HH] HHHHHHHH HHHHHHHHHH (8H 1970H HHHHHH HHH HHHHHH HHHHH) (360)   HHHHH.mp4
H:\HHH\HHHHHHH.HHH\H\HHHHHHHH HHHHHHHHHHHH -   +H[HH]   HHH HHHH HHH HHHHHHHH HüHHH   HHHHHHH HHHHHH (HHHHH HH HHHHHHH HHH - HHHHHH HH HHH, HHHH HHHHHH) - HHHHHHH.HHH - [HHHHHHHHHH3] HHHHHH HHHHHHHH (1980,HHHHHH,HHHHHHHH HHHHH,HHHH HHHH,HHHHH HHHHHH) (360)   HHHHH.mp4
                                                                               ^---unicode char, mangled though (i suspect) [regardless]
H:\HHH\HHHHHHHHHH\HHHH\HHHHH\HHHHHHHHH HHHHHHH - HHHHHHH HHHHHH   (HHHH HHHHHH  HHHHHH HHHH  HHHHHHH HHHHHHHH) - [HH1] HHHHHHH.HHH - [HHHHHHHHHHH] HHHHHHH HHHHHH (480)=H3-233[9HH43HH5087, HHHHH HHHHH HHHHH HHHH HHHHHH HHHHHH 13 HHHHH HHH HHHHHHH HHHHHHH HHHHHHH]~H.360H.HHH-225.mp4

other then noted, nothing special, simply "text", ( ) [ ] \ & +
that ~ in the last filename is a literal ~
none of the noted chars are irregular in my filenames (including a physical ~)

so out of ~1400 (see, there's that character, again) files that i picked,
only the above 5 failed to translate (from lfn to sfn), for whatever reason?

4 or 5 path parts, so nothing special
combinations of both ( ) & [ ] or multiples of each, nothing special


---

#'s below 38, 39, 65..., simply relate to relative # position of particular files in the .m3u (playlist)
94..98 are (the final 5 files in the list & are) LFN's that failed to play, everywhere

mpc-be
- not ADVANCE (Next) PAST 38.RCT
- if /moved/ to 39., it then kept going
- if REVERSED from 39 to 38 to 37, that did work - oddly ?
- 65. 254.LFN
- failed, simply skipped over - oh, maybe it is not a real file ? (in which, OK)
HEH, not real
- 94..98 simply show nothing (no name [nor length, obviously] in Playlist

MPUI/MPlayer
- no issue with 38.
- 65 stops with "unable to play media"
- 93 last played file, obviously
- 94..98 do not even turn up in its' Playlist (as if they weren't there to begin with)

VLC
- no issue with 38.
- 65 pops up a "can't play" message instead of (automatically) skipping over
- vlc gathers Length as the playlist loads (mpc, only as each song is actually accessed)
- 94..98 /does/ show FULL File Name (per .m3u), but no Length (obviously)
& displays message "Your input can't be opened:" for the LFN names

mpv
- simply skips over all "non-playable"
so plays all until it gets to 94 (the 1st LFN), where it simply exits
(presumably ? also automatically trying the final 4 LFN, /then/ exits)

mpv.net
- no issue with 38.
- 65, simply skips over, automatically
- 94, stops (after presumably also have tried 95..98, LFN's)
- 'Recent' shows the last played file to be 93. (final SFN)

mpc-be
- 38. oh, so that's what's going on - mpc* "skip" (aka Skip Fwd aka Next),
skips to Next Chapter - if chapter markers are found (or, file if no chapters),
& 38 has them (chapters) [so that it was not advancing to the next file when i hit "Next"]
- 94..98 does show FULL Name but then marks Length as "Invalid" for each of
the files & stops (final file, 98)


mpc* seem slower advancing to next file (perhaps cause the gather of Length ?)
(heh, i forgot about [Everything's ] 'Full Path Length' - much easier & quicker
then farting around with editors & other methods )

[therube]

File Export -> m3u / m3u8 should export as "SFN"*

File Export works (mostly, see above).

But ES.exe -export-m3u (-export-m3u8) does not, so some sort of "-sfn" switch would be nice.

[void]

only the above 5 failed to translate (from lfn to sfn), for whatever reason?

Check if some of the LFNs don't have a SFN, or the SFN is still really long..

audio: path:len:>259 add-column:a;short-full-path a:=LEN($shortfullpath:)

Is any line in your exported m3u over 259 characters?
-Everything should not be exporting any line over 259 characters.

One thing I have noticed is Everything will only shorten filenames if they are over 259 wide-characters.
The filenames exported to the m3u are either ANSI or UTF8.
They might be more than 259 UTF-8 characters! (while the number of wide-characters would be less than or equal to 259)

Filenames are only omitted if they are over 259 wide-characters.



Thanks for testing all the media players.
It's interesting that a lot of them have issues with LFNs.

Would it be a better to just not export LFNs at all?

Windows Media player has no issue with LFNs.
Maybe I am missing something?

But ES.exe -export-m3u (-export-m3u8) does not, so some sort of "-sfn" switch would be nice.

A -sfn switch is on my TODO list.

[therube]

Is any line in your exported m3u over 259 characters?
-Everything should not be exporting any line over 259 characters.

Yes. 262, 265, 268, 269, 281.
269 had a unicode char. Not sure offhand if it was wide?

Would it be a better to just not export LFNs at all?

No.
It helps to point out issues.
You might use a .m3u formatted file for other purposes where you would want to see all files & not only files that may happen to load into a player.

[void]

Are you exporting as m3u or m3u8?

Please send the lines with a length of 262, 265, 268, 269 and 281.
This will help with my understanding of the issue.

All your media players are most likely going to convert the ANSI/UTF-8 text to wide char internally.
These media players could be having issues with the ANSI/UTF-8 text being longer than 259 bytes.
I think I am going to need to cap the ANSI/UTF-8 length to 259 bytes instead of 259 wide characters.

[therube]

Check if some of the LFNs don't have a SFN, or the SFN is still really long..

This. [more later.]

Code: Select all

c:\
255-longest NAME
  3=VOLUME:\
  1-for good luck (i think that the "EOL" or something or the other)
259=longest short Full Path

259>=LFN

so if Name = 255
if > 1 path part (more then c:/)
Name must be SFN(8.3)
& for every path parts+name where where len>259, name &/or path parts must be SFN(8.3) to make it work...

in most cases, what i am seeing, at the least the Name is SFN(8.3)
though in far less cases, name is not 8.3, & in those cases it /seems/ that at least /some/ path parts are 8.3

oh, & i was going about it wrong, wasn't i
i was looking for big, where i should have been looking for small (nothing, 0)
& yes, they have no SFN


HEH.
remember how i hadn't happen to come across all my "deadwood" files - yet, heh.
guess what, i just did - found the rest of them .

Short Full Name="", A=0, i.e., no SFN, no Len - the files do not exist - deadwood, heh.

OK, so that was the issue. you were SFN'ing LFN's that no longer existed, so there was no SFN to shorten them to.
And, now Purge'd, I have no SFN > 156 & no Full Path > 408 [where: path:len:>259] .

As far as "wide", yes some file names are "wide" (some file name characters are wide), but that wasn't the issue.

And... with all that, File Export -> m3u8 is A-OK, none > 259 .



deadwood's, now PURGED:
(So as it was, I unknowingly happened upon these non-existent files, & they happened to be written to the .m3u/.m3u8, & with that, I happened to "see" them - even though they were not.)