Changing values on the 'folder thumbnail settings' dialog causes Opus to stop displaying thumbnails

Opus 12.32 x64, running on Windows 10 Pro 22H2.

Every time I make a change to any of the settings on the 'Folder Thumbnail Settings' dialog, Opus stops displaying thumbnails and instead displays icons. In the case of folders, it also reverts to displaying the '3D' shell icons, rather than the Opus-generated folder icons that I have actually selected.

The problem persists until I restart Opus.

Occasionally, Opus will also hang after I close the dialog.

1 Like

Which changes are you making?

Many of the changes there require re-generating all folder thumbnails. It's likely the shell thumbnail system is stalling when doing that, which will mean no further thumbnails can be generated until whatever it's stuck on completes or you restart the program. Could be the result of a bad shell extension or something else, but it's largely outside our control in any case. (We do have a change coming which will put a message in the log window when this happens, to help diagnose if it's the problem.)

So far as I can tell, changing any of the settings will do it.

After a bit more testing, it looks like it does in fact recover, albeit after a lengthy delay, so I suspect you're right in that it's stalling somewhere. There's no noticeable CPU activity, so it's not busy-waiting.

Interestingly, it kills all thumbnails - not just those for folders, which are presumably the only ones that would have to be regenerated.

All the thumbnail threads are probably stuck waiting for one of the folders, and won't process further thumbnail requests until those complete. We'll handle this a bit better in the future, by allowing some to continue if it looks like the shell thumbnails have stalled.

(We have to avoid asking the shell for more than one folder thumbnail at a time or it can go wrong, due to one of many new bugs in Windows. :frowning: )

That figures :frowning: I'm refusing to 'upgrade' to Windows 11. 10's bad enough!

On a semi-related note, is it possible to selectively disable folder borders? What I would like to do is have my folder.jpg image displayed on its own, with no Opus-generated border graphic. I can do this by disabling borders, but as that's a global setting, any folder which doesn't contain images will not render anything at all. I'd like to be able to display the Opus folder icon for these folders; my folder.jpg where present; and the normal folder-icon-with-thumbnails for all other folders.

Not yet, but it is planned.

Excellent, thanks! :slight_smile:

Were you able to reproduce this issue? I think I've always had this issue when changing thumbnail settings. I noticed it again when creating the new folder thumbnail styles. All thumbnails are gone and sometimes Opus freezes. I have to restart it or wait for a long time. (I'm also using Windows 10)

It's probably a thumbnailer (external to Opus) getting stuck if you're still seeing it in Opus 13.

Next time it happens, please make some process snapshots while it's in that stuck state, waiting a few seconds between each so we can check if it's completely stuck or making progress but very slowly.

Here's how to make them:

Thanks, I'm not sure if I'd like to share those big memory dumps. I didn't find any clue when comparing them but I probably don't know what to look for... When enabling the 'thumbnail_debug' advanced option, I see some messages like this in the dump: LoadImageFile(1) succeeded, GetThumbnail start, GetThumbnail end, Thumbnail from cache, but I don't see any error messages.

All the options in Thumbnails > Folders and Thumbnails > Styles cause this issue, also the option Rotate images automatically using EXIF metadata.

Just some more observations using Process Hacker when this issue occurs:

  • dopus.exe thread dopuslib.dll > dopus.thumbnailproc starts to use a bit of CPU while RAM starts to grow indefinitely in a linear curve...
    dopus.exe

  • Running 'Go REFRESHTHUMBS' will cause a freeze but no change in CPU/RAM.

  • When exiting Opus, it takes some time to shut down, the RAM usage shrinks until it shuts down. The longer it is kept running, the bigger the RAM usage, the longer it takes to exit.

Definitely something going wrong there, but we need process snapshots to see where it is, and if it’s in Opus or another component.

I fixed this issue by clearing the thumbnail cache. I thought I tried this before but I only disabled the thumbnail caching and didn't clear the existing cache... which was at 3.5 GiB.

This is what Opus was stuck at, reading from the thumbnail cache, never stopping (?).