Moto G5 Plus -- Recorded Video Has Incorrect Timestamp. Pictures are fine though.

  • Thread starter Android Central Question
  • Start date
A

Android Central Question

Hi friends. I have a Motorola G5 Plus. The date/time on the phone is correct, however when I take videos, I noticed the EXIF data when read on my computer is set ahead several hours. Pictures, however, are just fine.

Below is an example output when I read the EXIF data from a sample video.

administrator@vault:/mnt/vault/unsorted_pictures$ exiftool -time:all -s VID_20171225_214456599.mp4
FileModifyDate : 2017:12:25 21:47:02-05:00
FileAccessDate : 2017:12:25 21:47:00-05:00
FileInodeChangeDate : 2017:12:25 21:47:02-05:00
CreateDate : 2017:12:26 02:45:00
ModifyDate : 2017:12:26 02:45:00
TrackCreateDate : 2017:12:26 02:45:00
TrackModifyDate : 2017:12:26 02:45:00
MediaCreateDate : 2017:12:26 02:45:00
MediaModifyDate : 2017:12:26 02:45:00

administrator@vault:/mnt/vault/unsorted_pictures$ date
Mon Dec 25 21:47:23 EST 2017

The "CreateDate" field, and related fields below it, is what's wrong. As I type this message, my clock says Dec 25th 10:04 PM. Meanwhile, in the second line you can see I ran the "date" command, yielding the current date/time of the computer. 21:47 translates to 9:47 PM. The FileModifyDate is shown correctly, but the CreateDate field is not, citing Dec 26th at the 2 AM hour. Clearly it's not December 26th yet, so... something isn't lining up properly here.

It's worth noting that the CreateDate field is the one taken when the image/video was captured. Even if I edit this exact file, it will not change the CreateDate field. Instead, editing files only update their FileModifyDate field, which is fueling this confusion even more as CreateDate should not be affected -- yet like I said, somehow, it's writing a future time, ahead by approximately 5 hours.

I cleared the data/cache for the camera app, no dice. I also installed a separate camera app from the Play Store to compare against the default Camera app. No change.

Any ideas?
 

ManiacJoe

Trusted Member
Aug 5, 2015
6,326
3
38
Visit site
Looks like there is two things going on.
1. The file system dates have a timezone marker while the EXIF data is in UTC time. They do match if you do the math (-5:00 = EST).

2. The file system dates are tracking the "last changed" times while the EXIF data is recording the "capture" time, assuming the video was 2 minutes long. The EXIF data for the "modified" dates will change if you edit the movie in an editor.
 

JaSauders

Active member
Aug 28, 2012
27
2
0
Visit site
Looks like there is two things going on.
1. The file system dates have a timezone marker while the EXIF data is in UTC time. They do match if you do the math (-5:00 = EST).

2. The file system dates are tracking the "last changed" times while the EXIF data is recording the "capture" time, assuming the video was 2 minutes long. The EXIF data for the "modified" dates will change if you edit the movie in an editor.

Hi there. OP here. Sorry wasn't logged in when I first made the post.

I figured it wasn't so much a legitimate problem or a bug of the phone or Android version I'm on (7.x), but it still made me raise an eyebrow because it wasn't expected behavior. At least, I wasn't expecting it.

Do you have any idea how I would be able to change this behavior? I find it a bit strange that my photos are recorded, effectively, with one "timezone/set time" that gets applied to the CreateDate marker while videos are created with a different "timezone/set time" to the same marker. I would think it'd be all or nothing.

Truth be told the exact time doesn't matter much, it's just the fact that the time is off by enough of a range that it could flip the file to the next day, thus changing the way my photos/videos get automatically sorted. I do have an idea in mind as to how I could script making this change automatic on my server, but I'd prefer to focus on getting this changed locally on my phone since that's where this particular situation is spawned from.

Thanks for your help with pointing this out. If you or anybody else would have any idea how I could change the exact time settings for recorded video I'd greatly appreciate it. :)
 

JaSauders

Active member
Aug 28, 2012
27
2
0
Visit site
I felt compelled to come back here as a follow up in case anybody in the future digs up this question.

I asked over at AskUbuntu since while I'm using Android in this scenario, I'm also using Ubuntu (specifically Ubuntu Server with where my media gets stored) in this setup. Again, I'm using exiftool to automatically sort my photos and videos* in an organized fashion on my server.

* = exiftool is predominantly a picture-based sort utility, however its support is pretty extensive and does dip into that of reading metadata from other file types as well.

I learned that exiftool takes a conservative approach when it comes to dealing with video timestamps as there's not really a fixed standard. Smartphones are internet connected and thus always updated with time zone, date, time, etc., but digital cameras are not. As a result a lot (most) digital cameras seemingly use UTC for their time recording. A lot of that has drifted into today's usage despite it being less of an issue.

Using exiftool, you can pass a QuickTime flag which will read the local time back from the video files instead of the UTC time. This flag is -api QuickTimeUTC. So if you want to read back all time stamps to a video file, it'd be:

exiftool -api QuickTimeUTC -time:all -s videofilenamehere.mp4

Overall, the metadata is there. It's just exiftool takes a more conservative approach and provides the times "as is", but when this flag is added, it commands it to show the local time instead. I simply added that to my script when sorting through this media and everything seems to run fine.

Truth be told, I still find it strange that photos would get recorded with local time whereas videos get recorded with UTC time, but I've compared several Android devices and found that to be consistent with each one of them. But hey, at least in this particular context I think this issue is in pretty good shape now. I figured if what I learned helped me perhaps it could help others, so, there ya go. :D
 

Members online

Trending Posts

Forum statistics

Threads
943,267
Messages
6,918,094
Members
3,158,925
Latest member
itay85