Dear Maintainer,

The thumbnail size control in the PcmanFM preferences is somewhat
dysfunctional. There are two things at play:

1. thumbnailing
2. caching of thumbnails

But that control tries to control both, and does so in a weird and very non-
linear way. It's labeled as controlling thumbnail generation, but it's primary
function which it actually does well, is controlling caching of thumbnails.
Anything under the size you set it won't generate thumbnails for the cache.
Very sensible if that's all it did.

Firstly, it seems like all images should get thumbnails. So that shouldn't be
on the table. Unfortunately it is with this control.

At the larger settings, it allows all images regardless of size to be
thumbnailed but very few to be cached, so it's actually acting like that
control should actually say "Do not cache thumbnails above this size:" because
that's all it does at any setting over about 4096 kb. In fact it does control
caching at all settings, and will cache the thumbnails IF they get generated in
the first place.

Below 4096 kb all the way down to the default 2048 kb setting and past that on
down to around under 100 kb somewhere, it's completely wonky about thumbnailing
images, at any setting it arbitrarily refuses to thumbnail some images, without
regard to size or format or anything else, just refuses to thumbnail random
images. Change the size a bit and you get back thumbnails for some, while
losing them for others, it's completely random. And obviously if it doesn't get
thumbnailed in the first place, it doesn't get cached either. I used several
different folders with multiple image formats and sizes (all supported and will
work at the higher settings), some 75-100 images per folder.

Down at the lower levels that random behavior slowly stops finally ceasing
around 64 kb, but now it stops thumbnailing specifically anything below that
number and you can no longer get thumbnails of smaller files, just a generic
icon.

So either way, you can't optimize behavior, at 4096 and above you finally get
thumbnails of all files, but very little caching, so files full of large pics
have to re-thumbnail every time you go to that directory. This is tolerable at
least, but if you have a lot of photos/artwork they have to re-thumbnail every
time you return to that directory so it slows down and uses a lot of cpu.

At 64 kb and below, you get lots of caching, so secondary openings of those
directories are lightning quick, but no thumbnailing of the smaller images,
everything should thumbnail at least, the control should only control caching.
Obviously 64 kb is really too small a setting, I just wanted to be thorough in
testing, so I tested the control from 5120 kb down going in 128 kb increments,
and then at 64, 32, 16, 8 kb. I believe the factory setting of 2048 is about
right but it simply won't thumbnail some images, whereas going up to 4096 and
above they do thumbnail.

Thanks for your time and sorry for the long-winded explanation, i've never
reported a bug before so forgive me if this is not the proper protocol.
~greenjeans

In my report I made a typo, this is what I said:

"Do not cache thumbnails above this size:"

That should actually read:

"Do not cache thumbnails below this size:"

I have since gathered some more data and found numerous reports of this, and one user seems to have found the commit that caused it:

https://github.com/lxde/libfm/commit/00120b795a811ae70db89dde5021461658f2880f

I have since made myself a band-aid consisting of a python script that runs once after bootup and properly caches all thumbnails over a given size, with a menu entry to run it during session if a lot of image files are added. But it is a band-aid, not a fix. I had intended to fix it myself, but then the GTK3 version came out and I think it would be smarter for me to try and patch that version.

I understand what they were trying to do and there is some merit in it, at least for edge cases, but the implementation was wrong.

~greenjeans

Sent with [Proton Mail](https://proton.me/mail/home) secure email.