Sagnac / streamsave

mpv script aimed at saving live streams and clipping online videos without encoding.
94 stars 4 forks source link

Filename requires truncating under long paths #13

Closed Sagnac closed 9 months ago

Sagnac commented 10 months ago

When the URL's very long, streamsave seems to fail to create the file, probably due to an OS path length error, should prob be trunc-ed with room to account for the file extension.

Originally posted by @brian6932 in https://github.com/Sagnac/streamsave/issues/12#issuecomment-1881477019

Sagnac commented 10 months ago

Some notes:

On Windows the limit is 259 characters without considering the null character and it looks like this would be the limiting case when considering most popular operating systems. Truncating is simple enough, but there'd have to also be some sort of check on the save directory path length as well where'd we'd probably want to emit a warning for long enough save_directory paths and throw an error if that's too long by itself.

Since UTF-8 uses an encoding scheme where the length of a character can vary there's also an additional complication in measuring the length of the string itself since this limit seems to be in actual characters (and not bytes) and older versions of Lua (< 5.3) don't seem to have utf8.len (the length operator # and string.len measure bytes).

A straightforward approach would be to simply measure the string in bytes, emit a warning if save_directory is > 128, and throw an error if it's > 251 (the truncation limit should be around 8: 4 for the extension with the period, 3 for the hyphen + 2 digits under incrementation, and a minimum of 1 for the title.

I'm sure there's some standard way of dealing with this, but I'm not familiar with the methods so this'll require some brief research. But ultimately this should be relatively simple to fix.

brian6932 commented 10 months ago

For the record, I have Enable Win32 long paths/LongPathsEnabled enabled, and saving with the long URI still exceeded the limit, it wasn't 37k characters long, so I think that it's very likely mpv's responsible for enforcing the limit instead of the system.

Sagnac commented 10 months ago

Which version of mpv are you using? These two commits were just merged a few weeks ago:

https://github.com/mpv-player/mpv/commit/c09245cdf2491211f3e0bfe47f28cc0e0a2e05c8

https://github.com/mpv-player/mpv/commit/9565675488c51133e85627e5e610bf631eca6289

brian6932 commented 10 months ago

https://github.com/mpv-player/mpv/commit/abc2a748

Sagnac commented 10 months ago

Hmm, shinchiro or your own builds? He seems to have just added support for it in Windows 10 right around the time of that commit:

https://github.com/shinchiro/mpv-packaging/commit/1c534ce8c21fab0be2a394ad73decc15e015693e

in any case, when I find the time I'll test things out on my Windows machine and see if I can figure out what the limit is. Maybe for outputting files with the recorder it makes a difference. Do you remember more or less how long the path was?

brian6932 commented 10 months ago

I use this https://sourceforge.net/projects/mpv-player-windows/files/64bit-v3/ (https://github.com/brian6932/dank-scoop/blob/master/bucket/mpv-git.json)

Sagnac commented 9 months ago

I was able to reproduce the issue with older versions of mpv and I think it's a good idea to truncate long paths anyway so I've thrown up a quick fix. It's slightly more complex than usual since it needs to be robust in order to handle variable length encoding. I still need to test a few things before I merge it, but it seems to work.