Failure to sometimes completely update image when minor error from exiftool

[ubacher]

I encounter images (newly added) where the date/time shown on the thumbnail or the
file window tip is the modified time rather than the {File.MD.XMP::xmp\CreateDate\CreateDate\0}

This gets fixed if I force-rescan the file. (but not reliably?)

Logfile shows the following for files with this problem;

Code Select Expand

09.20 07:32:30+  109 [6F08] 01  W> ETWARN:Warning: [Minor] Not decoding some large array(s). Ignore minor errors to decode - D:\Foto Cache\AAA 2021\2021-09-01 FALL ====\2021-09-06 Lake Am\PANO\2021-09-06 020.dng
Warning: [Minor] Not decoding some large array(s). Ignore minor errors to decode - D:\Foto Cache\AAA 2021\2021-09-01 FALL ====\2021-09-07 Red sky Am\PANO\2021-09-07 005.dng
Warning: [Minor] Not decoding some large array(s). Ignore minor errors to decode - D:\Foto Cache\AAA 2021\2021-09-01 FALL ====\2021-09-07 Red sky Am\PANO\2021-09-07 007.dng

These are dng files produced by the adobe dngconverter (from Nikon Z6 NEF).
The problem is that there is no indication on the thumbnail display that the file was not properly updated!
Only by noticing that the displayed file date is wrong do I know! Of course, the starting problem was the error report from exiftool (it
has problems with a compressed DNG file it seems). This must have caused some timing problems when Imatch runs exiftool - and
as a consequence the file does not get updated properly.

[Mario]

This all tells me nothing.
If ExifTool does not return an error and IMatch can import the metadata, it will not flag the file. Else it will.

Please always provide the full log file (you may easily miss the important bits by posting just as small fragment) and provide a DNG file which exhibits this problem.
This gives me the minimum of into to work with and I can see what actually happens, if this is something that is reproducible on PCs different than yours, if this is an issue in IMatch or ExifTool etc.

[ubacher]

I did send you a dng file and the log.

Now I have more info - the same thing happening - without exiftool errors!:

I process 11 NEF files with PS ACR (the latest) and produce jpg files.
Some of the files do not get their capture time updated - they show up with their modification time.
I repeated this several times and the failures are random.

In addition there is the occasional file which does not get indexed completely (the blue UPDATING icon and grayed out thumbnail stays)

Additionally: When I  last thought the exiftool errors were caused by compressed dng files - I had the same error message today on a
normal dng file.

As long as I notice this wrong time I can fix it by force-rescanning the file.

[jch2103]

I have noticed something that might be similar: https://www.photools.com/community/index.php?topic=11262.msg80389#msg80389

It seems to have happened when I processed large groups of images in DxO PhotoLab: some but not all images showed the 'wrong' date in the File Window unless I rescanned them (although the images had the correct 'taken' and 'digitized' date/times. I haven't been able to reproduce this consistently, and it hasn't happened lately that I've noticed.

[Mario]

Locking issues?

[jch2103]

Locking issues?

That's what I suspected. But just a guess because I can't reproduce it consistently (and haven't had the problem lately).

[Mario]

When IMatch (or ExifTool) cannot access an image, a corresponding W> should be logged to the log file.
And the file should get a yellow warning icon.

If the file could be accessed but the other application is still writing to it (?), things may look different and maybe only partial data can be read. Very tricky to figure out unless there is a 100% repro case.

[Mario]

I have tested the file.
IMatch shows the correct date and time in the metadata panel.
The file has an embedded EXIF record and an XMP record written by Lightroom I believe.
The date and time of the two important timestamps matches and is also what IMatch shows in the Metadata Panel.