Database Diagnostics causes files to become pending writeback for PersonInImage

[Tveloso]

I have recently, on a few different occasions, found a few files that were pending writeback, that I didn't expect to be pending.  In all cases, the tag needing to be written back was PersonInImage, and the files in question were usually allVersions...(although there have been at least one occasion each, where a file that became pending for PersonInImage, was either a Master, or not part of a Version Set).

I thought perhaps this might be happening during propagation (although again, a few times, non-Versions were involved), so I kept a close eye on new writebacks, filtering for any files that remained pending (Version or not), after a writeback on a given batch of files.  I didn't find any that were pending following those writebacks.  And now that I was paying attention to this, I found that some files, that I was certain were previously not pending, became pending sometime later.  In fact, even files that I had "completely finished", and were now archived on the NAS, were among the files that became pending.

It appears to be the Database Diagnostics that's causing this.  Even when it completes without any Errors or warnings, there are sometimes files that become newly pending writeback (for the PersonInImage tag).

Today I isolated a time range of files containing 13,956 Files, within which there were no files pending writeback.  I then ran a Database Diagnostics (after turning on Debug Logging), which completed with no Errors or Warnings.  Afterwards, there were 7 Files, within that scope I was watching, that were now pending for writeback, and all 7 has the PersonInImage Tag as what was pending:

   

In this case all of these files were Versions, and their Masters were not pending writeback.

Neither the Diagnosis Log, nor the IMatch Log, mentioned the OIDs of these 7 files.

There have also been times when a Diagnostics run did not create this condition, but over the past several days, it has done so most of the time.  Is there anything else I can do to help track this down?...

[Mario]

Did  you check the diagnosis and IMatch log file for related entries.
I find no reference to PersonInImage in the entire diagnosis code so this can only be a side-effect of something else.
If you write back and run the diagnosis again, does the issue reappear? If not, maybe IMatch found something that needed fixing? I don't know.

[Mario]

I see noting in the diagnosis log file.
But while the diagnosis was running, the PeopleManager in IMatch has updated metadata for a number of files. I cannot tell from the logs why. This may have caused PersonInImage to become pending when it was changed. I cannot tell this from the log file either.

[Tveloso]

I did recognize the files that became pending, as files I had worked on relatively recently.  But it was several IMatch sessions ago.

If you write back and run the diagnosis again, does the issue reappear?

I can't be certain of this, but I think that a few of the same files have come back with the condition, after a writeback and a subsequent Diagnostics run.  But for the most part, it has been different files that become pending with each Diagnostics run that creates the condition.  So a writeback usually does make the issue disappear.

I did a writeback earlier, of the 7 Files in question here, but have not run another Diagnostics yet.  I'll do that tonight, and will report back.

[Tveloso]

A diagnostics run tonight did not cause any new files to become pending writeback.

The Diagnosis Log did contain some warnings - all were Missing Keywords for Entity N File N, which were fixed.  I thought that perhaps, after that condition, another Diagnistics run might then create the pending writeback condition for the files involved in the Missing Keywords Warnings (they were all "People Keywords", which should have a corresponding PersonInImage entry), so I ran another Database Diagnostics, which completed successfully, without any warnings.  But again, no new files became pending writeback.

I'll keep monitoring this, and will report back if it should happen again.

[Mario]

If the diagnosis reports this problem, keywords you have added to a person were not applied when you assigned the person to a face. This should of course not happen.

Do you recall what you did before this warning was issued?
Changed keywords for a person in the Person Editor?
Made modifications to these keywords int he thesaurus?
Replaced a person with another person?
Removed a person from a face?
Added faces, moved faces, ...

PersonInImage is updated when you assign, remove or change persons to faces.
Maybe this is related?

If we can figure out which operation or workflow produces the diagnosis warning, I can fix it.

[Tveloso]

Do you recall what you did before this warning was issued?
Changed keywords for a person in the Person Editor?
Made modifications to these keywords int he thesaurus?
Replaced a person with another person?
Removed a person from a face?
Added faces, moved faces, ...

There were 24 of those Missing Keywords Warnings, for 7 Files.  All of them are related to a batch of 107 Files (from September of 2023) that I'm currently working on. 

These are all Versions (exactly the kind of files that become unexpectedly pending writeback), so I didn't actually work on them directly (only on their Masters).  I added Faces to all of their Masters (but I also did so with many other files, which are the same type of Version Set, and only these 7 turned up with this warning).

The Version Rule that governs this particular Version Set is configured to propagate Annotations (in addition to several selected "on-write" XMP Tags - including Keywords):

   

...and the Propagation of Annotations has already happened "in Database" (is the "in Database" propagation of annotations new in IMatch 2025?).  Perhaps that's what caused the Missing Keywords warnings?...(the "in Database" propagation didn't include the Keywords from the Person Records?...since those are done "on-write").

There have been no writebacks yet for any of these files (and they already have the correct values in PersonInImage).  I'm guessing that after I writeback the Masters of these 7 files, maybe the next diagnostics will then cause the PersonInImage to become pending?  I have already verified that these types of files do not remain pending following a writeback of their Masters.

I must leave now for most of the day, but I'll get back to this tonight, and will report back.

[Tveloso]

Unfortunately I was not successful in reproducing the pending PersonInImage condition for the 7 files that I was hoping would produce it.

Those 7 files previously had Missing Keywords warnings in a Database Diagnostics run yesterday.  The thinking was that after they were written back, that they would then show up with the Pending Writeback condition following another Diagnostics (which I have seen recently several times, for a few files, following a Diagnostics run).  But after doing the following:

• Isolate the 7 Files with the Missing Keywords warnings
  Create a scope containing only the 7 files that had the Missing Keywords warnings in yesterday's Diagnostics run.  These were all Version files.
  
• Send these 7 and their Masters to a Result Window (F4,S)
  This Result Window now contained 14 Files, all of them Pending Writeback (for many different tags - including Keywords, Location, Regions, PersonInImage, etc.)
  
• Writeback Masters
  Set the Don't Group by Master option (to make the masters accessible in this result window), and Control-Click just the Masters, and do a Writeback.  None of the 14 Files were now Pending Writeback (as expected)
  
• Run Diagnostics

...no new files became pending for writeback...(the expectation was that the Versions would become pending for PersonInImage, following the Diagnostics.

This was a little out of sequence from my usual workflow though...(and perhaps it takes a specific sequence of events for the issue to manifest?).  Ordinarily, I would have written back those files before a Diagnostics would have caught the Missing Keywords condition (and the on-write propagation would have established those Keywords in the Versions).  Perhaps it's then that the PersonInImage pending condition gets created?

I'll keep monitoring this - it has happened somewhat regularly recently (although like now, has also not happened when I was thinking that it might), and I'll report back if I encounter another instance of it.

[Mario]

Fuzzy/random issues like this, happening only with installation (as far as I know yet) are always tough to tie down.

I can fix what I can reproduce here. I've played around with this yesterday, using version rules that propagate annotations and keywords, running diagnosis after each person assignment, person exchange, dropping and re-adding faces and assigning persons. The problem it has not happened so far. I use a small database so diagnosis is quick. I can produce the error by manually removing keywords from a file which has face annotations and persons assigned. But that's of course a correct warning then.
This is probably something were specific to your workflow, version rule and whoknowswhat...

[Tveloso]

Yes, this very likely is something specific to my setup/workflow, so it's probably not something that you should spend any more time on.

I did find that it was exactly those 7 Files (that had turned up with Missing Keywords in that prior Diagnostics run), that then became pending for writeback (for PersonInImage) on a later Diagnostics (which did not call out those files at all).  That didn't happen when I "wanted it to".  In my prior test, the issue didn't surface for those files following a Diagnostics run.  It was not until I had "completely finished" the batch of files that contained those 7 (I may have added more Keywords - in addition to the "Person Keywords" that the files already contained), that the issue then appeared.

I'm guessing that it's somehow related to my Version Rule that propagates Annotations (I'm guessing not many users do that - as it's usually not a proper thing to do).  That Rule also propagates XMP Keywords (along with a few other XMP tags), and since Annotations are propagated in-database, while Keywords are propagated on-write, it makes sense that a Diagnostics run in between when faces have been added, and when the file has been written back, would identify the Missing Keywords condition.

This falls squarely into the realm of "Doc, it hurts when I do that"..."well then, don't do that".  I'm guessing that if I were to time my Diagnostics runs, such that there are no newly processed files, still in a Pending Writeback state, this issue will not Manifest.

There are still questions on this though...(I'm sure that the actual issue is not as simple as I've made it out to be).  Just for my own edification I might still try to get a more definitive explanation for when/how this happens. 

One question that I arrived at right away is: why did this happen with only 7 files.  Those files were part of a "current batch" of more than 100 files that I was working on, and I'm sure that I added faces to many more than just those 7.  I did notice that for these 7, at least one of the faces I added in each of them became a "true face", and not a Manual Annotation.  Perhaps that's a contributing factor?...(but here again though, I think that there were other files in the batch for which that was true - which didn't have the issue).

I'll keep paying attention to this as I work in IMatch, but even if I manage to come up with a proper repro case, it's still probably not something that really needs to be "fixed".  The condition can be easily detected, and addressed by the user.

[Mario]

Probably. There are 1000s of ways to shoot yourself in the foot when it comes to metadata.
As I said, I tried to reproduce this already, with no success.
Propagating annotations is something very rarely done, unless you have identical images (e.g. versions directly derived from the master without changing dimensions or crop).

Propagating annotations (face annotations) does not propagate keywords.
This way things can be handled more flexibly, the user can select to propagate only the annotations or also propagate keywords, as needed. One could argue it should be different, but that's how it is implemented for the past couple of years and so far it worked.


As I said, I tried to reproduce this.
If you propagate annotations (which is done in database) and then run a diagnosis, the diagnosis will report "missing" keywords, because the annotations have been copied, but the keywords will only be "there" after writing back. This is expected. The diagnosis will just add the missing keywords.