Thumbnails for Archives are not cached

The thumbnails for archives are not cached, despite being set in the Preferences.

I have recorded a clip showing that behaviour. I used ZIPs (CBZ) and RARs in the same directory, as ZIPs thumbnail a lot faster. When I leave the directory and jump back again, it thumbnails from the start. You can watch the 4-thread behavious pretty nicely.

Enten Edition 2024-06-14 15-49-55.mp4

It's definitely working here.

Do you have something installed which makes CBR thumbnails for File Explorer? If so I suspect it might be this:

  • The RARs are created with solid compression. (That would explain why generating thumbnails for them is so slow. The entire archive may have to be decompressed to decode any file within it.)

  • Opus itself isn't generating the thumbnails, as it won't do so with solid archives (since solid archives are so slow to read small files from).

  • Since Opus doesn't generate it, it asks the Windows Shell if it can provide a thumbnail. (The installed thumbnailer for CBR files may go ahead even with a solid archive, depending on how it's written.)

  • Since the thumbnail comes from the shell, Opus won't cache it, since the shell is supposed to cache it itself.

Another possibility is that the timestamp or size of the archive is changing. (It's rare, but we've seen at least one NAS in the past which bumped the modified timestamp on files every time they were opened for reading.)

Yeah, Darkthumbs is installed but im my Video I have RARs, not CBRs, to show the difference. These are clearly Opus Thumbnails (Folder with a Zipper!). Darkthumbs is not switched on for RARs. Also, when I go to Windows Explorer, thumbnails are created AND CACHED in Windows Explorer (for the CBRs, when I rename to RAR they do not get thumbnails). The Windows attributes are not changing at all. I only get UP on dir then back down to the dir and thumbnails are recreated.
So I switch off Dark Thumbs and Windows does NOT show any thumbnails. Opus still creates them. So this proves again that it is Opus, not Darkthumbs.
When I open Preferences "File Display Mode - Thumbnails - Folders" and switch "Display thumbnails for folders" off, immediately the thumbnails vanish. "Use Windows folder thumbnails" is off. "Include images of folder contents" is ALSO off, but this has no effect, it still shows thumbs! When I switch this (Include images...), it again starts recreating all the thumbnails.
The thumbnail cache is on for everything, currently uses 646 MB if 1000 which sounds unreasonably large too.
When I check "C:\Users\boris\AppData\Local\GPSoftware\Directory Opus\Thumbnail Cache" I can see many .db files. Looking into these I can see the filenames of the files that have thumbnails. So they are in the cache. But for whatever reason, Opus still decides to recreate the thumbnails.

I am at my wits end. Thumbnails are generated BY OPUS and cached BY OPUS. When entering the directory again, Opus simply ignores the cache and starts fresh.

Thanks, Boris

Okay, one more even stranger observation:

I clear the thumbnail cache. The directory is empty.
I let Opus create 168 Thumbnails for 84 RARs and 84 CBZs.
This creates 32 files in the database. I have zipped them up as "First Pass"
I exit and reenter the directory. Thumbnails are recreated. All Thumbnail db files are touched, but their size stays the same. I have zipped them up as "Second Pass".
So far I have only the Source pane open. I click on "Display this folder in the other file display", opening the Destination. Opus, with the thumbnails VISIBLE in the source pane, starts creating thumbnails AGAIN. (I have zipped the data base as "Third Pass".
Looking at the database, the files look identical between passes (at least by a cursory CRC check) and the timestamps suggest that the thumbnail creation takes the same amount of time at each of the three passes.
Clearly Opus when seeing the directory again simply ignores the cache - even when it is open in the other window!
Now, when both panes show the thumbnails of the same directory and I click on "Display in other...", no matter which of the two, thumbnails are created AGAIN for the Window.
Pushing Refresh/F5 - you can guess it, Thumbnails are created AGAIN.
Each time I check the timestamps of the database I see no speedup at all.

First Pass.zip (8.5 MB)
Second Pass.zip (8.5 MB)

I have investigated further and everything I do points to a bug in Opus - sorry!

  • Some of the files had alternative data streams. I have eliminated those - no change.
  • I have set files on the NAS itself to read only even for the admin - no change.
  • I have fully removed Dark Thumbs and rebooted - no change.
  • I have checked the file properties, the "last accessed" is updated, the "last modified" not.
  • Updated to 13.6.12 - no change, but that was expected as this was not acknowledge yet as a bug.

As in the video above, simply asking destination to display the same folder as source will lead to thumbnail regeneration, so clearly there is something broken in the logic to decide whether to used the cached thumbnail or re-do it even though Opus had one created internally a minute ago in the same instance and nothing has touched the file since.

We've got a handle on this now. The cache is actually being used, it's just that the archives are being opened before it's used, and on a network drive this can be slow enough as to make it look like the thumbs aren't cached at all. We'll have a fix for this in the 13.7.1.

2 Likes

FANTASTIC. I was really questioning my sanity on this one. Good to know that it will be fixed.

THANK YOU! 13.7.1. is now exponentially faster for me!!!

2 Likes

Does this close out your other thread as well?

1 Like

Thank you for picking up that other discussion - I totally forgot about that because I though OneDrive is an unsolvable problem. It looks like it NEARLY works very well now. When I enter a subdirectory that is on the Onedrive and it has been cached earlier, it is lightning fast. I checked by unplugging network connections, it shows thumbnails even when the files are "cloud only".

The only optimization I could suggest is that when thumbnailing a slow drive, you do not throw ALL available threads on it. If the source pane is thumbnailing a OneDrive folder and I go to any other folder in the destination pane (or the other way around), because all, in my case 4, threads of the thumbnailer are waiting for the OneDrive client, it can take up to three seconds before one thread gets free and then starts showing SOME of my already cached thumbnail, until by bad luck all threads are busy on the Onedrive again. A quick and easy fix could be that one thread stays reserved for the "other" pane so it stays responsive?

Also, when I have content thumbnails on for folders, it takes a very long time with OneDrive to get these apparently because collecting all those TNs is stalling all the time. This would be a non-issue if it would not block the other pane. (And OneDrive currently is PAINFULLY slow to return a single PDF thumbnail)

But I am very happy overall! Once Thumbnails have been created, they are now shown lighting fast with NAS and OneDrive, both personal and business.

1 Like