Conversely we could keep a sidecar date modified in the library. This would be a little painful on upgrade because I think the system would want to 'Update Library (from tags)' for all files since the sidecar date modified would be empty.
Why should this be a problem?
Actually, I was about to suggest two additional fields, the other new field would have been a boolean field that would show if a sidecar file has ever been created or read, but then I realized that an empty "Sidecar Date Modified" field would already indicate the "boolean zero" value and if the field has a value it would indicate that a sidecar file has been created or read. Naturally MC would need to write/update the "Sidecar Date Modified" value whenever it creates a new sidecar file or reads an existing file.
Could it go like this:
1. check the Date Modified library field:
- if the media file's OS time stamp is newer => reread file info
- if the field is up-to-date => go to 2.
2. check the Sidecar Date Modified library field value
- if the sidecar file's OS time stamp is newer => reread file info
- if the field is up-to-date => do nothing
- if the field is empty => go to 3.
3. check if a sidecar file exists on the disk
- if exists => reread file info (a sidecar file is most likely added by another MC library instance)
- if does not exist => do nothing