Increase ExifTool Runtime Timeout

[Ian Pollen]

I would like the ExifTool runtime timeout in IMatch to be increased beyond the current 3 minutes.

I am trying to write out metadata to large TIF files stored on a NAS drive and the current 3 minute timeout is causing the metadata save to fail resulting in a corrupted TIF.

[RalfC]

I wonder how hard it would be to make the ExifTool timeout a user configurable setting?
We could all choose our own desired and acceptable time based on our individual hardware setup.

[quoted from the discussion chain where the request originated]

I am not sure if many users would be able to choose a reasonable timeout, but I think that it might be good to get a Pop-Up warning if IMatch terminated Exiftool (due to a timeout) asking to reduce the amount of threads.

This would help to recognize if there is a bottleneck in writing/reading metadata.

Regards,
Ralf

(amended for giving more information on solving the issue)

[Mario]

This is not a simple "Start ExifTool and wait for 3 minutes and then abort" check.

IMatch monitors the ExifTool process to see if is still "doing work", making file I/O. In the rare instances where ExifTool actually hangs (because it hits badly damaged metadata, infinite loops in the metadata or a file operation is blocked/stalled by whatever) IMatch stops the process after 180 seconds and creates a new instance of ExifTool and then continues.

[Ian Pollen]

But ET is actively writing out to the file when it is terminated. On testing I end of with TIF files are varying length depending on how far it progressed in the allowed 3min timeout.

If I watch the folder hitting refresh the file is growing constantly and never stalls.

[Mario]

I will run some tests for your very specific scenario for one of the next updates. Maybe the code which monitors ET fails on your machine for whatever reason. IMatch tracks file I/O and also the data delivered from ET to IMatch via memory (when ET returns the results). If IMatch closes ET after 180 seconds it did not recognize any file I/O or other activity. May be related to the NAS you are running, the SAMBA version and many other factors which prevent Windows from reporting back proper data to IMatch.

NAS boxes and CIFS/NFS whatever are always a cause for problems, especially when put under heavy load. That's just not the way NAS boxes should be used. Much better to finish your files locally and then move to NAS for long-term storage. NAS boxes are not the ideal working environment for downloading/uploading/writing 800 MB files over the network. They great for archival or music/video streaming. Not image editing.

[Ian Pollen]

Interesting... looks like we maybe getting closer to working this one out :-)
If you need me to test anything this end please don't hesitate to ask Mario.

I will say this though, the ReadyNAS Pro Pioneer is built for enterprise level usage and I have never had any issues with editing files directly stored on it. In fact I can back up a full disk image of my main computer 500Gig significantly quicker to the NAS than a directly attached USB2 drive.

Ian

[Ian Pollen]

OK I decided to do a test and remove the NAS and network performance or any LAN transfer protocol from the equation.

I inflated this TIF file to 1.5Gb and copied it to a USB2 external hard drive. As soon as the 3min timeout is reached is terminates and leaves a  partially written TIF or ExifTool tmp file behind. I had to make it 1.5Gb to hit the 3min limit.

Ian

[Mario]

I've added a bit more monitoring for the next release. See if this works. So far you are the only user ever reporting this so you need to test.
I'll close this FR until then as done.

[Ian Pollen]

Thanks Mario... more than happy to test as and when required :-)