IMatch Processing Queue Files category

[cg]

Many times after writing back metadata, the dashboard update hangs while displaying a rotating circle. If I clear the file processing queue under commands, the dashboard refreshes. At that point, there are files assigned to the IMATCH_PROCESSING_QUEUE_FILES category (there is a number in the parentheses) however the file window is always empty and shows 0 (0.00 KB). There are no filters active.

I've toggled different settings in the file window (Show Hierarchy, Show only directly assigned, etc) yet I haven't been able to see what files are in the category.

How do I view the files in this category (as I assume that would be useful in tracking down metadata read/write problem files)?

Thanks!

[Mario]

What does the queue contain when you forcefully delete it (this is something that should only be done under very special circumstances, because it may cause data loss (metadata not written but forcefully stripped from the queue). Not all queue entries produce entries in this category, e.g. rescan entries do not (no need).

The dashboard will pause updating while it detects activity in the database (like, after a write-back, where all files must be re-read, all categories and collections recalculated etc.).
I don't know how many files you write-back in a batch, how large your database is, if IMatch has logged any warnings or errors. You did not include a log file (see log file) so I have basically nothing to work with. A similar issue was not reported so far.

[cg]

In this case, I ran face detection on a number of images and it seemed to get "stuck" matching faces for 25 images or so. Each time I restarted the program, there was one fewer in the queue. I enabled debug-level logging and cleared the face matching queue. That "unstuck" the dashboard and it refreshed, and there are now 23 files listed as being in the IMATCH_PROCESSING_QUEUE_FILES category, though there are no files in the file window for that category.

I can probably recreate this situation by running more face detection/matching, but, as mentioned above, I run into similar numbers of files from 25-70 getting "stuck" in queue when doing metadata writeback as well.

[Mario]

Define "stuck", what happens exactly?
In which View are you when you run face recognition manually (from the File Window menu) or do you run it from the Viewer?
What kind of hardware do you use?

The log file looks normal, no errors or warnings. Nothing unusually slow for a 120K files database.


Please go to Edit > Preferences and search for threads. Set the value to 4 and restart IMatch.
This reduces the load on the system and maybe this fixes this strange problem.

[cg]

This has happened when I write back metadata, and also happens when I select files (sometimes only 85 or fewer) in the file window and "Detect Faces and Create Face Annotations."

For instance, right now, I ran the face recognition on 39 files, the face detection finished, but perhaps something in the face matching step is hanging, as there still seem to be 10 files in the "Entries in Queue" line in Info & Activity. The line flashes 0, then immediately refreshes to 10 and never gets to 0. While in this state, the dashboard won't refresh until I "Cancel Person Assignment Updates" then the dashboard immediately refreshes and Entries in Queue is 0.

I set the threads for face recognition a long time ago 2 which already solved what I believe were overload crashing problems.

Is there a way to see a list of what files imatch is trying to process in "Entries in Queue" ?

I'm using an Asus laptop i9 2.9GHZ, 16G RAM with the photos across two SSD's and the database on the internal SSD.

The operation and performance seems otherwise fine except for this recurring problem. I emailed a larger log file from the metadata write back that caused the same problem that perhaps contains some clues.

Thank you!
Chris

[Mario]

Which virus checker do you use?
I mean, problems during write-back and problems during face recog. are totally different things.
In 95% of all reports of such strange issues, the problem is the installed virus checker blocking IMatch or scanning the database all the time, bringing down IMatch to a crawl.
See IMPORTANT: Virus Checkers. Unless you use Windows Defender, this might be something to look into.

I set the threads for face recognition a long time ago 2 which already solved what I believe were overload crashing problems.

You have a 12 core system and you had to set the threads to 2? I also have a 12 core system and IMatch runs full-throttle over my test database with 80,000 files doing face recognition...
Some stability issues under prolonged load perhaps?

Is there a way to see a list of what files imatch is trying to process in "Entries in Queue" ?

No. This is never needed. Because all this just works. IMatch processes the files you have selected when you started the face recognition. It will process the files you have selected when you triggered the write-back.
The recently processed files are listed at the end of the log file (see log file).

For information about IMatch's resource usage (memory, CPU) look at the the IMatch Dashboard