Imatch hangs a long time after viewing half a dozen or so D180 jpegs

[muranod]

When viewing a folder and clicking on large files from a Nikon D810, the program eventually hangs for 2-4 minutes and more before displaying an image in the QuickView panel. I tried forcing a rescan (including a rebuild of all of the NEF files), The Jpeg files do not have prebuilt previews. I have Win 10, 64-bit w/ 32GB of ram and plenty of hard disk space, most of it SSD drives.

I tried creating a dump file (following instructions here) when I had to crash out of the program crashed, but only got 0kb files. I did turn on enhanced debugging in Imatch and am including those log files here from several events, in case they may show what's going on that would take so long to read files, which are round 19MB each our of the camera. I have not had the same issues with Nikon D610 files.

The NEF files all have cache previews, but after this happens, even those take a very long time to load. Things work better at first if I close the Quick View panel, but will still eventually slow to a crawl to read the metadata as each file is selected. With QuickView enabled, Imatch eventually stops responding completely.

[Mario]

The log files show no errors or warnings. IMatch peak memory usage at about 400 MB.
The reported time for loading an image into the Viewer / Preview is about 50 milliseconds.
The DMP files are empty?

What does the process manager image show us? You did crop the column headers so I cannot tell what is what.
IMatch is using 16% CPU time (?) so it is doing 'something'.

Which kind of WIC codec are you using? Which kind of graphic card? When you use the Task Manager, also check for the GPU usage, because IMatch may hanging, waiting for the graphic card or driver to do something...

Or maybe Windows is locking files when you try to view the same files in the Quick View Panel and the Viewer?
When the user opens the Viewer IMatch notifies the Quick View Panel to clear the cache, except for the image currently displayed. This reduces memory usage and prevents Windows WIC / DirectX from locking files. Maybe this does not work on your system?

Effects like this which (apparently) only happen on a single PC are always hard to diagnose.
I recommend to update the graphic card driver to the latest version and to really reboot your system once.

[muranod]

Thank you, Mario. I've been experiencing this for a week or two. I posted now because I figured you could tell me a few more places to look. I'm using the fastpictureviewer codecs which I last updated about nine months ago. I will check for an update there as well. It's odd that this only seems to be happening on some D810 files, but not across all of them. I will report back if I can track down a cause / causes.

[Mario]

If the cache images have already been created, the RAW WIC codecs are out of the loop. IMatch uses JPEG or PNG files for cache images and these are loaded by the Quick View Panel / Viewer using the default Windows JPEG WIC codec (unless it has been replaced by some other codec) and then the image is handed over to DirectX and the graphic card for storage and display.

I have only about 50 D810 / D850 files here, but they did not show any unusual behavior in my quick test. This is not a new RAW format and so far I don't recall any related issues.

What is strange is that IMatch uses only 400 MB memory in Peak. Usually the Quick View Panel / Viewer use memory until 90% of the available RAM is full. Then they remove 'old' files from memory to make room for files which are being loaded in the prefetch. But that means usually several GB of RAM in use by IMatch, not only 400 MB....400 MB is only enough for 2 or 3 D810 files.

It looks like IMatch got stuck loading files from the cache? Or pumping image data into the graphic card memory.
Mabye a virus checker issue? Or another application locking the graphic card or interfering in other ways...but then, why only for D810 files...unless they are not yet cached and then WIC comes into play again...

Tip: Enable Debug logging via Help menu > Support to get as much detail as possible into the log file during your tests. Maybe we can figure out what's causing this.

[muranod]

Thanks. Will do that as I continue testing. Also, I didn't realize Imatch was using so little memory at that time. I did update my Nvidia graphics driver a few weeks ago and will begin with a check into the Nvidia driver and settings.

[muranod]

All better now.

I switched to the administrator profile where things were the same, except I noticed I had loaded an older copy of the database made for IMA. No idea why I would have loaded it, but I logged back into my profile and saw it was the same. I switched to the other database and everything was working again! After a few hours relocating and re-indexing folders and files, nothing was lost. Thanks for the many suggestions that helped me understand how some of the parts of Imatch work and in what parts of the program to hunt for solutions.