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
Unloadable image detection is slow with Imlib2 ≥ 1.6 #505
Comments
It's possible, but I'd rather not re-implement functionality already provided by other tools. Do you see a case where a variation on |
I think with |
Glad to hear. Closing this issue as wontfix for now. |
Hello, it seems that I'm not the only one bothered by this issue (#520 another example). |
Nice to see that others also have problems with this behavior of feh. The workaround mentioned here is unfortunately absolutely useless for me. As soon as the path or filename contains spaces, the output of find doesn't work with feh or does anyone know how to put the output of find in quotes so that feh loads the paths correctly? |
Not arguing either way, but |
Thank you very much for this solution, it works for me too. I had spent over 2 hours on the internet to find a working solution the last days and didn't find one, but was close to it, only the -0 at xargs was missing. I would suggest to extend the manual to include the info, so that others don't have to search for an own solution. Anyway, I am satisfied with it.
This catch only supported formats and files smaller than 30 MB. |
One disadvantage of this method I noticed now. the processing of the paths is done in chunks. If the paths are long enough and there are enough images, only a part of all paths is passed to feh. If you end feh with q, feh starts immediately again with the next chunk until all chunks are passed to feh. You can see this behaviour already with less than 1000 images, if the paths are long enough. |
Apparently, Imlib2 1.6 (released in nov 2019) introduced major changes in its image loader. It has been reported on IRC that feh takes much longer to dismiss unloadable files as unloadable with Imlib 2 1.6 compared to 1.5. So my previous assumption (feh doesn't get stuck on unloadable files for long when not using |
Judging from the Upstream Issue, it might be an Imlib2 regression and unrelated to feh. Let's see how it turns out and whether feh needs a workaround in the meantime. |
I have this issue and feh is borderline unusable when opening a dir that has mp4 files and cycling through them. imlib2 v1.6.1, feh v3.3, ubuntu In the meantime I'll hunt down and install an older imlib2 version, but it would be nice for it to be fixed, even if this isn't exactly your problem. |
You're right, I forgot about this issue. Thank you for reminding me! It doesn't look like Imlib2 is making progress, so I'm making feh check whehter a file looks like an image before attempting to load it via Imlib2. The check is based on magic bytes, so it should be fairly reliable. It will be possible to override it using an environment variable. |
That's honestly a serious bummer - for people who want an older version, i got mine from debian's website (missing dep here), and it makes it so much more responsive.
And thank you for making such a nice project. |
Sun, 06 Dec 2020 08:34:15 +0100 Daniel Friesel <derf+feh@finalrewind.org> * Release v3.6.1 * Fix excessive memory consumption when showing long-running slideshows with thousands to tens of thousands of images and feh has been compiled with exif=1 (see derf/feh#553) * Fix memory leak when showing long-running slideshows with relatively few images and feh has been compiled with exif=1 (ibid.) * Fix memory leak when reloading an image and feh has been compiled with exif=1 * Fix memory leak in --draw-exif * Fix memory leak when reloading HTTP files with --no-conversion-cache Mon, 30 Nov 2020 19:44:47 +0100 Daniel Friesel <derf+feh@finalrewind.org> * Release v3.6 * Add flip and rotate options to the menu * Improve unloadable image detection time (e.g. for large video files) by checking a file's header before passing it to Imlib2. For rarely used image formats, there is a very small chance that an image which could be loaded by feh 3.5 is reported as unloadable by feh 3.6 due to this change. Set FEH_SKIP_MAGIC=1 to bypass the header check in this case. See <https://phab.enlightenment.org/T8739> and <derf/feh#505> for details.
When I run
feh Folder_name
and iterate over the images, feh is stuck on large .mp4 files. It logs:And feh may just not respond to any commands.
Is it possible to add command line arguments:
All optional
The text was updated successfully, but these errors were encountered: