Unloadable image detection is slow with Imlib2 ≥ 1.6

[zotho]

When I run feh Folder_name and iterate over the images, feh is stuck on large .mp4 files. It logs:

feh WARNING: *.mp4 - No Imlib2 loader for that file format
...

And feh may just not respond to any commands.
Is it possible to add command line arguments:

• list of extensions that can be opened
• list of extensions that can't be opened
• file size limit

All optional

[derf]

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 feh $(find Folder_name -not -name '*.mp4') wouldn't work?

[zotho]

I think with find this will work fine

[derf]

Glad to hear. Closing this issue as wontfix for now.

[mallniya]

Hello, it seems that I'm not the only one bothered by this issue (#520 another example).
Generic unix tools work (as they always do), but this is quite cumbersome to print, especially if one has many other formats in target directory. It's finite list of formats feh supports, so why just don't try to load files with unsupported format or at least has an option to?
Also there are 2 cases where unix tools are inapplicable: opening directory from UI and setting white-/blacklist through themes.
@derf, please reconsider this feature in one form or another.

[kpcee]

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?

[Ferada]

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 find . -print0 | xargs -0 feh will deal with all paths.

[kpcee]

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.

find . -type f -iregex ".*\.\(jpg\|jpeg|bmp|png|pnm|tiff|gif\)$" -size -30M -print0 | xargs -0 feh

This catch only supported formats and files smaller than 30 MB.

[kpcee]

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.

[derf]

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 --magick-timeout) was wrong. I can reproduce the issue now, but hope that I can fix it by changing the way feh interacts with Imlib2. I'll update the title accordingly, as I assume that this caused the issue for you as well, @zotho.

[derf]

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.

[eepykate]

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.

[derf]

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.

[eepykate]

It doesn't look like Imlib2 is making progress

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.

Thank you for reminding me!

And thank you for making such a nice project.