---- Reported by shotwell-maint@gnome.bugs 2011-03-09 15:34:00 -0800 ----

Original Redmine bug id: 3314
Original URL: http://redmine.yorba.org/issues/3314
Searchable id: yorba-bug-3314
Original author: over 2 years
Original description:

Hey there,

Videos, recorded by my HTC Desire, are always recognized as recorded in the
year 1945.

This absolutely makes no sense, since pictures are recognized correctly.

The format of thos videos is 3gp.

If I can somehow help you, please comment.

What also'd be nice, is the option to edit the recording date etc manually, so
the problem could be solved that way.

Thank you :)

Related issues:
related to shotwell - 4166: [android] wrong date for video mp4 import
from some Samsu... (Open)
related to shotwell - 3300: use file mtime as timestamp if EXIF
information missing (Open)



---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:39:00 -0700 ----

### History

####

#1

Updated by Jim Nelson over 2 years ago

  * **Target version** set to _0.9_
  * **Priority** set to _High_

Could you make the video available to us? If it's too large to attach to this
ticket, please post it through a file sharing service so we can examine the
metadata.

I should note that we've seen another camera record an improper timestamp in
its movies. It may simply be a bug with the camera.

####

#2

Updated by Anonymous over 2 years ago

So, just attached some videos and a picture.

I dont think the probleme is related to the camera (mobile phone), since the
date is showed properly, clicking on details in the camera menu.

####

#3

Updated by Adam Dingle over 2 years ago

  * **Status** changed from _Open_ to _5_
  * **Resolution** set to _invalid_
  * **% Done** changed from _0_ to _0_
  * **Target version** deleted (<strike>_0.9_</strike>)

The qtdump utility shows that the date/time embedded in these files appears to
be 1945:

$ qtdump '/home/adam/Desktop/VID_20110310_110647.3gp' | strings | grep time

quicktime_dump

    
    creation_time 1945-03-09 03:06:54 (1299751614)
    
    modification_time 1945-03-09 03:06:54 (1299751614)
    
    ...

But perhaps the 3GP specification (which I haven't read) says that the
creation/modification times in a 3GP file should be interpreted differently
than in a!QuickTimefile. Or maybe this is a bug in your camera or its
settings.

####

#4

Updated by Adam Dingle over 2 years ago

I downloaded a sample 3GP from from HTC's own web site at
http://masds03.htc.com.tw/sm/basictesting.htm and examined it with qtdump:

adam@natoma:~$ qtdump '/home/adam/Desktop/H264_15f_128k_5KF_qvga.3gp' |
strings | grep time

quicktime_dump

    
    creation_time 2006-11-06 22:20:42 (3245725242)
    
    modification_time 2006-11-06 22:20:42 (3245725242)

That time looks normal. So it appears that 3GP files store their dates in the
same way as other QuickTime-based files. I now think this is a bug in your
camera or in the settings on it.

####

#5

Updated by Anonymous over 2 years ago

Ok, thanks, think you're right. Will add a bug report to my ROM (Oxygen).

While its not supposed to be posted here, do somebody know how to edit this
datum tag?

####

#6

Updated by Adam Dingle over 2 years ago

Unfortunately you can't adjust the video's date/time in Shotwell yet -- see
#3066. Hopefully for 0.10.

####

#7

Updated by Abe Pazos over 2 years ago

  * **Description** updated (diff)
  * **Priority** changed from _High_ to _Normal_

I'm having the same problem on my HTC Nexus One.

The video with a Modified date of Wed 20 Jul 2011 03:48:28 goes to the
%(=Apple-style-span){=border-collapse: collapse; color: rgb(51, 51, 51); font-
family: arial, sans-serif; font-size: 13px; }folder %%(=Apple-style-span
){=border-collapse: collapse; color: rgb(51, 51, 51); font-family: arial,
sans-serif; font-size: 13px; }/1945/07/19.%

It is possible that the date is incorrect inside the file, but I can think of
an easy workaround: the exact date and time are part of the file name

p{=margin-top: 1em; margin-right: 1em; margin-bottom: 1em; margin-left: 1.6em;
padding-top: 2px; padding-right: 2px; padding-bottom: 2px; padding-left: 0px;
background-color: rgb(250, 250, 250); border-top-width: 1px; border-right-
width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-
style: solid; border-right-style: solid; border-bottom-style: solid; border-
left-style: solid; border-top-color: rgb(218, 218, 218); border-right-color:
rgb(218, 218, 218); border-bottom-color: rgb(218, 218, 218); border-left-
color: rgb(218, 218, 218); width: auto; overflow-x: auto; overflow-y: hidden;
}.

VID_20110310_110647.3gp

So the problem could be solved in Shotwell, or wait for it to be fixed by
Google / Android, which may take very long or never happen.

Is there any chance we could have the date being read from the file name or
from the file creation date?

####

#8

Updated by Thomas Novin over 2 years ago

That workaround doesn't work on my phone with the same problem. My video files
are just called VIDEONNNN.3GP.

More details on my post to the ML here:
http://lists.yorba.org/pipermail/shotwell/2011-July/002574.html


####

#9

Updated by Abe Pazos over 2 years ago

I suggested "read from the file name or from the file creation date".

So we could say that if the exif date is previous to the invention of the
digital camera, take the file creation date. Or?

####

#10

Updated by Thomas Novin over 2 years ago

That would work, when you import the files from the phone they will under
normal circumstances always have the correct date.

On 3gp-import:

if date.year = 1945 ; then use file date instead; fi

:)

####

#11

Updated by Alexey Fisher over 2 years ago

I use HTC Desire and this bug do not affect me, my Timestamps are displayed
correctly. The reason of this timestamp problem is an epoch problem. The time
used in "brocken files" based on unix time, also seconds sinece 1970. The time
in "correct files" based on Apple time since 1904. Looks like quictime/mp4/3gp
files normally use 1904 epoch. To convert appletime to unixe time you need
remove 2082844800 seconds, thes what libquictime and other apps doing.

Since this problemm exist i suggest to add epoch conversation, to "fix" this
files.

####

#12

Updated by Adam Dingle over 2 years ago

Abe and Thomas, could you each run the qtdump command on one of your video
files to reveal the date/time stored inside it?  You'll first need to install
it on your machine (on Ubuntu, it lives in a package called quicktime-utils).
Then run this:

$ qtdump <video-file-name> | strings | grep time

And post the output here.  Thanks!

####

#13

Updated by Abe Pazos over 2 years ago

Here is the result: http://pastebin.com/yBm6AmDv

The correct date can be seen in the file name, which matches the file time
stamp.

####

#14

Updated by Alexey Fisher over 2 years ago

Abe Pazos wrote:

bq.

Here is the result: http://pastebin.com/yBm6AmDv

qtdump read:

creation_time 1945-04-06 17:28:19 (1302190099)

if you handle 1302190099 as unixtime (not appletime) and convert to human
time:

date -u -d @1302190099

Do 7. Apr 15:28:19 _UTC_ 2011

or: Do 7. Apr 17:28:19 _CEST_ 2011


Sudennly i can't find what epoch 3gp/mp4  should use. If it is not defined,
then we have a big problem.

####

#15

Updated by Adam Dingle over 2 years ago

  * **Status** changed from _5_ to _Open_
  * **Priority** changed from _Normal_ to _High_
  * **Resolution** deleted (<strike>_invalid_</strike>)

Hm - this is odd.  It seems that several different cameras record a date of
1945 in 3GP videos.  All these cameras are made by HTC.  I think this is
probably a bug in HTC's code.  Nevertheless I'm reopening this since it seems
to be affecting a number of Shotwell users and might be worth working around.

####

#16

Updated by Thomas Novin over 2 years ago

I saw some post to the ML about someone with a Google Nexus that had the same
problem. Although the phone is actually made by HTC aswell the SW is Google-
only so I think there are other phones out there with the same problem, not
just HTCs.

####

#17

Updated by dave42 - over 1 year ago

  * **Description** updated (diff)

I can confirm the same problem with my Nexus One and Nexus S. If the problem
is on the device side, it's in Google's code.

Either way, it sure would be nice if Shotwell could handle this. There are a
lot of Android users out there. It shouldn't be too hard to recognize these
crazy dates and automatically correct them, should it?

####

#18

Updated by Alexey Fisher over 1 year ago

Search by phone neame is not good. It is possible to fix it in firmware, and
if it will be fixed say in CyanogenMod then we will get same problemm again.
But some way to fix the date for old video will be good.

####

#19

Updated by Alexey Fisher over 1 year ago

Just added report here:

http://code.google.com/p/cyanogenmod/issues/detail?id=5956

will see if we will get some response.

####

#20

Updated by dave42 - about 1 year ago

Asking for a fix in cyanogenmod is a good thing, but it has some 3 million
users, out of more than 600 million Android users today. So a fix there is
only going to reach a tiny number of people. This bug (or unusual behaviour)
exists in the base AOSP code, so it affects all Nexus devices, and any other
devices where the manufacturer hasn't reimplemented this, which we know
includes the massive selling Samsung Galaxy phones, too.

Wouldn't it make sense to help people out by recognizing and accommodating
that bug in Shotwell? You wouldn't need to search by phone name. A simple
sanity check on the value itself would suffice. For example, if the date is
before January 1, 2000, make the adjustment. That would cover us off until
2066, which seems like long enough to be worth doing.

Why not do it?

####

#21

Updated by Jim Nelson about 1 year ago

  * **Target version** set to _0.14.0_

dave42, we've considered this. It's possible the best solution here is to look
for a sane date, and if not found, use the file's modification time. We'll see
if we can get this in for 0.14.

####

#22

Updated by Thomas Novin about 1 year ago

I have Android 4.1.2 (JB, CM10) and this is still a problem. So this will
continue to be a problem with many (all?) Android-phones for many years to
come.

Edit: The workaround in http://redmine.yorba.org/issues/4166#note-19 could
probably be used to fix this for videos already imported. I will have a go at
re-writing the script when and if I get the time.

####

#23

Updated by dave42 - about 1 year ago

Jim,

Thanks for your willingness to try to fix this in 0.14.

I'd recommend not using the file's modification time, though. The metadata IS
available. The problem is just that there are two ways to interpret it:
seconds since 1904 or seconds since 1970. Fortunately, for a given value, only
one of those interpretations makes sense for the next 50 years or so.

####

#24

Updated by Jim Nelson about 1 year ago

I haven't looked at this bug in quite a while, so I might be mistaken here,
but I thought the problem with HTG was not simply that the offset was
different (I believe that's accounted for in the Quicktime metadata code), but
that it was recording a bogus date outright.

####

#25

Updated by dave42 - about 1 year ago

Jim,

The problem in AOSP that's reported to cyanogenmod (in comment #19 above) and
that I've personally experienced in two different Nexus devices is just the
offset. It looks to me that all of the comments on this bug are referring to
the same issue: they're all reporting videos dated 1945 in 2011. That's off by
66 years, which is the difference between 1970 (unix) and 1904 (quicktime).

I don't see any sign of other problems reported in this bug.

####

#26

Updated by Jim Nelson 11 months ago

  * **Category** set to _video_

####

#27

Updated by Jim Nelson 9 months ago

It doesn't look like this is getting fixed in the firmware and there's a lot
of people being burned by this. We'll add a sanity check to Shotwell to detect
old videos and correct them.

####

#28

Updated by Jim Nelson 9 months ago

  * **Assignee** set to _Lucas Beeler_

####

#29

Updated by Lucas Beeler 9 months ago

  * **Status** changed from _Open_ to _5_

Applied in changeset f6065c18d236e2b9ed9973269195bc04058227bd.

####

#30

Updated by Lucas Beeler 9 months ago

  * **Resolution** set to _fixed_

####

#31

Updated by Charles Lindsay 7 months ago

  * **Status** changed from _5_ to _Fixed_



--- Bug imported by chaz@yorba.org 2013-11-25 21:51 UTC  ---

This bug was previously known as _bug_ 3314 at http://redmine.yorba.org/show_bug.cgi?id=3314
Imported an attachment (id=261974)
Imported an attachment (id=261975)
Imported an attachment (id=261976)
Imported an attachment (id=261977)
Imported an attachment (id=261978)

Unknown milestone "unknown in product shotwell. 
   Setting to default milestone for this product, "---".
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.