Broken Timeline - "Rebuild Timeline" crashes

[rreyer]

The timeline of my DB seems to be broken, the sorting is messed up.

When I start "Database -> Database Tools -> Rebuild Timeline..." iMatch works for some seconds and then comes to a halt (0% activity, never comes back).

Is there anything that I can do?

[Mario]

Never had any reports about a broken Timeline. 
How is the sorting messed up? Can you show a screen shot of the Timeline View? 

After which operation did the sort oder change?
Have you maybe changed any timeline option, like "Show current year on top"?


The Timeline is based on the global {File.DateTime} IMatch maintains for each file (based on "Date Subject Created" for images). The rebuild option is only for situations where users change options which affect File.DateTime, e.g. time zone offsets and similar.

The attached log file seems to be from a normal start, nothing related to the timeline is logged. it ends when IMatch is loading the database. Note that the BACKUP log is the one from the last IMatch session, not from the session where you experienced any issues.

I would expect to find a PTR_MSG_DB_TIMELINE_REBUILD entry when the timeline rebuild is started.



I have successfully rebuilt just now the timeline in a 40,000 and a 100,000 files database. Takes only a few seconds. No problems.

[rreyer]

Ok, here is a fresh log file.

The main trouble is with .MOV files (Canon, Apple) which usually display the correct date/time, but the sorting doesn't match that, they are sorted by some other date/time.

The situation got worse when I tried to shift time of a whole bunch of images and .MOV to US PDTimezone. In the TimeWiz I set a different timezone which *displays* the correct result time - but the result on the file is *not* correct and I have to also shift the time.
While the images worked ok, the MOVs went all crazy, display the correct DateTimeOriginal, but are sorted with their old times.
Even worse, the sorting is different depending on the view (Timeline vs. Categories - same sort profile).
That happend with files from 2012 which I just need to have in the correct order.

I'm not sure if I can reproduce the thing in a sandbox with just a few files.

[Mario]

OK, to make sure we understand you correctly:

The order of the nodes in the Timeline View is correct. You're talking about the sort order in File Windows for movie files.
Rebuilding the Timeline would not change that at all. It does not change metadata.

Which sort profile do you use? One of the default profiles or one you have made yourself?

I understand that you are trying to manipulate timestamps in video files. Can be really complicated and somewhat risky.

FIRST: BE AWARE that metadata mess in video files is much worse than metadata mess in images.
Every device, Apple and their mother cook up different schemes to store date and time in video files.
Also, video files can have multiple streams, with different tracks, each with it's own timestamp.

As described in How IMatch uses Date and Time Information IMatch looks at a wide range of timestamps in video files in order to produce the global File.DateTime timestamp. And this timestamp is the base for all default sort profiles.

Make sure you have read that help topic before continuing.

You can see the contents of this timestamp and it''s variations using these variables in the VarToy:

DT: {File.DateTime}
DT: {File.DateTime.TZO}
UTC: {File.DateTime.UTC}
LT: {File.DateTime.Local}
LT: {File.DateTime.Local.TZO}
Org: {File.DateTime.Original}
Org: {File.DateTime.Original.TZO}

I understand that you have used the TimeWiz to change time stamps. Which tags did you change? The default XMP tags IMatch uses, or some other timestamps. There are about 10 or more timestamps for video files. Most don't work with more than one vendor.

Please give us some details about

a) the contents of the "Create Date" and "Date Subject created" for a problem video fie
b) the contents of the above variables
c) the settings you have used in TimeWiz
d) the results of your changes to a) and b)
e) download linke for a sample video file with this problem

This gives us a minimum of information to work with.

Even worse, the sorting is different depending on the view (Timeline vs. Categories - same sort profile)

I don't thin this can happen. The same sort profile will always sort the same files in the same order, in dependent of the File Window you are in. Double check that the same profile is used, the reverse option is off and that there are no stacked files hidden or shown differently in your File Windows.

[rreyer]

Rebuilding the Timeline would not change that at all. It does not change metadata.

Well, rebuilding the timeline freezes iMatch.
That was the reason for my bug report.

You can see the contents of this timestamp and it''s variations using these variables in the VarToy:

Here is a screenshot of what I see:
- both files were treated with TimeWiz together: set the timezone to -8, subtract 9 hours (coming from CET)
- the JPG on the left is taken LATER than the MOV on the right (numbering)
- the current sorting is Date/Time Original
- download the JPG at https://drive.google.com/file/d/1OERpdEtzJ_0493pR9y_51AT3X7s6OLEK/view?usp=drive_link
- download the MOV at https://drive.google.com/file/d/1qQunV3iX7Sq0cFYQOGYLwizR_EnipdjJ/view?usp=drive_link

[Mario]

Well, rebuilding the timeline freezes iMatch.
That was the reason for my bug report.

I have successfully rebuilt the timelines for5 databases. No other user has ever reported a similar problem.
I would probably need your database here in the lab to see if I can reproduce this or if this is something that happens only on your computer.

All logs you have attached so far show a normal IMatch start. The "Refresh timeline prompt" was not shown, and this is shown before the timeline is updated. 

Switch IMatch to debug logging via Help menu > Support.
Run the Refresh Timeline command.
If the problem reappears, secure the log file by copying it before restarting IMatch. ZIP and attach.
I should then see that the time line update is starting and what it does, where it stalls.

In your screen shot, I see only the "Date Subject Created" for the MOV file, and it matches File.DateTime and what's shown in the thumbnail panel. For the JPG File.DateTime matches what's shown in the thumbnail. So this looks good at least.

- the current sorting is Date/Time Original

This is not a standard sort profile. How do you have configured it? Which tag do you use? One of these perhaps?
Composite\MWG-DateTimeOriginal\DateTimeOriginal\0
Exif::Main\36867\DateTimeOriginal\0
XMP::exif\DateTimeOriginal\DateTimeOriginal\0

I cannot download the files provided. They require a login for Google Drive which I don't have.
Make sure to make the links public and then post here again.

[rreyer]

I have published the files, you should now have access.

JPG: https://drive.google.com/file/d/1OERpdEtzJ_0493pR9y_51AT3X7s6OLEK/view?usp=sharing
MOV: https://drive.google.com/file/d/1qQunV3iX7Sq0cFYQOGYLwizR_EnipdjJ/view?usp=sharing

------
I have 25 sort profiles in that list, and I'm sure I've done 5 of them.

That sort profile (Date/Time Original) uses
- composite/DateTimeOriginal
- XMP::exif/DateTimeOriginal
- File Name (Smart)
------

Here's a new log file with Debug on.
It ends with the command to rebuild the timeline

[Mario]

- composite/DateTimeOriginal 

This tag, like all Composite tags, is created on-the-fly by ExifTool during import. Composite have many potential source tags and I don't know how Phil fills it for videos.

XMP::exif/DateTimeOriginal

Why do you use two date and time tags in a Sort Profile?

Have you looked at the contents of these tags in the Metadata Panel?  What you expect?

XMP::photoshop\DateCreated\DateCreated is linked with XMP::exif\DateTimeOriginal\DateTimeOriginal but IMatch produces File.DateTime from Date Subject Created, not DateCreated, so there might be a difference.

Was this the tag you have manipulated in TimeWiz?

[Mario]

My findings:

MOV

Create Date 2012:03:08 18:44:47+01:00
Date Subject Created 2012:03:08 18:44:47+01:00
Date/Time Original 2012:03:08 18:44:47+01:00

JPG

Create Date 2012:03:08 17:52:13-08:00
Date Subject Created 2012:03:08 17:52:13-08:00
Date/Time Original 2012:03:08 17:52:13-08:00

A sort profile sorting by XMP::exif\DateTimeOriginal\DateTimeOriginal and File Name sorts the JPG before the MOV.


The Metadata Mechanic reports nothing relevant for the JPG and this for the MOV

Warning: [EXIF] Offset TimeOriginal missing. 'Date Subject Created' may have no time zone offset.
Warning: [EXIF] Offset TimeDigitized missing. 'Create Date' may have no time zone offset.

Warning: [XMP] [ExifIFD]:DateTimeOriginal and [XMP-exif]:DateTimeOriginal (embedded) mismatch.
Warning: [XMP] [ExifIFD]:CreateDate and [XMP-xmp]:CreateDate (embedded) mismatch.
Warning: [XMP] [ExifIFD]:DateTimeOriginal and [XMP-photoshop]:DateCreated (embedded) mismatch.
Warning: [XMP] [ExifIFD]:UserComment and [XMP-dc]:Description (embedded) mismatch.

The JPG already has a -08:00 offset.
For fun I used TimeWiz to adjsut the time zone of the MOV to -08:00. This changed the time stamps to

Create Date 2012:03:08 09:44:47-08:00
Date Subject Created 2012:03:08 09:44:47-08:00

After write-back, the two timestamps where again:

Create Date 2012:03:08 18:44:47+01:00
Date Subject Created 2012:03:08 18:44:47+01:00

not sure why. So, that's it. Something is not written correctly (IMatch sends the correct data) but somehow this fails. Must be a .MOV thing, no idea. ExifTool does not update EXIF in MOV files (I assume) and that's causing the fallback to the original timestamps, I guess.

Changing / writing XMP::exif\DateTimeDigitized\DateTimeDigitized sticks.
But when I write XMP::exif\DateTimeOriginal\DateTimeOriginal is also reset to the original value again XMP::exif\DateTimeDigitized\DateTimeDigitized

I can see in the verbose logging that IMatch is sending the proper data to ExifTool, but it does not stick. When metadata is re-imported after write-back, the old timestamps come back.

I'll put that on my 3rd-level to-do list and I will look into this again.

I suggest you try a software like the free Handbrake to re-encode the MOV into a container like MP4 and try again. EXIF data in video files is special.

[Mario]

I think I have figured it out. It is related to this very long thread from 2023, where I explain why a certain problem happened (again with movie files): https://www.photools.com/community/index.php?msg=97798

The bug fix I made at the time bites IMatch into the buttocks for the particular combination of timestamps and time-zone offsets in your video file.

I could not understand why the old times always came back after write-back. I looked at the file and IMatch had correctly written the data (with the -08:00 time zone offset) into XMP. And when IMatch re-imported the file after write-back, the data looked OK, too. But when IMatch updated the database many steps later, the XMP timestamps with the time-zone offset were reset back.

I tracked this down to the special handling / work-around for situations where camera vendors embed XMP timestamps with a time-zone offset but don't apply the same time-zone offset to the EXIF metadata in the file. For example, XMP states a time-zone offset of +04:00 but the EXIF data written by the same camera (!) does not fill out the EXIF time-zone offset tags, basically declaring the EXIF timestamps as UTC or whatever time-zone the image was taken in.

In your particular case, you add time-zone info. But ExifTool cannot modify EXIF in MOV files (only read it). So it cannot update the EXIF time stamps or add the missing time-zone offset EXIF tags. And when IMatch re-reads the metadata, it runs into the work-around and that causes the XMP timestamps to fall back on the EXIF timestamps, despite the "Keep existing XMP data" option being enabled - which is actually supposed to prevent that.

I need to re-read my comments from two years ago several times and figure out how to make a work-around for the work-around. I need to ask Phil if ExifTool cannot write EXIF to MOV files in general, or just in some cases. From the web site it looks like it can, but there are several foot notes.

So, that's it. Video metadata mess is much messier than the already messy image metadata mess.

And I have spent too much of my life time at the crap the camera vendors produce when it comes to metadata - because they give a shit. And I'm already on that boot myself now! If they don't give a shit and produce faulty metadata even after years and a dozen firmware updates, why should I?

I may look at your particular problem again when IMatch 2025 is out and everything has settled. In a couple of weeks or months.

As a work-around, I recommend using the free Handbrake software to re-encode the video into MP4. This removes the problematic EXIF data. Then copy over the XMP record from the original file. It has the interesting EXIF data in the XMP::exif namespace.