I'm running into a problem with the above and am after any insights as to what I might be doing wrong. Missing some parameter perhaps.
I've got some GOPRO videos and the device reset its date/time so I'm trying to correct these. I'm on windows if that is relevant.
I'm doing quite a few videos but wrote a little CMD file to show the actual problem. Sometimes it works and sometimws it doesn't. That is really the problem. It seems unreliable.
Here's the output from the script. You can see I want to shift the time "+06:10:02 13:00:00" but on this occasion it used "+06:10:01 13:00:00" instead. I ran it a second time and it worked as required.
Run 1
-----
copy "Z:\Photos\GoPro3\2018\2018_11_03\GOPR0208.MP4" "Z:\Photos-#Comp\#2-GOPR0208.MP4"
1 file(s) copied.
C:\#Links\Exiftool\exiftool -a -s -m -ee -G0:1 -api QuickTimeUTC "Z:\Photos-#Comp\#2-GOPR0208.MP4"
-CreateDate
[QuickTime] CreateDate : 2012:01:01 02:41:42+01:00
C:\#Links\Exiftool\exiftool -a -s -m -ee -api QuickTimeUTC
-FileModifyDate="2011:12:31 17:43:14+01:00" -GlobalTimeShift "+06:10:02 13:00:00" -"ModifyDate<CreateDate" -"TrackCreateDate<CreateDate" -"TrackModifyDate<CreateDate" -"MediaCreateDate<CreateDate" -"MediaModifyDate<CreateDate" -"CreateDate<CreateDate"
-Overwrite_Original "Z:\Photos-#Comp\#2-GOPR0208.MP4"
1 image files updated
C:\#Links\Exiftool\exiftool -a -s -m -ee -G0:1 -api QuickTimeUTC "Z:\Photos-#Comp\#2-GOPR0208.MP4"
-CreateDate
[QuickTime] CreateDate : 2018:11:02 15:41:42+01:00
[XMP:XMP-xmp] CreateDate : 2018:11:02 15:41:42+01:00
Run 2
-----
copy "Z:\Photos\GoPro3\2018\2018_11_03\GOPR0208.MP4" "Z:\Photos-#Comp\#2-GOPR0208.MP4"
1 file(s) copied.
C:\#Links\Exiftool\exiftool -a -s -m -ee -G0:1 -api QuickTimeUTC "Z:\Photos-#Comp\#2-GOPR0208.MP4"
-CreateDate
[QuickTime] CreateDate : 2012:01:01 02:41:42+01:00
C:\#Links\Exiftool\exiftool -a -s -m -ee -api QuickTimeUTC
-FileModifyDate="2011:12:31 17:43:14+01:00" -GlobalTimeShift "+06:10:02 13:00:00" -"ModifyDate<CreateDate" -"TrackCreateDate<CreateDate" -"TrackModifyDate<CreateDate" -"MediaCreateDate<CreateDate" -"MediaModifyDate<CreateDate" -"CreateDate<CreateDate"
-Overwrite_Original "Z:\Photos-#Comp\#2-GOPR0208.MP4"
1 image files updated
C:\#Links\Exiftool\exiftool -a -s -m -ee -G0:1 -api QuickTimeUTC "Z:\Photos-#Comp\#2-GOPR0208.MP4"
-CreateDate
[QuickTime] CreateDate : 2018:11:03 15:41:42+01:00
[XMP:XMP-xmp] CreateDate : 2018:11:03 15:41:42+01:00
What is the output of this on the original, before editing, file
exiftool -time:all -G1 -a -s file.mp4I suspect that Date/Time Shift Module→Tricky (https://exiftool.org/Shift.html#TRICKY) is involved and one of the dates being modified run into this. Specifically, the part that says
QuoteThe inconsistency is handled by shifting the first tag found with the actual specified shift,
But then, I don't know enough about the edge cases involved, so this is just a guess.
StarGeek has the answer, but this is a variation of the problem I haven't seen before.
The issue is that the tags from the source file are extracted and shifted even if they aren't being used, and the order in which the tags are processed is random. And I'm guessing that there are some vastly different date/time values in your file. A one day difference can happen (for example) if one more leap year is included in one of the shift ranges. I'll have to think about this more to see if there is a way to fix this issue better. For now, if you apply the time shift in days instead of year:month:days then it should behave as you expected. ie)
exiftool -api globaltimeshift="+2497 13:00:00" ...
- Phil
I'm working on an enhancement for version 13.03 to allow a tag to be specified for the start date as a way to work around this issue:
GlobalTimeShift
Time shift to apply to all extracted date/time PrintConv values.
Does not affect ValueConv values. Value is a date/time shift
string (see Image::ExifTool::Shift(3pm)) with a leading '-' for
negative shifts, or a tag name with option group prefix followed
by '+' or '-' then the shift string. Default is undef.
Note: When specifying a number of months and/or years to shift,
the tag for the starting date should be specified so the number
of days can be determined unambiguously. For example:
'createdate-1:0:0 0:0:0' - shift back by the length of the
year before the CreateDate value
'xmp:createdate+0:2:0 0' - shift forward by the length of
the 2 months after XMP:CreateDate
If the starting tag is not specified, or the specified tag
doesn't exist, then the shift is calculated based on the first
shifted tag.
- Phil
Working more on this, I have added a patch to check which tags are being copied and to use the first date/time tag from these to determine the time shift, which should make your command behave as expected, as is.
- Phil
Thanks for replying. Answering the question from Stargeek "What is the output of this on the original, before editing, file"
C:\#Links\Exiftool\exiftool -time:all -G1 -a -s "Z:\Photos\GoPro3\2018\2018_11_03\GOPR0208.MP4"
[System] FileModifyDate : 2011:12:31 17:43:14+01:00
[System] FileAccessDate : 2024:11:12 14:43:58+01:00
[System] FileCreateDate : 2019:05:11 18:47:02+02:00
[QuickTime] CreateDate : 2012:01:01 01:41:42
[QuickTime] ModifyDate : 2012:01:01 01:41:42
[Track1] TrackCreateDate : 2012:01:01 01:41:42
[Track1] TrackModifyDate : 2012:01:01 01:41:42
[Track1] MediaCreateDate : 2012:01:01 01:41:42
[Track1] MediaModifyDate : 2012:01:01 01:41:42
[Track2] TrackCreateDate : 2012:01:01 01:41:42
[Track2] TrackModifyDate : 2012:01:01 01:41:42
[Track2] MediaCreateDate : 2012:01:01 01:41:42
[Track2] MediaModifyDate : 2012:01:01 01:41:42
I'll go try Phil's "days only" suggestion now.
I was going to write Phil's suggestion didn't work but then noticed it was consistently giving "2018:11:02" so (after trying to work it out manually and getting different results) I put the two dates into an excel spreadsheet and it gives 2498 as the difference. Using this value it now consistently gives "2018:11:03".
So thanks very much Phil for this workaround. I can certainly use this.
In fact, I've just run it against all 9 files for this particular day and it has worked perfectly.
Sorry. Looks like I calculated the wrong number of days.
- Phil