Face-related diagnostics warning

[jch2103]

I ran Diagnostics today and it reported 68 warnings, apparently all related to Faces:

PersonManager Stats:
    Files with faces: 6393
    Persons: 159
    Faces: 6393
    Confirmed: 6332
    Unconfirmed: 0
    Unassigned: 61
    Warning: Face [5836] for file [63080] has no timestamp. Fixed.
    [Etc.]

They were all fixed, so no real problem. I'm just curious why some face information wouldn't have a time stamp, as I don't have any direct control over that as far as I know?

Diagnostics log attached, for information.

[Mario]

The timestamp format was changed between 2020.3.4 and 2020.3.6. Usually this is automatically handled when the database is opened for the first time.
Do you recall any issues during the first open of the database? Since this was reported only once so far, I guess this may be something unique. The diagnosis can fix this, so no harm done.

[jch2103]

The timestamp format was changed between 2020.3.4 and 2020.3.6. Usually this is automatically handled when the database is opened for the first time.
Do you recall any issues during the first open of the database? Since this was reported only once so far, I guess this may be something unique. The diagnosis can fix this, so no harm done.

I didn't notice any issues during the first open of the database. Because the diagnostics fixed it, all looks fine now. I was just curious...

[jch2103]

For some reason, the same face/files keep returning when I run Diagnostics, despite Diagnostics saying that the warnings are fixed.

See diagnostics logs from April 7 and April 12 (run twice, two logs).

What do I do to clear the warnings?

[Mario]

Hm. Seems that some of the faces are not having proper new format timestamps. Not sure why.
This is not harmful, though. It just affects the ability of IMatch to integrate the 'face age' when assigning persons.
When you run the diagnosis two times, do these issues remain?

[jch2103]

When you run the diagnosis two times, do these issues remain?

Yes, the problem is still there after two diagnosis runs. How can I locate the faces/files in question?
E.g., "Warning: Face [5836] for file [63080] has no timestamp. "

[Mario]

Strange.
The diagnosis actually sets a new timestamp when it identifies this issue.
The code is simple and should not fail.

An end user cannot easily find a file by its unique id.
So I have pimped one of the sample apps included in IMatch do to this.
Download the attached ZIP file and extract it. Copy the resulting "filedata" folder into

c:\ProgramData\photools.com\IMatch6\webroot\imatch\samples

on your system. Replace the existing folder.

Then go to Edit > Preferences > Application and enable the Developer Mode. Close and restart IMatch.
IMatch now shows the sample apps for developers in the App Manager.
Click on the sample app named "File Data" and then enter the id (OID) of the file you want to find in the input field. Press <Enter> or click "Lookup".
This shows you the data for this file, and the folder etc.

Anything special about the file?
Does it show a valid date and time in the File Window?

[thrinn]

I also get this warning for one (only one!) image in my database.
Warning: Face [5409] for file [32108] has no timestamp. Fixed.
And in spite of tagging this warning as fixed, it remains for consecutive diagnostic runs (3 so far).
In my case, it is a tif file.

Just as a tip for others: To identify which file is mentioned in the log, I used a call to the v1/files endpoint:

Code Select Expand

http://127.0.0.1:50519/v1/files?auth_token=&prettyprint=true&id=32108
The last id part is the number shown as ...for file[nnnnn]... in the diagnostics log.

So, after identifying the image, I used the Metadata Analyst on it (result attached). I got a warning "EXIF: CreateDate missing".
To check if this could be a possible cause, I set the CreateDate (using the Time Wizard App). After this step, the Metadata Analyst warning was gone, but another diagnostics run showed still the warning documented above.
Conclusion: The missing CreateDate was not related to the warning in the diagnostics, I just want to document what I tried.

Next step (successful, this time) was to re-confirm the face (the image in question had only one) in the new Face Manager. After re-confirming, the warning was gone.

[thrinn]

Mario,
the ZIP file containing the modified app is missing.

[Mario]

Yikes. It was probably stolen...

I will attach it again below.

[jch2103]

OK, I ran the File Date app on the image I referenced above (File 64080) and got the attached file data. All the dates look reasonable, but note that the original date/time is in 1846 (family portrait approximate date).

I next checked File 76131. Again, a family photograph, this time from 1883. (See attached File Date app data.)

I can run some more, but it looks like the problem has to do with original date/times from the 1800s. Let me know if I need to check more images from the diagnosis output or if you want me to do something else with the images/faces.

Edit: I also noticed that many of the warnings are duplicated, e.g.:

Warning: Face [5884] for file [76131] has no timestamp. Fixed.
    Warning: Face [5885] for file [76131] has no timestamp. Fixed.
    Warning: Face [5884] for file [76131] has no timestamp. Fixed.
    Warning: Face [5885] for file [76131] has no timestamp. Fixed.

In fact, most of the warnings are repeated; for example file 76134 has 4 repeats.

[Mario]

I see.
All is well. The database is OK. Just the check for the timestamp is wrong in the diagnosis.
Your very early dates create a negative date and time value (it becomes negative before 30 December 1899, midnight) and the diagnosis used the wrong check.

[jch2103]

So, to be fixed in the next update?

Is there any reason the same files are being repeated in the diagnostics?

[Mario]

This has been fixed.
The files will re-appear because the same date is written to correct the problem.
But then the test will find it again.

It's just one of the many weird things with dates and computers.
Computers don't like dates before 1970 

[jch2103]

Understood. I was wondering if the diagnostics check would be updated to take this situation into account. Not a high priority, as the underlying data are OK, but I suspect I'm not the only one who is or will be working with pre-1900 faces.

[Mario]

The diagnosis will no longer flag these files.
It only occured with dates before December 1899 anyway, which not that many users use...

[jch2103]

Thank you.

[thrinn]

Great!
(For what its worth, I discovered that my problem file had indeed also a date of 18xx. By mistake, I should add, because it should have been 1989....)