File.DateTime problem with MP4 video files

[thrinn]

Recently, I discovered that the video files I took with my Sony camera were not sorted in the correct order in comparison to ARW/JPG photos I shooted on the same trip. The File Window in question was sorted by File.DateTime. Digging deeper, I think it has something to to with yet another variant of timestamps without TZ offset. There is also another report which sounds a bit similar, but that one was never answered by the OP so I decided to create a new one.
 
Ok, let's start: When I record a video my camera produces a MP4 file together with an acompanying XML file (XML, not XMP!). The XML file contains some information about the video file. I have no idea if this is somehow "standard" for MP4 or only one of Sony's quirks, and I don't expect IMatch to pay attention to this XML file, but it is helpful because it contains the creation timestamp in a correct format:

Code Select Expand

<CreationDate value="2023-12-11T18:52:42+01:00"/>
For testing, I took a JPG (as reference) and immediately afterwards a very short video. Both were taken at 18:52 with TZ offset of +01:00 (Germany, winter time). As you can see above, time setting of the camera was correct.

When I import these files (JPG, MP4, XML) into IMatch, the JPG and also the XML are getting the correct time. The results from Vartoy are exactly the same for both:

Code Select Expand

1 +01:00                    (File.DateTime.UTCOffset)
2 11.12.2023 18:52:36       (File.DateTime)
3 11.12.2023 18:52:36       (File.DateTime.Original)
4 11.12.2023 18:52:36+01:00 (File.DateTime.Original.TZO)
5 11.12.2023 18:52:36       (Create Date)
6 11.12.2023 18:52:36       (Date Subject Created or DateCreated)
But for the MP4 file, the result is different. No TZ offset, therefore DateTime is 1h off.

Code Select Expand

1 +00:00                    (File.DateTime.UTCOffset)
2 11.12.2023 17:52:42       (File.DateTime)
3 11.12.2023 17:52:42       (File.DateTime.Original)
4 11.12.2023 17:52:42Z      (File.DateTime.Original.TZO)
5 11.12.2023 18:52:42       (Create Date)
6 11.12.2023 18:52:42       (Date Subject Created or DateCreated)I will attach the complete ECP output for the original MP4, but apparently the TZ offset is not part of QuickTime date tags, but instead stored separately:

Code Select Expand

[QuickTime]     Create Date                     : 2023:12:11 17:52:42
[QuickTime]     Modify Date                     : 2023:12:11 17:52:42
[QuickTime]     Time Zone                       : +01:00
So, my first question is: Should IMatch recognize the TZ offset in this case? If yes, it might be a bug. If not, it's BBD :-)

But either way, it should be easy to correct this using the TimeWiz app. I used the following settings, which should set the correct TZ.

This required a write-back, which I did. I then used the "Recalculate File.DateTime" function on the file, just to make sure to get the correct DateTime information.
Unfortunately, the TZ is still wrong. CreateDate and and Date Subject Created are displayed in the Metadata Panel with the correct +01:00 offset. The VarToy output has not changed. But why is File.DateTime still assuming a +00:00 offset?

Code Select Expand

1 +00:00                    (File.DateTime.UTCOffset)
2 11.12.2023 17:52:42       (File.DateTime)
3 11.12.2023 17:52:42       (File.DateTime.Original)
4 11.12.2023 17:52:42Z (File.DateTime.Original.TZO)
5 11.12.2023 18:52:42       (Create Date)
6 11.12.2023 18:52:42       (Date Subject Created or DateCreated)
Therefore, my second question is: How can I force the correct TZ to the MP4? Am I doing something wrong with TimeWiz? Just for the record, I find only a Create Date in the ECP output, not a Creation Date. So the default of taking the CreateDate timestamp in Quicktime files should be ok.

I can not attach the files here due to size limitations, but you should be able to access all files here. The folder contains the original MP4, the MP4 after using TimeWiz, the corresponding ECP output files and, just for reference, the XML and JPG. The videos are just black (I didn't take the lens cap off).

[axel.hennig]

When I use VarToy-app on the file "C0010 - after TimeWizard.MP4" I get:
{File.DateTime.Original.TZO}: 11.12.2023 18:52:42+01:00

This seems to be correct and differs from what you wrote in your post.

[axel.hennig]

Hi Thorsten,

now I was able to reproduce your problem.

Steps to reproduce
1. Take the video "C0010 - Original.MP4" and use TimeWiz in the way shown in your screenshot.
2. Use VarToy and look at {File.DateTime.Original.TZO}. This shows 17:52 (wrong)
3. Close DB
4. Copy (not move) the video "C0010 - Original.MP4" to a folder not managed by IMatch
5. Open DB
6. Delete the video "C0010 - Original.MP4" (using IMatch functionality)
7. Move the video from step 4. back to a folder managed by IMatch and import that video
8. Use VarToy and look again at {File.DateTime.Original.TZO} (now correct)

Maybe IMatch is using some caching for VarToy and this one is not updated?

Seems to be a bug for me.

[thrinn]

Hi Axel,
thank you for checking! I did not try to close and reopen the DB, so this might be a hint.
Have to try it out later on.

[axel.hennig]

Be careful Thorsten, just closing and reopening the DB does not solve the problem. You have to save the video somewhere "outside" of IMatch, delete it in IMatch and re-import the "outside"-version.

Follow the steps I've described above.

[Mario]

Where can I download this MP4 file? Did I miss a link somewhere?

IMatch does not do anything special with the XML file. Probably this XML file is something SONY made up. It's not like MP4 files can hold a full-build XMP record or anything. Which could hold all dates and times and time-zone offsets...

I don't think IMatch yet looks for time zone offsets outside  the standardized EXIF data or existing XMP time stamps produced by ExifTool and read by IMatch.

Attach the MP4 or send me the file with a link back to this thread.

[axel.hennig]

Link from the first post (Thorsten): https://magentacloud.de/s/GDj4Tww8HBABtrw

[Mario]

Strange. I don't see this link anywhere, except in your reply.

So, my first question is: Should IMatch recognize the TZ offset in this case? If yes, it might be a bug. If not, it's BBD :-)

IMatch currently checks only various EXIF tags to determine the time zone offset when ExifTool does not include any time zone designation in the data returned (as in this case).
I shall look into this and also check this QuickTime tag when there is no other source for a time zone offset.

Therefore, my second question is: How can I force the correct TZ to the MP4?

Should work automatically, since IMatch detects and prefers time zone information stored in the XMP DateSubjectCreated and DateCreated values. But this is a video, and with video files there are many special cases, depending on the video container format and the streams included.

I will play with this for a bit and let you know.

[axel.hennig]

Strange. I don't see this link anywhere, except in your reply.

Maybe it's time for a new 16K monitor 

It's in the first post, more or less at the end behind the word "here".

[Mario]

Ah, I see. Jeez.
Folks, keep in mind that I often use the community on my smart phone.
Maybe put something like "Download here" in a separate paragraph so poor old Mario gets it.

[Mario]

I have added support for checking the QuickTime timezone tag for the next release.

I've tried to search the QuickTime documentation (https://developer.apple.com/documentation/quicktime-file-format) but could not find anything about the time zone tag. It's actually hard to find anything in that doc. Or maybe it's just me.

I've found various discussions about the somewhat flexible time zone handling in various QuickTime processing applications and Apple tools. And Ive found an knowledge base article which discusses a lot of points for QuickTimeat great length.

Phil once mentioned that QuickTime:CreateDate is in ISO 8601 format and may contain a time zone segment. I have not encountered this yet. IMatch treats this tag, if used, the same as the other 12 (!) QuickTime tags it checks for usable date and time information (nothing is really mandatory with QuickTime in this regard).

If IMatch detects a filled date and time tag in QuickTime and parses it but finds no time zone, it checks for the QuickTime::TimeZone tag, applies it and parses the date again.

For the MP4 file in this thread, IMatch now produces (in my German +01:00 time zone):

Code Select Expand

File.DateTime:  11.12.2023 17:52:42
File.DateTime:  11.12.2023 17:52:42+01:00
UTC:            11.12.2023 16:52:42
LocalTime:      11.12.2023 17:52:42
LocalTime:      11.12.2023 17:52:42+01:00
Original:       11.12.2023 17:52:42
Original:       11.12.2023 17:52:42+01:00
which is correct, since the File has a +60 minute time zone offset.

Question 2:

ExifTool documents most QuickTime tags, including time zone as non-writable.
But IMatch prefers XMP.

When I change the date subject created (and create date) for the MP4 file in the MD panel or via Time Wiz to

2023:12:11 17:52:42+04:00

and write-back, these time stamps are persisted in the XMP record embedded in the XMP:

Code Select Expand

[XMP-exif]      Date/Time Original            : 2023:12:11 17:52:42+04:00
[XMP-photoshop] Date Created                  : 2023:12:11 17:52:42+04:00
[XMP-xmp]      Create Date                    : 2023:12:11 17:52:42+04:00
[XMP-xmp]      Metadata Date                  : 2023:12:12 18:27:42+01:00
[XMP-xmp]      Modify Date                    : 2023:12:12 18:27:42+01:00
and the various time stamps show as:

Code Select Expand

DT: 11.12.2023 17:52:42
DT: 11.12.2023 17:52:42+04:00
UTC: 11.12.2023 13:52:42
LT: 11.12.2023 14:52:42
LT: 11.12.2023 14:52:42+01:00
Org: 11.12.2023 17:52:42
Org: 11.12.2023 17:52:42+04:00
This is persistent. Removing the file from the database and adding it again shows the same values with the +04:00 offset.

[thrinn]

Folks, keep in mind that I often use the community on my smart phone.
Maybe put something like "Download here" in a separate paragraph so poor old Mario gets it.

I apologize - rereading my own post, the link is indeed hard to find. Will do it more prominently next time.

I have added support for checking the QuickTime timezone tag for the next release.

Mario, thank you for the outstanding support - that's great. I do not much with videos, hence I am not familiar with the related "even bigger metadata mess".
I will make some further tests when the next update is out.

I've found various discussions about the somewhat flexible time zone handling in various QuickTime processing applications and Apple tools.

"Flexible" is a nice term for "they simply can't do it right" . Or, if not "right", at least "consistent".

[axel.hennig]

Hi Thorsten,

I would be interested if you are able to reproduce what I wrote in my post with the "steps to reproduce". Just if you have some time to test.

[thrinn]

I would be interested if you are able to reproduce what I wrote in my post with the "steps to reproduce"

Steps to reproduce

1. Take the video "C0010 - Original.MP4" and use TimeWiz in the way shown in your screenshot.
2. Use VarToy and look at {File.DateTime.Original.TZO}. This shows 17:52 (wrong)
3. Close DB
4. Copy (not move) the video "C0010 - Original.MP4" to a folder not managed by IMatch
5. Open DB
6. Delete the video "C0010 - Original.MP4" (using IMatch functionality)
7. Move the video from step 4. back to a folder managed by IMatch and import that video
8. Use VarToy and look again at {File.DateTime.Original.TZO} (now correct)

What we want to test here:
Does manipulating the TZ with TimeWiz for the given MP4 is properly recognized by IMatch? We suspect that File.DateTime is not updated or still using an older (cached?) value.

• Our starting point is a fresh import of the untouched orginal MP4. {File.DateTime.Original.TZO} shows 17:52Z.
• Modify the MP4 using TimeWiz, setting the correct Timestamp (18:52+01:00). Date Subject Created is now correct (2023:12:11 18:52:42+01:00). But {File.DateTime.Original.TZO} still shows 17:52Z
• "Unwritten Metadata" displays the following tags to write-back. Hence, I perform the write-back.
  
• After write-back, {File.DateTime.Original.TZO} still shows 17:52Z.
• Let's try to force an update of File.DateTime by a Reload Metadata rescan. {File.DateTime.Original.TZO} still shows 17:52Z.
• Same result after using a Force Update rescan.
• Last try: Use Database > Database Tools > Recalculate File.DateTime on the selected file. {File.DateTime.Original.TZO} still shows 17:52Z
• Check Axel's experience that reopening the database does not help. Indeed: After closing and reopening, {File.DateTime.Original.TZO} still shows 17:52Z
• Now close IMatch and restart it. {File.DateTime.Original.TZO} still shows 17:52Z 
• Now perform steps 3 to 7 of Axel's test process. This means: The file is removed from the database, then added as a new file again.
• And indeed, now {File.DateTime.Original.TZO} shows 18:52+01:00 which is the correct timestamp.

Conclusion: Following Axel's steps, the result is exactly as he describes.
Question: It looks as if File.DateTime is only updated when the MP4 is added as a new file to the database.
Mario, I think this it not the expected behaviour.

[axel.hennig]

@Thorsten: Thanks for checking 

[Mario]

I could reproduce and fix that, thanks.

IMatch automatically checks for modified "date subject created" and "create date" (when no date subject created exists) and compares the new date and time with the File.DateTime and if there is a change, it updates File.DateTime.

But in one branch there was a missing check for a changed time zone offset!
Since the date and time in your example does not change, only the time zone offset, the metadata tags were updated with the new time time zone offset but the time zone change was not detected and did not trigger an update of File.DateTime.

If this is urgent, you can work around this glitch by changing the time by a second when you change the time zone offset in the TimeWiz. And maybe back again, if this extra second causes an issue.

[thrinn]

If this is urgent, you can work around this glitch by changing the time by a second when you change the time zone offset in the TimeWiz. And maybe back again, if this extra second causes an issue.

It is not urgent for me, and this workaround is also good advice. As we are talking about videos, I can't even think of a situation where an one second difference in the creation timestamp would make any recognizable difference.
Thanks again!

[axel.hennig]

Since the date and time in your example does not change, only the time zone offset, the metadata tags were updated with the new time time zone offset but the time zone change was not detected and did not trigger an update of File.DateTime.

Interesting. If I try to reproduce this it works as you describe Mario with adding 1 second (and changing the TimeZone). Everything is recognized.
BUT: If I add 1 hour (and change the TimeZone) it does not work.

Worth to mention: I'm in Germany (+01:00 currently) and the plus 1 hour is exactly the difference between UTC and my current TimeZone. Maybe that's why it does not work when adding 1 hour (plus changing the TimeZone).

To be clear:

• I'm using the video "C0010 - Original.MP4" from Thorstens downloadlink
• I'm using TimeWiz to add 1 hour / 1 second and change the TimeZone by:
  
  • Shift Date and Time -> Add: 1 hours OR 1 Seconds
  • Change Time-Zone (ticked)
  • Keep original time (ticked)
  • Specify time-zone as: +01:00

[Mario]

Try without "keep original time". Or change by one hour and one second, as a work-around.
If this still happens when the new release is out, open a bug report. I then look into it for the next release.