-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract frames from videos in mounted paths longer than 256 chars on Windows #1809
Comments
The cause is the long path indeed. Just processed 2 videos in a local long path without special chars. The one with 256 chars in the full path had video thumbs created, while the one with 257 chars in the path had not. |
I know NTFS has a max path length, but not sure why java (HashTask, ParsingTask, HexViewer...) and imagemagick are able to read the files while mplayer isn't... |
Mplayer verbose output on the 2 videos:
|
I'll try the same workaround used on #1170 to pass the paths to mplayer. |
Just tested here and got the same error. |
Looking at MPlayer code, there are a few places that check the path length against a constant maximum value, and then show the message we are getting: #define MSGTR_FilenameTooLong "Filename is too long, can not load file or directory specific config files\n"
(...)
if (strlen(file) > PATH_MAX - 14) {
mp_msg(MSGT_CPLAYER, MSGL_WARN, MSGTR_FilenameTooLong);
return;
} The problem is that EDIT: It seems FFmpeg also have this message, and similar checks. |
I see... It didn't work for me too. If some day mplayer removes this when passing the path to java ProcessBuilder because, on Windows, it messes up the quotes (or back slashes), if I remember from #1170. |
So, I'm closing this as won't fix for now... |
A possible (non-ideal) workaround would be copying the file in IPED's Temp folder (if full path has more than 256 chars) and then passing it to MPlayer, but I am not sure if it is worth the effort, as this is not a usual scenario. |
Just as example for reference, here is the command used on #1170 before replacing it for a File.delete(): |
Hum, this should work... I'll give it a try! |
As expected, it worked! Thanks @tc-wleite for the suggestion! I think it is worth, since the change is simple and many users use IPED to process cloud warrant returns, where those long paths are pretty common. So I'll reopen and send a PR, if you could take a quick look at the code changes in |
I'm re-tagging this as enhancement since I didn't expect any module to work on file paths longer than 256 chars and because this is a clear restriction of mplayer, not a dependency bug. |
Just tried to process an iCloud backup in a network share and I noticed no video thumbs were generated, although the videos play fine if double clicked from IPED UI and are show fine into HexViewer. Additionally, thumbs of image files were generated fine, including external ones like SVG which uses imagemagick external conversion. So I think the long paths, longer than 256 chars, perhaps are not a problem, because files can be read. But maybe they are an issue for mplayer or there is a possible issue with the mplayer command line, not sure...
The text was updated successfully, but these errors were encountered: