Thumbs won't update (but do in ::Fresh)

[Malarki]

XY v24.90.0117 in Windows 10 x64 Pro.

I copied some .jpg pictures to a new folder, and thumbs were created ok. I used another tool to rotate and crop them, but the thumbs stayed the same ie. now wrong.

Note that this is while "Cache thumbnails on disk" is disabled. In fact in Configuration F9 | Preview | Thumbnails the only items enabled are "Align to bottom" and "Show caption".

None of the following helped - XY still always finds or creates the wrong old thumbnails for these pictures:
Tried Views | Caches | Refresh Thumbnails.
Tried Configuration F9 | Thumbnails | Enabled and Disabled "Cache thumbnails on disk" with default path "\Thumbnails". [note that regardless of this setting, "echo get("thumbs_cache");" returns nothing AND dbit files show up in the cache folder]
Tried Configuration F9 | Thumbnails | Clear the cache path - and can see that the cache folder is empty.
Cleared the thumbnail cache folder using Windows Explorer.

And with "Cache thumbnails on disk" still disabled:

If I move the picture files out of their folder then back in, when they return the old obsolete thumbnail is shown for them. This is also true if I delete the picture files; clear the cache; and then Restore the files from the Recycle Bin. Changing the name of the picture folder doesn't help - old thumbnail still shown. Copying these pix to another folder doesn't help - old thumbnails still shown there too.

And all other things I can think of don't work either eg enabling and disabling auto-rotates (had been confused by that a year ago).

A system reboot doesn't help - XY somehow still finds the old thumbnails (I thought this would fix it if they're kept in memory only).

==> BUT - A ::fresh instance works fine, as does a newly downloaded unmodified XY, until I replace its stock xyplorer.ini file with mine. Then the problem recurs and somehow XY finds the old thumbnails!

So I suppose that something in my XYplorer.ini file is causing XY to permanently remember thumbs even without disk cache specified; but looking through all thumb-related settings doesn't show any likely candidates.

I rarely use thumbnails so can only guess that this started happening within the last 6 months.

Any ideas?

[jupe]

FYI that echo cmd will only produce output if you are in a active thumbnail view listing. If you disable the XY thumbs cache, the windows cache takes over in some situations. In fresh the XY cache is enabled by default.
Try View | Caches | Refresh Thumbnails, maybe even after temp enabling it if necessary.

[Malarki]

Thanks; I'm very fuzzy on the caching mechanisms.

I've found the problem by comparing xyplorer.ini files saved from way back. Looks like months ago in Configuration | Thumbnails I changed to Quality "Fast". Setting Quality to anything except "Fast" seems to fix things.

So it's a bug, apparently, because these are vanilla JPG files. Maybe you can move this thread there? If not I can copy it myself; if it matters where it's reported.

[jupe]

Are you on Windows 7?

[Malarki]

No - XY v24.90.0117 in Windows 10 x64 Pro.

[jupe]

Just to be sure, you are saying you can make the issue re-appear now, on demand by switching to Fast?

Anyway, just leave this post here for now, Don will see it.

[Malarki]

Yes, it's repeatable for me. Changing nothing else, if I select Quality "Fast" my thumbnails revert to the unrotated and uncropped versions of hours ago.
If I select any other Quality, and do a Ctl-Alt-F5 refresh, they become correct.

Come to think of it, only the pictures I had earlier rotated are affected - not all the thumbnails in the list panel. All had been cropped, so it looks like some rotation artifact is confusing the Fast presentation. No idea how that might be but that's what the evidence points to.

And btw all this time the pop-up Preview and MDBU representations were fine. Only the thumbnails were bad.

I specialize in arcane "nobody else ever had this" problems... or at least my PC does.

[jupe]

Is it possible those files have an embedded exif thumbnail?

[Malarki]

The pix in question are from a Pixel4 digital camera and I think there is an embedded thumbnail.

I've attached one of the problem camera pix, with exif geo location info altered for privacy.

Oddly, ExifTool doesn't find one. The command
exiftool -b -ThumbnailImage 1rot.jpg > MyThumb.jpg
produces an empty file "MyThumb.jpg".

But an online exif thumbnail extractor appears to find a thumb:
https://www.dcode.fr/exif-thumbnail

--> In any case, on these camera pix, switching between XY's Quality "Fast" and any other Quality eg. Crisp or Smooth gives a differently rotated thumb.

--> However, I don't have this Fast Quality issue on regular screen caps. With those all Quality levels give the same thumb.

[jupe]

Yeah so that file does have an exif thumbnail, Fast mode displays that in XY if available, other modes generate fresh thumbnails regardless, you just didn't update the exif thumbnails (or remove them) in whatever software you used to perform the modifications. Screen caps wouldn't have exif info.

[Malarki]

Well, that explains it, thanks.

I use Faststone Image Viewer for most image manipulations because it's free, fast and very powerful. It doesn't even have an option for rewriting the exif thumb after editing. OTOH both Gimp and Photoshop do have this.

While I understand the utility of Fast mode, it is something of an error trap because it is so different in nature. By not creating or updating thumbs if there is an exif thumb, it can easily show a thumb out of sync with the real image. That may account for some of the occasional and usually unresolved "thumbs not updating" complaints.

This btw isn't described in the Help; so I would never have figured it out.

So... I suggest that in the Configuration | Thumbnails | Quality dropdown, change "Fast" to "Fast (use exif thumb if avail)"

That will at least plant a clue for anybody puzzling over this in the future. And add it to the Help.

[admin]

Are you sure that "Fast" is the only quality setting that uses embedded thumbs?

[Malarki]

No, I'm not sure Fast is the only setting that uses embedded thumbs. That conclusion was simply consistent with jupe's input and the symptoms I've got. My photo app doesn't update embedded thumbs after altering the picture; Fast is showing old thumbs on those pictures; and the other Quality levels don't. Is there another explanation?

[admin]

Sounds logical to me.

[Malarki]

New info:

Apparently... Both "High Speed" and "Fast" Quality will show thumbs that are derived from an embedded thumb, when thumbs are refreshed (Ctl-Alt-F5), with disk cache enabled in the default location.

HS does this occasionally whereas Fast always does it. When the embedded thumb is out of date, the thumb shown doesn't match the actual picture file.

Oddly, these two Quality methods will sometimes show a different mismatched thumb, so I wonder if disk cache is being fully cleared when Ctl-Alt-F5 is pressed. If that's what Ctl-Alt-F5 is in fact supposed to do.

Moving the whole picture folder to another drive fixes the issue for High Speed (no obsolete thumbs shown) but not for Fast.

I attach a picture file which seems to have an obsolete embedded thumb, and illustrates the above.

As before, Quality Crisp and Quality Smooth seem to always create thumbs from the existing picture (ignoring the embedded info) so there are no mismatches. Of course those methods are slower.

I say "Apparently" above because almost all of this is speculation based on hints and experiment. I don't really know what's going on - only the symptoms on my machine when I "Refresh thumbs" (Ctl-Alt-F5).

All this is info only since it isn't a bug in XY and I will probably stick with "Crisp" Quality; though it would be nice to use High Speed.

PXL_20230416_001234719 cl.jpg