Files with write-back error do not have the Extra\Error Tag set

[Tveloso]

Last night I started a Write-Back on a group of a little over 100 Files, that were already in their archive location (on a NAS), that I found were in need of write-back.  The majority of them failed, and the tooltip on the warning triangle is the following:

    You cannot view this attachment.

The log names the files, and contains this message:

Code Select Expand

E>     PTWrapper hangs in ProcessRun for 120000 ms.  'V:\develop\IMatch5\src\IMEngine\PTETWrapper.cpp(4146)'

...preceeding each failure.  Does this indicate that IMatch had to kill the ExifTool instances that were working on them?

None of these files has the Extra\Error tag set though, so they didn't appear in my "Files With Errors" Category (which is based on the Extra\Error\Error\0 tag).  Is this because Exiftool did not actually return any error for the file, but had to be killed due to the timeout?

Should IMatch maybe still set this tag in that instance (maybe with a message indicating ExifTool was terminated due to a timeout)?

The Writing Metadata item in the Files With Problems section of the Dashboard does identify these files, so it's probably not important that they don't have a value in Extra\Error\Error\0, but I thought I should ask just for completeness.

I suspect that the issue was really caused by my attempting the write-backs directly on my NAS.  I usually "pull back" files that I need to write back again, in order to do it on the local SSD, but it was relatively few, so I thought I would just do the Write-backs in place.  Even though that's the likely cause, I'll still send the log that shows the Write-Back failures, just in case there might be something of interest there.

[Mario]

...preceeding each failure.  Does this indicate that IMatch had to kill the ExifTool instances that were working on them?

Yes. IMatch monitors ET and when an instance does no disk I/O for 120 seconds, IMatch terminates the instance and starts a new one.

Should IMatch maybe still set this tag in that instance (maybe with a message indicating ExifTool was terminated due to a timeout)?

This tag is created and filled by ExifTool, not IMatch.

Situations where ExifTool fails to update a file are so rare, not worth adding more work to this.
Your NAS / virus checker blocked ExifTool from writing or it was so slow than ExifTool stalled for 2 minutes.
Keep in mind that IMatch writes many files in parallel, depending on the performance mode. This may have just overloaded our NAS box, or it crashed.

No need for sending the logs. The problem is the NAS or your virus checker. Or you must use the lowest performance mode when you try to write directly on the NAS. If IMatch must terminate ExifTool after the very relaxed 120 second period (normal write time is ~1 to 2 seconds), the cause for the problem is external, not IMatch.

NAS boxes are notorious to falter under stress, like many ExifTool instances writing. Thia may saturate your network, may max out the (presumably) spinning disks in your NAS and similar issues.

Check how long it takes to write one file, and go from there.

[Tveloso]

Should IMatch maybe still set this tag in that instance (maybe with a message indicating ExifTool was terminated due to a timeout)?

This tag is created and filled by ExifTool, not IMatch.

Situations where ExifTool fails to update a file are so rare, not worth adding more work to this.

Makes perfect sense.

And isolating the files with this particular condition was easy using the Result Window created by the Dashboard's Files with Problems/Writing Metadata link, and then filtering for files not in my "Files with Errors" DD Category (I had a few more than those identified in the log from the IMatch session where this occurred last night).  So I should be able to easily get this sorted.

Thank you Mario.

[sybersitizen]

NAS boxes are notorious to falter under stress, like many ExifTool instances writing. Thia may saturate your network, may max out the (presumably) spinning disks in your NAS and similar issues.

Check how long it takes to write one file, and go from there.

That's a bit ominous to those us who have our collections on NAS.

Once we find out how long a writeback takes, how do we use that info to safely do bulk writebacks?