Endless updating

[Mees Dekker]

I ran into a rather peculiar problem. After changing some keywords in the thesaurus manager, I did a write-back on some 2000 files. Another 1000 files I left as write-back. A database diagnosis (log attached) showed warnings about files that should be pending, but stated that is was fixed. After this diagnosis, Imatch opened again, but when switching to another panel, it stopped responing.

From that moment on Imatch keeps updating (reading metadata, adding files etc) and never stops. It comes to about 90% and than falls back to 80% and does that over and over again. There seems to be some kind of loop, because I see the same files being  processed.

I ran this on both my desktop as on my laptop. Same behaviour on both machines. After running for more dan 24 hours. Imatch had to be killed through taskmanager. Logfile (form lptop) attached, alas not in debug mode.

Information & activity panels says that there are over 9200 items in the queu. However the IMatch_Pocessing_Queu  category does not exist/is not shown. So cannot be cleared either. 

Also when I try to change my file relations, Imatch immediately stops responding.

[Mario]

To clear the processing queue, use the corresponding command from Database menu > Tools.

The log file shows a larger number of folders, e.g.'P:\Foto's\Privé\2010-2019\2016\ or P:\Foto's\Trefkuul\2017\ with files newer than the folder in the database. These folders are scheduled for rescan. Are these the folders you mean?
You can find the folders in your log file, search for W>

I see one warning about ExifTool not responding in time at the end of the log file while IMatch tries to shut-down the thread.
Then the log file ends.

[Mees Dekker]

Yes indeed are these the folders.

My problem is that the process starts with some 50 files to be scanned, but the number increases and currently is over 1100 files. Scanning takes for ever, at a rate of several mintes per file! Almost 10.000 items in the queu. Should I clear that queu or is it not advisable and wait (I could leave my computer on during the night)?

[Mario]

Scanning takes for ever, at a rate of several mintes per file!

Do you have a log file in debug mode where I can see the timing information?
When you look at the "Performance" tab in Windows Task Manager, are the processor cores maxed out (CPU) or maybe a disk at 100% all the time?

Did you make an exception for IMatch 2025 in your virus checker?
What kind of drive is P:? Maybe the system is overloaded?
Go to Edit menu > Preferences > Application. Locate the performance profile and set it to Balanced or even Low. See if this improves things.

[Mees Dekker]

P: is on a Synology NAS. Exceptions have been made you both the Imatch, as well as the

I let IMatch run for a couple of days (!). it kept doing things at a very slow pace. But when I wanted it to close in the normal way, it stopped responding.

Changing to another performance profile, seems not to make any difference.

I have a log file in debug mode but it is to big for attaching. How can I get that to you?

[Mario]

A NAS is the worst-case, performance wise.

But when I wanted it to close in the normal way, it stopped responding.

This is the typical sign of IMatch (or ExifTool) hanging locked in a file system call (trying to read data) and IMatch being unable to shut-down all running operations because of that.

Super-slow or blocking file operations would also explain why performance is so slow. The NAS does not keep up.
Try with the performance mode set to the Lowest setting. IMatch then only uses a very small number of parallel operations, maybe the NAS can handle that.

When you copy a folder of your images from the NAS to a disk or SSD installed in your computer and add it to an IMatch database, how's the performance then? Just to rule out the NAS as the cause of the problem.

If the ZIPPed log file is smaller than 20MB, you can send it to my email.
Else, upload it to your cloud space and send me a download link.

[Mees Dekker]

I know that a NAS is the worst case. But it was slower indeed, but untill a couple af days ago, it never caused a problem like this. This all started after I had keywords changed through the thesaurus.

However: this phenomena is not restricted to the files on my NAS. Also files on my internal SSD take for ever to be read (metadata). Moreover: even the included thumbnails in my CR3 are not loaded.

Another peculiar thing: I closed Imatch (by hitting the red cross in upper righthand corner) but the file window stayed open/visible. The taskmanager did not show any Imatch running. It gets more and more puzzling for me.

Reinstall IMatch perhaps, but what about my database? (I have P&G copies from more a month, so well before 2025.3 or the occurring of this problem.

[Mario]

But it was slower indeed, but untill a couple af days ago, it never caused a problem like this. This all started after I had keywords changed through the thesaurus.

You changed keywords in the thesaurus and let the thesaurus apply these changes to your database. (?)
Which type of change did you do?
This is an in-database operation that does not affect files, unless you have immediate write-back enabled (default is off).

Did you make any other change at the time? Windows update installed? Virus checker updated?

Also files on my internal SSD take for ever to be read (metadata).

Did you send a log file yet? I have nothing to work with.
If reading metadata takes a very long time, the typical reason is that ExifTool does not handle the metadata well (unlikely), there is a problem with the metadata or ExifTool is throttled by a virus checker or similar cause.

Another peculiar thing: I closed Imatch (by hitting the red cross in upper righthand corner) but the file window stayed open/visible. The taskmanager did not show any Imatch running. It gets more and more puzzling for me.

This also sounds like IMatch or ExifTool processes were "stuck" in file system calls and took a long time to terminate.
When you close IMatch while it is indexing files, reading metadata or writing back, IMatch must terminate all threads and processes and then wait until they finish. If ExifTool is stuck reading files, IMatch waits for up to 120 seconds when ExifTool shows no disk I/O and does not consume and CPU resources. But that's really rare, unless ExifTool is stuck/blocked by something.

The log file may tell me more, especially what takes so long.

[Mees Dekker]

You changed keywords in the thesaurus and let the thesaurus apply these changes to your database. (?)
Which type of change did you do?
This is an in-database operation that does not affect files, unless you have immediate write-back enabled (default is off).

Yes, I made some changes in the Thesaurus (mainly spelling en Upper-/lowercase, also deleted some). Automatic write-back not enabled, but I did write-back some 2000 files and left 1000 to be written-back

Did you send a log file yet? I have nothing to work with.

I send you an e-mail this afternoon (May 10th, 12.18 hrs)

Should there be an exeption (in W Defender) for Exiftool as well as for Imatch?

[Mario]

Should there be an exeption (in W Defender) for Exiftool as well as for Imatch?

Since we don't know what's causing this, I would consider this a good idea.
exiftool.exe in the IMatch program files folder, IMatch2025x64.exe, the folder containing your database.
Maybe this improves things. Worth a try.

I have seen your email in my stack from today. I will look into this on Sunday or Monday.

[Mario]

I have looked at your log file.
It has 2,113,105 lines, 261 warnings, 1 error and 24,141 log entries about "slow" operations.
138 folders were identified as outdated (last modified newer than in the database or a file newer than the folder).
20 files failed (CR*) to load with LibRaw (unsupported format).
Log runs from 05.09 12:25:34 to 05.10 07:47:53

When the database was loaded, IMatch consumed 702MB, the highest usage value reported is 2.7 GB (< 10%), which is OK while indexing many files. When IMatch started, memory utilization was 41% (out of 32GB).
The highest utilization reported was 84%. This means that some external application or ExifTool (unlikely) have consumed a lot of memory over the time period recorded in the log file.

IMatch was very busy scanning folders and indexing files. Recreating missing cache images. Propagating metadata, because new versions are found. Maybe this is part of the problem?
While IMatch is ingesting metadata, the execution times for the PTETWrapper::ProcessRun (metadata read / write) become slower and slower. From initially 0.5 to 1.0 seconds to 12, 16 or more seconds.
I see things like
PTMetabase::ImportFiles: 1 files (655 tags) in 25156 ms.

Importing metadata for one RAW file usually takes 0.1 to 0.5 seconds (local disk), not 25 seconds. This varies a lot up and down. Sometimes IMatch logs 1 second, sometimes it logs 101 (!) seconds or more. Then things go back to normal.

IMatch tries to adapt by dynamically reducing and incrementing the number of parallel threads in use.

Then I see again things like:

PTMetabase::ImportFiles: 1 files (483 tags) in 186360 ms.
[189860ms #sl] PTMetabase::Propagate

3 minutes to import metadata for one file. 3 minutes to propagate data from a master to versions (using ExifTool).

To me this sounds like somehow the system is a) super-busy reading and writing metadata, and b) the P: NAS seems not to cope to well or with a wide variety of response times.

What happens when you set the performance profile to the "Minimal" setting (which is a fallback).
In this mode, IMatch runs only a few threads in parallel and with < 50% CPU utilization. This should give your system room to breathe while it works through all the updated files and propagations.

[Mees Dekker]

Thanks for all your investigating. Much appreciated.

Most of the time, the preferences window would freeze, but now I managed to set performance to minimal. De-activated all versions and propagating. 

Will see this works out.

[Mario]

Maybe a cyclic version rule, making the same files masters and versions, causing endless propagation?

[Mees Dekker]

After some 6 hours of reading metadata en updating files, the database is fine again.

Phew, this caused me considerable worries for possibly losing my data (I'm a long time user of IMatch), so my database is worth a lot.

Thanks to Mario for his superb assistance. Never seen anything better in the world of IT.

From here on I will go back to my normal performance profile. Then further investigate my file relations, as per Mario's suggestion.

[Mario]

Very good. Always remember to make a daily backup of your database and to keep these backups for a couple of weeks.
This is the best insurance against bad will ever happen to your database. You can always go back, step by step, to the time before the error happened.

I'm still not sure what caused this flurry of indexing and updating operations. But what IMatch logged checked out, just the runtime was so variable and, quite often, abysmal.

When indexing, IMatch utilizes all available processor cores, memory and disk resources, limited by the performance profile.

Unfortunately, I have not found a way to monitor disks on NAS systems or servers. The performance profiling features in Windows don't work for non-local drives. Windows / IMatch cannot "look" into the NAS system to monitor disk performance. I've I've used some heuristics to guess an average utilization for network drives and tested that on some NAS systems and Windows servers.

I still wondering if this slow-down was caused by the NAS not coping or some virus checker or whoknowswhat...

If the performance was notably better in with the "Minimal" performance profile (did you keep the logfile?) I guess it was an overload / not copying condition caused by the NAS system and the many parallel reads and writes IMatch did.

I mention this in the help: Utilization for Slow Media (DVD, NAS ...)

[Mees Dekker]

Alas, unfortunately I did not keep that logfile.


I think the versions were the culprit (recurring/cyclic version).

For now: I'm glad to have this resoved. Thanks again.

[stefanjan2]

I mention this in the help: Utilization for Slow Media (DVD, NAS ...)

I'm interested in readin this help article but link does not work and could not find when searching help

[bekesizl]

I mention this in the help: Utilization for Slow Media (DVD, NAS ...)

I'm interested in readin this help article but link does not work and could not find when searching help

https://www.photools.com/help/imatch/index.html#rmh_config_appsettings.htm?dl=hid-16