Collection or Filter for metadata writeback error

[Rhadamanthys]

In my process of migrating from 3 to 5 an attempt was made to write GPS data to and to correct creation time (for camera clock offset to UTC) in file metadata. Browsing  the folders I discovered some writeback errors, see FileWindow.JPG.
The file window shows the pending writeback icon and a warning icon.
Suspecting to encounter more than one error in the about 30k images (primarily JPGs) distributed over about 30 folders I hoped (almost expected) to find them somewhere in the Collection window. However: CollectionView.JPG.

There seems to be no filter setup for these warnings either.

From the Help I understand res=data.writeback(true) not only writes to the database but also to the physical file. The result however does not refer to file write success.
Question: Is there any way to verify file write success other than using another script to check all the files?

Off topic comment: looks like the Exiftool warning ("Warning: Bad InteropOffset SubDirectory start - M:\iMatch5\Fotos\Eigene\2004\20040308.jpg") is associated with files which were "lossless rotated" by Imatch 3 ( or whichever version I used back in 2004) as they occur only on portrait oriented images.

[attachment deleted by admin]

[jch2103]

Take a look at this thread (read the whole thing, though, for completeness); it may help:
https://www.photools.com/community/index.php?topic=1152.msg6855

[Mario]

A metadata filter on the Extra\Error tag is the trick to find all files with a write-back error.

I did not implement a dedicated filter or feature because write-back errors are so rare, it's just not worth it.
If you want it, you can create a data-driven category on this tag and this gives you a category with all files with a failed write-back.


If you have write-back errors for your file, the exact message reported by ExifTool would be helpful.
You can see it in the warning icon tooltip, and also in the output panel after the write back.

Bad InteropOffset SubDirectory start

is a rather common warning and can be caused by many reasons. Sometimes even files straight from the camera show this.
ExifTool will fix this usually when you write-back successfully once.

[Rhadamanthys]

I have qty 2014 pics taken in year 2004 with a Olympus C750UZ. 700 of them are portrait and of these 136 show the error. Attached is the exiftool output as copied from the Output Panel after I attempted to edit the XMP::photoshop\DateCreated\DateCreated\0 tag, named "Date Subject Created" in the Metadata Browser. Various GPS related tags can be written to those files successfully though.

[attachment deleted by admin]

[Mario]

ExifTool reports:

Error: Can't read InteropIFD data - M:/iMatch5/Fotos/Eigene/2004/20040308.jpg

and a quick search reveals

https://www.google.de/#q=exiftool+Can%27t+read+InteropIFD+data+fix

I suggest you try out the tips there in order to repair the damaged data in your files.


PS.: A Feature Request is not the best place to ask this kind of questions. I usually look at FR's maybe once a week.

[Rhadamanthys]

Mario,
my subject was indeed a feature request for a collection or a filter for writeback errors generated by IM5. I am aware the errors are caused by corrupt files.

Addendum:
(Strictly for information, no feature request, no bug report, no request for help)
Writing to "XMP::photoshop\DateCreated\DateCreated\0" causes IMatch/Exiftool to copy the value to "XMP::exif\DateTimeOriginal\DateTimeOriginal\0" too. This works via script as well as by manual editing in the Metadata panel.
In my corrupted file the copy process fails and this raises the error and the writeback icon in the file window. It does not update the pending writeback collection though. Hence writeback cannot be initiated from the Commands menu.
However the copy process can be initiated by clicking the icon  , indicating that Exiftool can do the job even on my corrupted file.
My script now writes successfully both tags at a time and I can safely ignore the warning which will be extinguished at the next rescan anyway.
And yes, I reckon I could even fiddle with the args files which I guess are responsible for all this tag copying