Capture dates for MP4 files taken in a different time zone

[Rumboogy]

I am looking at using PM to manage photos and videos taken on a Nexus 5 (Android cell phone) .  The problem I am running into has to do with MP4 files.  When I ingest photos & videos I would like to view them in capture order on the contact sheet.  Essentially I want to see them in the same order as they were on the phone.  The problem occurs when the photos & videos were taken in a different time zone.  Photos have the capture time set to the local time were they were captured while MP4 files have the capture time adjusted back to my local time zone.  For example, I live in California, but visit Illinois (2 time zones away).  If I take photos & videos and then ingest them into PM when I get back, the photos all have captures times using Illinois time (which is good) while the MP4s all have capture times using California time (not so good).

Any ideas?

[Kirk Baker]

I am looking at using PM to manage photos and videos taken on a Nexus 5 (Android cell phone) .  The problem I am running into has to do with MP4 files.  When I ingest photos & videos I would like to view them in capture order on the contact sheet.  Essentially I want to see them in the same order as they were on the phone.  The problem occurs when the photos & videos were taken in a different time zone.  Photos have the capture time set to the local time were they were captured while MP4 files have the capture time adjusted back to my local time zone.  For example, I live in California, but visit Illinois (2 time zones away).  If I take photos & videos and then ingest them into PM when I get back, the photos all have captures times using Illinois time (which is good) while the MP4s all have capture times using California time (not so good).

You could try adjusting the capture times of the videos, but I don't know offhand if that will work.  Video files don't contain EXIF data like photos do.  I expect that PM is simply mapping the MP4 file's modification time onto the value used as capture time.

-Kirk

[Rumboogy]

You could try adjusting the capture times of the videos, but I don't know offhand if that will work.  Video files don't contain EXIF data like photos do.  I expect that PM is simply mapping the MP4 file's modification time onto the value used as capture time.

From further examination it appears that PM is getting the MP4 creation time from the file time (as you suggested) and that the file dates have the time zone embedded so they are adjusted back to your current time zone.  I tried using the "Adjust capture dates and times..." function in PM.  This solved the problem by creating an XMP sidecar file for the MP4 which had the corrected time.  So the lack of EXIF in MP4 can be overcome.  Of course now I have a sidecar file which adds complexity but it is a solution.

I guess you could also use the "Adjust capture dates and times..." function to change the modification time of the MP4 file and then PM would also handle the capture time correctly. 

[harvey@croze.net]

Greetings. Hope it's not too late to glean some insight and perhaps help shed some light on this MP4 issue...

I’m working with an array of various models of Reconyx camera traps in a Kenyan forest. The XR6 Ultrafire produces both JPGs and MP4s that can be captured for each episode, i.e., one JPG followed immediately by a video. In Finder, the images sort correctly on the SSD fresh from the camera. After ingest by PM, the MP4s all have a “Capture Time” that is 3 hrs greater than the true capture time; the JPGs have the correct local time, which in Nairobi is UTC+3.  Thus, when sorting the batch on the default “Capture Time” in the contact sheet, the JPGs and MP4s are all badly out of sequence making the export of precise time-series summaries impossible. (NB: *.avi files from another camera model, Hyperfire 2 Pro HP2XODG, don't exhibit the anomaly.)

The timestamp anomaly occurs apparently because PhotoMechanic changes the "capture date" on ingest.  I did an ingest test with my iMac system date set to UTC-0, that is three hours earlier than the actual Nairobi time, UTC+3.  The batch ingested were in the correct time sequence when sorted on PM’s default Capture Time option, unlike a batch ingested with the iMac internal clock set back to Nariboi time, UTC+3: all the latter MP4 Capture Times were increased by 3 hours.

It gets more complicated.  I tried a custom sort of the date-corrupted UTC+3 batch using the {datesort} variable.  The sort rendered both JPGs and MP4s in the correct time sequence, despite the fact that the IPTC data of the MP4s continuing to show the +3 hour anomaly in the IPTC data.

So question: what meta-data is PM sorting on when using {datesort}?   It’s important to know which variable has the actual time because we subsequently use those times, measured in seconds, exported into Excel tables in order to determine which bursts of photos constitute one capture event.

Many thanks if you managed to read this far.