Sorry for reviving an old discussion, but apparently there is no good solution on the horizon and one of the main arguments from ten years ago does not hold true anymore I'd say.
Currently Opus only caches thumbnails that it itself has created. When Windows supplies the thumbnail, Opus does not cache it. Unfortunately under a number of circumstances (e.g. Onedrive or Samba shares) Windows does not cache them either, meaning the SLOWEST drives to thumbnail are not cached by any of the two players.
I understand that in earlier discussions the "We don't want to waste space to store twice" argument was valid, but storage these days is not that limited anymore while general filesizes go up all the time and now thumbnails are really tiny in relation to the other data stored.
Therefore I would kindly ask for a future version of Opus to optionally allow storing of externally generated thumbnails, especially on networked drives, in the Opus thumbnail cache.
Currently it is simply awful to deal with PDF or CBR/X thumbnails (to name two common ones) because, as said above, the slowest drives get not speedup at all and any directory traversal is slow as molasses because they even do not stay in memory.
There is no indication that the Windows behaviour for this will change in the future and it looks like it is a deliberate choice, not necessity, not to cache for Opus, so... pretty please?
Just pushing this request up again because today I was re-organizing a LOT of .cbr files on a NAS and due to the nature of packed RAR thumbnailing is slow (Opus needs to go through the large file) and thumbnails were not cached... I am considering to reconvert all to cbz simply because they thumbnail a LOT faster. A cache mechanism though would be great. Especially because my NAS really is getting worked out due to the fact that I am running the standard 4 thumbnail threads, now four processes are parsing through four large RARs in parallel. Lots of head moves, takes lots of time.
Okay, maybe I need to rephrase the request. I just turned on cbr thumbnails in "Dark Thumbs". I had them switched off quite a while ago, hoping that DOpus internal thumbnailing would be cached. It does not.
Current situation:
Dark Thumbs Thumbnails on a NAS for .CBR files are cached by Windows. Survives Reboots.
DOpus Thumbnails for the same files are NOT cached. All cache settings are on. I even cleared the cache to start with a clean slate - those thumbnails are not saved.
Any ideas what I am doing wrong here? (This does not invalidate the request to cache Windows-provided thumbnails, we are just on a 2nd track here).
The RARs are probably using solid compression, if their thumbnails take a log longer than similar Zips to generate. Recompressing them as non-solid should fix that.
Thumbnails on network drives which were generated via Windows are cached here, at least. (Testing with some video files on a Windows server's share, they re-appear instantly in a new window after the initial generation.)
On my machine with 13.6.10 (but at least for several weeks if not months), thumbnails for archive files, especially *.cbz and *cbz, were not cached at all, despite being turned on in Preferences. Creation was just REALLY fast on my SSD and I never noticed. I repeatedly cleared the cache and it stays at 0 MB used when I traverse no other folders, just those with CBZ and CBR.
Once I went into settings, turned "Cache thumbnails for images located on: Archive Files" OFF and then ON again, Opus has started caching those thumbnails. I see the MB number going up when I hit my CBR folders.
When I enter the directory again on the NAS, Thumbnails are created again, although having been written to the cache. They are even coming up in groups of four, as I am running four threads.
So basically there is some logic error somewhere with archive files where the cache is ignored when going back into the directory plus the oddity that they were not even created although the flag was shown as set (could maybe be a hidden 12->13 upgrade preference thingie?)
Idea - could it be that you storing a thumbnail but for the wrong property? So not for the archive itself but for the file in the archive? So that when you rehit the archive, Opus still has to look inside the archive for the filename of the thumbnail? (The archive might be named DonaldDuck90.cbr, but the image is 0000.jpg and the cached thumbnail is not associated directly with DonaldDuck90.cbr but with DonaldDuck90.cbr/0000.jpg which you then would access to see if the cache is still valid)?