2.6K+ metadata changes update took over 12 hours. Is something wrong?

[Damit]

I just changed some keywords around which caused over 3000 files to update metadata. So far only 2650 have updated and it has been roughly 12 hours.  IMatch is predicting the rest will take another 6 hours.  The files are large tiffs made when scanning negatives and prints at high resolutions, but still, I would think that this would process more quickly. Could this be normal?  If not, what could be causing the delay? Is there something I should do to verify if there is something wrong?

My database is on a very fast Nvme but my files are on a enterprise HHD.  Initially my HHD showed 100% active time with transfer rate varying from 5 mb/s to 60 mb/s, but now my database nvme is showing 100% active time, with short bursts of transfers at 100 mb/s and the HHD is completely inactive.  I assume now some of the changes are being written to the database, where before the information was being modified on the HHD. 

Would changing metadata cause the file to be re-written completely?  Even so, this cannot be more than 500 GB of files, maybe 1 TB and writing that much still would not take this long. I am just trying to figure out if there is a problem or a bottleneck that is slowing down my system, so perhaps I could address it in my next build.

[Mario]

Always include a ZIPped copy of the IMatch log file (see log file). This will tell us a lot more about what is going on.

When ExifTool has to splice TIFF files to make room for XMP and update EXIF/GPS or whatever is needed, the file size of course matters. The file needs to be spliced, rewritten and then re-read to bring in the new data into the database. ExifTool also never updates the original file directly, it create a new copy with the new data and when that succeeds the original is replaced. This is very safe, but slower.

IMatch writes back multiple files simultaneously and maybe this is too much for your system? Or maybe the virus checker is kicking in (frequent case!) and slows down things massively? Maybe ExifTool finds problems in the TIFF files and has to do extra work to fix them. Without a log file, we don't know.

Writing back to a 350 MB TIFF fiel (1 TB / 3.000 files) can take a couple of seconds. And when IMatch does this in parallel (depending on your CPU count), this may max out your system. Is this a desktop PC, a workstation or a Notebook, for example? The log file shows how long ExifTool needs to read/write files.

1. Check your virus checker and make sure it does not interfere with IMatch. Windows Defender is usually fine, but other virus-checkers make problems occasionally. See IMPORTANT: Virus Checkers

Go to Edit > Preferences > Application and reduce the number of parallel write-back threads (see Write-back).
IMatch balances the write-back usually quite well, reducing the number of parallel writes when the system is not coping, but that may not always work.

[Damit]

I have attached the zipped log file. It has a lot or warnings, mostly stating IPTCDigest is not current. XMP may be out of sync.  I also read some errors stating some files could not be written to because they were read only.  I checked and somehow they were set as read only.  Would this cause serious delays?

The reason I did not attach the log before is that I was trying to be patient and IMatch finish because the last time I tried to cancel the process IMatch seemed to hang and was unresponsive for over 30 minutes.  I had to shut it down with the task manager. That may be the reason why I read some warning saying a temp file already existed for some files.

I timed the last few metadata updates and they were averaging around 15 seconds but I know some have taken much longer. They are large files, some as large, or maybe larger than your estimate.  They consist of materials scanned in .tiff with little compression at high resolution. They are about 5-10% of my photos but take probably 30% my hard drive space.

I monitored the system in the task manager.  My CPU has never been tasked by this process. Process Explorer is currently tracking all IMatch processes to be taking 14% of my CPU. Yes all cores are being used but at 10-20% with brief peaks at around 50%, which last for a second every couple of minutes. I do not think my CPU (Ryzen5 3600) is being taxed. I do see 12 or so process of exiftool working when I check out the Disk Processes.  It does seem like I am in the process you described with exif, where it is writing a new file, considering that I now noticed by HHD with the photos is active again after being inactive for a while. Still write speeds never seem to exceed the speeds I have seen my enterprise drive read.

My memory remains stable at around 68% utilized (43.4/63.9 GB).  I use DDR4 error correcting memory.
The drives are active 100% of the time but the read and write rates are negliable and very slow at times. They beak at 50 mb but for brief periods. 95% of the time it is 5-10mb.
I do NOT have an antivirus other than defender. If there are things you need me to check or verify to ensure that it is not the virus protection, please let me know.

For now I will do a database cleanup after backing up.  I will then try to write back again, now that I have reset the read only condition on them.

[Mario]

Long delays usually mean that ExifTool has crashed or is "hanging". IMatch monitors the ExifTool process and shuts it down after 120 seconds without I/O or CPU usage (to accommodate for slow media / network storage).

But ExifTool crashing or hanging is very rare, and usually indicates a) a badly corrupted file or b) a virus-checker or other "security" software blocking the ExifTool process from writing.

The Temporary file already exists warnings in your log file indicate that ExifTool crashed or aborted. It uses a temporary file in the same folder as the original file to write safely and when the write operation has successfully completed, it replaces the original file with the temp file. If the temp file still exists, ExifTool crashed. Please delete the temp files in Windows Explorer manually. They all end in _exiftool_tmp.

The first warnings in the log file are about read-only files. ExifTool will not write to read-only files. Make sure the files are writable (use the shield icon in the File Window) before writing back. Read-only files will not slow-down ExifTool.

The warning IPTCDigest is not current. XMP may be out of sync is just a sign that you have used non-compliant software (or software with a half-assed attempt at metadata) on your files. The requirement digest (check sums) for IPTC do not exist. ExifTool will create them during write-back.

Then I see PTWrapper hangs in ProcessRun which means that ExifTool did stall for 120s and IMatch has terminated it. For example, for the file D:\[]5\1978-03-05 Circa Epsn800-Print-568(5).tif. What kind of file name is that, with the [] at the front?

This has nothing to do with file size. There are many more reports like this. And of course, if each ExifTool instance somehow stalls and has to be terminated after 2 minutes by IMatch and then started again, no work gets done and a write-back will take infinitely long.

This goes on for a long time, each time ExifTool does not complete and is stuck for 2 minutes.

Conclusions: Either all your files are several Gigabytes in size and contain metadata that makes ExifTool break, or your system is behaving funny under heavy load or your virus checker is blocking ExifTool (most likely). I have not seen such a mess in a long time.

1. Delete the temporary files created by the ExifTool crashes.

2. Go to Edit > Preferences > Applications: Process Control.
Set the write-back threads to 4

3. Restart IMatch and write-back a handful of files. Any change (Check the log file)

4. Make extra sure that your virus-checker is not blocking IMatch and ExifTool from writing. See the manual of your virus checker for details to see if it did that and how to make the ExifTool.exe in the IMatch program files folder an exception.

[Lucio.B]

In my case, as suggested by Mario, changing: Preferences>Application>ProcessControl "Threads for metadata write back" to 1 definitely speeds up A LOT the write back process.

[Mario]

1 means that IMatch only writes one file at a time, which is usually much slower than writing multiple files. Even for files on a slow remote disk / NAS.

I would recommend you make some tests and see if 2 or 4 works faster.

ExifTool hanging is very rare, and I have never seen this because of "stress" (aka IMatch writing too many files at the same time).