Quicktime MD import dependent on file extension

[sdb]

I have a lot of mp4 video files which have metadata that is not visible in the Metadata Browser (or usable for data-driven categories).  The odd thing is that if I rename the files to have a .mov extension instead of .mp4 and then reload the metadata, the missing data appears.  (In fact it seems to stay there even if I then rename the file extension back to .mp4.)

To be specific, in the .mp4 files I have tested, the Quicktime ItemList section contains the following fields:
CreationTime
Encoder

If I rename to .mov, this section expands to include:
CompatibleBrands
ContentIdentifier
CreationDate
CreationTime
Encoder
GPSCoordinates
MajorBrand
Make
MinorVersion
Model
Software

Obviously exiftool reports the same metadata in both cases.

Is this expected behaviour, and can I change it using configuration options?

To give some context: I have a workflow involving using ffmpeg to re-encode .mov videos from Apple devices so as to compress them, make them more suitable for web access and avoid the Apple proprietary mov format (at least I think that's what I am doing - I'm no expert), while preserving the metadata.  This results in mp4 files.  But I want to use the ContentIdentifier tag to classify Live Photos.  Because of the issue mentioned above, I can't do this unless I mess about with file renaming, and I don't know whether having .mov files would have any adverse effects down the line.

[Mario]

I have never heard something similar like this.

IMatch just tells ExifTool to extract the metadata (when the file format is a file format reported as supported by ExifTool) and then ingests the output provided by ExifTool.
IMatch does not treat .mov or .mp4 files in different ways, except that IMatch by default embeds XMP data in .MP4 files - because this is how the industry standard has evolved.
File extension should not matter. ExifTool does not look at the extension but at the actual data in the file.

Tip: You can see all metadata imported in the Metadata Panel when you switch to the Browser layout.

Note that IMatch by default skips thousands of tags which are not meant to be viewed or processed by humans. This keeps a lot of junk out of the database.
In rare cases, where users need to import a certain proprietary tag or maker note, they can enable the tag(s) in the The Tag Manager.

Apple's QuickTime format is a moving targetand it exists in many varieties and flavors. Apple has doctored a lot with QuickTime metadata over the years, and buggy camera firmware and buggy applications modifying QuickTime tags have added to the mess.

That being said, without a sample file which exhibits this behavior, there is little I can do.
Please upload a .mov file where ExifTool fails to extract QuickTime data and post (or send me) a link (with a link back to this topic, I get many emails per day).
If I have a sample video here, I can tell you more.

Exif

[sdb]

Well this is weird.  I made a serious mistake by turning on background processing which wiped a lot of metadata I needed, so I restored all my image files from a backup and did a "force update" on the entire database.

This time hundreds mp4 files ended up with the full set of metadata.  I'll have to investigate further, but as far as I know everything is OK now.

I had incidentally previously tried 'force update' several times with the individual mp4 files but it made no difference until I did the restoration.

[Mario]

How could background processing delete metadata?

By default, the Background processing options tell IMatch to automatically import new and updated files (recommended).
Immediate write-back for metadata changes is off, so IMatch is not forced to update all affected files when you make a small change. You can then explicitly tell IMatch when to write-back (recommended).
When a write-back deletes metadata, there is usually a problem in the source file and it often requires a considerable amount of time and analysis to figure out what is wrong.
The same applies to file relations (if you use them). This is an advanced features and propagating the wrong data from master to versions can cause problems.

As I said, when importing metadata, IMatch does not differentiate between .mov and .mp4 files - it ingests whatever ExifTool delivers and what has not been marked as "skip" by the Tag Manager.
IMatch always imports QuickTime by default, since it searches a multitude of potentially available QuickTime tags to figure out the best timestamp to use for the file. Among other things. See How IMatch uses Date and Time Information for details.

[sdb]

How could background processing delete metadata?

To be more accurate, the metadata was overwritten, not deleted.  I have many photos which were scanned and which contain DateTimeOriginal dates which I individually added over a period of years using exiftool.  However iMatch preferentially uses the XMP dates created by the scanner, and these dates overwrote my DateTimeOriginal dates when I triggered background write-back.

The reason I turned on immediate/background write-back is that when I first created the iMatch database, many hundreds of images were flagged as awaiting write-back in order to put the Picasa-created face-recognition data into the appropriate XMP fields.  I assume the overwriting of the DateTimeOriginal fields was a side effect of these updates.
( I just did a test on a backup database with an image which was flagged as awaiting update of the PersonInImage field.  Sure enough:
ExifIFD:Date/TimeOriginal was overwritten, and Composite:Date/TimeOriginal was created with the XMP date.  However, a new XMP-exif:Date/TimeOriginal tag was created and this preserves the date I had originally added.)

Strangely, after the backup restoration and the "forced-update", I no longer have these "awaiting write-back" flags (even though the PersonInImage field hasn't yet been created).  Maybe I should wait.  Or perhaps wipe the database and start again.

What with this and the mysterious mp4/mov behaviour, it seems likely I don't fully understand what is going on, so I need to study the software more.

PS Ha! The "awaiting write-back" flags have reappeared!

[Mario]

IMatch produces the two XMP timestamps during import as explained here: How IMatch uses Date and Time Information
By default, the EXIF data is used for images. When the images already have XMP data, data is merged.
XMP contains large chunks of EXIF data as copies, and the XMP tags and their corresponding EXIF tags must always be kept in-sync. IMatch ensures that, by mapping EXIF => XMP during import, and XMP => EXIF during write-back. Embedded XMP is prioritized by IMatch, since it is considered to be added "later" than the native EXIF metadata (e.g. by the user or a processing software).

If you have used software or devices which, for some reason, have written different timestamps for EXIF and the mirrored XMP tags, or which updated only XMP but left EXIF, legacy IPTC, GPS data embedded in the file get out-of-sync with the XMP data, you might have to do some work to fix the broken metadata. Usually the first write-back in IMatch sets things straight, by mapping XMP back into EXIF, legacy IPTC, GPS, updating all digests and checksums, metadata timestamps etc.

PS Ha! The "awaiting write-back" flags have reappeared!

This is normal. When IMatch ingests files, it produces complete and high-quality XMP data from the existing metadata found in the file. Since IMatch is usually much better and "more complete" than other software, new XMP data is usually produced during the first ingest. After the initial write-back, things will have settled, all metadata is in sync and your images are happy.

If it is PersonsInImage, the IMatch AI has found new faces in your image (a process which runs in the background) or IMatch has imported existing XMP face regions but found the PersonsInImage tag being empty or out-of-sync with the actual regions. A lot of software out there does a lot of wrong or half-assed jobs with metadata. This includes software which does face recognition but does not support the full XMP data (not filling PersonsInImage). IMatch will detect and correct that.

[sdb]

Just as a postscript to this thread, I'm now pretty sure that the anomalies I saw in the metadata from mov/mp4 files was purely due to the fact that some files had only been partially processed - on creating a new file with a different extension, that file was then fully processed and revealed more metadata.

I don't know why only partial processing was done, but I have been doing a lot of experimenting so it was probably my fault.

Thaks for your help, Mario.

[Mario]

IMatch processes files in the background.
First make sure that this process is completed.
Then check the files for the yellow warning indicator (in the File Window) to determine if ExifTool encountered problems.
Check the log file to see if IMatch has logged warnings for files.

Quite often these days it also happens that whatever virus checker is installed (except Windows Defender, which does a good job) suddenly interferes and blocks ExifTool from reading or writing data. Usually, IMatch notices this and logs an error to the log file. And will tell you when you close IMatch. But not always. Sometimes it's just logged as a warning, and then you only see it when you look at the log or the ExifTool Output Panel.
This happens more often when the system is under prolonged high load, e.g. users creating their database and throwing 50K or 100K files at IMatch. IMatch runs full-throttle, processing 5, 10 or 20 files in parallel (depending on the CPU count) and this may cause stress and "stress issues"on computers. Especially Notebooks which are not designed for this. Workstation or Studio-grade PCs usually don't sweat.

Always a bit hard to tell why some files on one user's PC were not processed. Especially when the metadata was not read correctly.
Missing thumbnails usually indicate that a WIC codec became unstable after processing a couple of thousand files. See above.
Incomplete metadata is usually caused by a virus checker blocking ExifTool.