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)