[android] wrong date for video mp4 import from some Samsung and Android devices
Submitted by an unknown user
Link to original bug (#718293)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-09-22 14:38:00 -0700 ----
Original Redmine bug id: 4166
Original URL: http://redmine.yorba.org/issues/4166
Searchable id: yorba-bug-4166
Original author: Hubert Toullec
Original description:
The Samsung Galaxy S2 Android smartphone uses date and time to name its video mp4 files, as in the following example : video-2011-06-30-11-38-23.mp4
All its time metadata however is filled with the constant string : "1904-01-01 00:09:21"
For example :
@$ qtdump video-2011-06-30-09-07-20.mp4 | grep -i --binary-files=text _time
creation_time 1904-01-01 00:09:21 (0)
modification_time 1904-01-01 00:09:21 (0)
preview_time 0
poster_time 0
selection_time 0
current_time 0
creation_time 1904-01-01 00:09:21 (0)
modification_time 1904-01-01 00:09:21 (0)
creation_time 1904-01-01 00:09:21 (0)
modification_time 1904-01-01 00:09:21 (0)
is_timecode 0
creation_time 1904-01-01 00:09:21 (0)
modification_time 1904-01-01 00:09:21 (0)
creation_time 1904-01-01 00:09:21 (0)
modification_time 1904-01-01 00:09:21 (0)
is_timecode 0@
ShotWell 0.11.2 takes account of the metadata timestamp to import the video, so dated event and storage dir is 1904... !
I did some video imports from this phone some weeks ago, and, as far as I can remember, I think dated event and storage directory were Ok, without any post or pre-processing. Has import logic changed from previous ShotWell versions ?
Is there something that can be done to get a correct import on this phone ? (perhaps when the file name contains valid date and time data, and when metadata timestamp is clearly wrong, as is the case here)
Related issues:
- related to shotwell - 3314: Wrong recognizing of Video recoring date (3gp) (Fixed)
- related to shotwell - 3300: use file mtime as timestamp if EXIF information missing (Open)
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-16 14:36:00 -0700 ----
History
Comment 1
Updated by Hubert Toullec about 2 years ago
Sorry, previous persions of ShotWell did have the same behaviour : dated event and storage dir were also ../1904/01/01
Comment 2
Updated by Jim Nelson about 2 years ago
- Category set to 4
You are able to adjust the date/time your video files using Photos -> Adjust Date/Time... Does this solve your problem?
Comment 3
Updated by Hubert Toullec about 2 years ago
-
Category deleted (
<strike>
_4_</strike>
)
Not really. After adjusting date/time from 1904/01/01 to 2011/06/30, the video event name is still "ven. 1 janv. 1904", but now located under june 2011 instead of january 1904 and the storage dir is still ../1904/01/01.
So, with the current ShotWell version, I see no other solution except the one I explained in 4117
Comment 4
Updated by Jim Nelson about 2 years ago
- Description updated (diff)
- Category set to 4
So, changing the event name does not change where the photo is stored. In general, Shotwell doesn't move files around. There is a ticket for this: #2170 (closed).
As far as the event keeping the same name, did you manually edit the event name at any time in the past? Shotwell automatically generates the event name based on the photos' dates, but if you touch it in any way (such as setting all the characters to lowercase), then Shotwell will persist it. You can reset it back to the automatic name by clearing it entirely (Event -> Rename, then delete all the characters and press Enter).
Comment 5
Updated by Hubert Toullec about 2 years ago
I just upgraded to ShotWell 0.11.4 and all my Galaxy S2 .mp4 video are under event "ven. 1 janv 1904" again ! I spent some time to carefully process each of them to get it in its correct event and storage dir (see 4117 for the method I use), and now everything has to be done again !
I also notice that the time adjust I did has not been kept when upgrading to 0.11.4 (from 0.11.2), as date of all .mp4 videos is now 1/1/1904
Very annoying...
NB. I never renamed any event. I always managed to get them created by ShotWell
Comment 6
Updated by Adam Dingle almost 2 years ago
- Priority changed from Normal to High
It's too bad that this phone creates bogus dates/times in video files. It might be worth creating a workaround for this special case if this phone is popular.
Comment 7
Updated by Laura Khalil almost 2 years ago
- Subject changed from Video mp4 import from Samsung Galaxy S2 to [android] Video mp4 import from Samsung Galaxy S2
Comment 8
Updated by Laura Khalil almost 2 years ago
As reported downstream, this may be more widespread than the Galaxy S2. It is also occurring on the Galaxy S and HTC Desire Z running CyanogenMOD 7.1.0.
I have also been able to replicate this issue on the HTC Evo running Android 2.3.3. The video was taken on today's date, but when imported the event date is listed as Friday January 11, 1946.
Same problem occurs with .mp4 and .3gp videos.
The date can be correctly set by selecting Photos > Adjust Date and Time from the drop down menu.
https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/900501
Comment 9
Updated by Adam Dingle over 1 year ago
- Subject changed from [android] Video mp4 import from Samsung Galaxy S2 to [android] wrong date for video mp4 import from Samsung Galaxy S2
Comment 10
Updated by Adam Dingle over 1 year ago
- Subject changed from [android] wrong date for video mp4 import from Samsung Galaxy S2 to [android] wrong date for video mp4 import from some Samsung and Android devices
Comment 11
Updated by Laura Khalil over 1 year ago
This has also been reported by a user with a Samsung WB2000 camera.
Comment 12
Updated by Khairil Yusof over 1 year ago
Also affects Sony Ericsson Xperia Mini Pro (2011), Android 2.3.4.
Comment 13
Updated by Khairil Yusof over 1 year ago
- File MOV_0080.mp4 added
Comment 14
Updated by Dan Garton over 1 year ago
For anybody needing a workaround for this problem, I wrote a bash/awk script that fixes the metadata for (at least) videos from Samsung Galaxy S2 devices (which is my problem case).
I covered the topic here: http://fyssh.net/blogs/technuts/2012/03/04/video- metadata-wrangling
and the direct download for the script is here: http://fyssh.net/bits/gpl/metaDateFix.sh (requirements: install libimage- exiftool-perl ffmpeg)
Usage: metaDateFix.sh -report|-fix <directory>
The "-report" mode makes no changes, just gives you a summary of the metadata
problems in mp4/avi/3gp files in <directory>
. "-fix" mode creates a copy of
the file with a fixed timestamp with "_broken" appended to the original
filename. These can then be removed however you want, or in the shell with
something like "find <dir> -name "_broken" -exec rm '{}' \;"
It should work on all AVI, MP4, and 3GP files. It uses exiftool to check if valid metadata exists, and if not, IF the filename is in the format "video-YYYY-MM-DD-HH-MM-SS" it uses ffmpeg to write a correct timestamp based on that filename.
Now my Shotwell is 100% date-ordered.
Comment 15
Updated by Adam Dingle over 1 year ago
- Target version set to 0.13
It seems this is affecting a number of users. It would be nice to have a fix or workaround for 0.13.
Comment 16
Updated by F M over 1 year ago
The same problem applies to the Samsung Nexus S -- one of the official Google phones. I am running Android 4.0.
Comment 17
Updated by Adam Dingle about 1 year ago
-
Target version deleted (
<strike>
_0.13_</strike>
)
Comment 18
Updated by Thomas Novin about 1 year ago
Still no fix for this in 0.13. Just imported from my HTC Sensation with CyanogenMod 10/Android 4.1 and my latest videos were imported to 1946.
Was going to try the workaround in post #14 but all links are 404.
Dan Garton, please make it available again.
Edit: Ooops, my issue is not this but http://redmine.yorba.org/issues/3314
Comment 19
Updated by Dan Garton about 1 year ago
- File metaDateFix.sh added
Workaround update:
Blog post now at: http://techtinker.net/2012/03/04/video-metadata-wrangling/
Script "metaDateFix.sh" available at: http://chocnmilk.org/bits/gpl/metaDateFix.sh or in the attachment.
(You may need to hack the script a bit in order to get your video files recognized - the naming seems to vary quite a lot across various Android versions....)
If you can wait a few days, I will provide a rewritten Python version of the script which I will make more flexible to recognize more naming structures.
Comment 20
Updated by Jim Nelson about 1 year ago
- Target version set to 0.14.0
This looks interesting. If you do develop a fuller script, please let us know.
Comment 21
Updated by Jim Nelson 11 months ago
- Category set to video
Comment 22
Updated by Jim Nelson 9 months ago
- Keywords set to needs-testing
Comment 23
Updated by Jim Nelson 8 months ago
- Target version changed from 0.14.0 to 0.15.0
Comment 24
Updated by Arnaud Jeansen 7 months ago
I also have this problem (Samsung Galaxy S2), and was pulling my hair trying to make my videos import properly.
Adjusting date / time was not a solution as it:
- left the video files in a 1904/01/01 directory, even when dragged afterwards to the proper event
- didn't edit the video metadata to the new date (even though the preference to write metadata is selected in my preferences)
Thanks a lot Dan Garton for the script, it is an evil script (awk and bash, yuk) but it did the job on my video files with no hassle. Metadata are now properly set, so importing the files in Shotwell is now obvious and do not require any tweak.
Comment 25
Updated by Jim Nelson 7 months ago
Arnaud, what version of Shotwell are you using? We did make some fixes in 0.14 for similar problems (#3314 (closed)). (Note that these changes only fix the videos timestamp at import, it won't update timestamps for videos you've already imported.)
Comment 26
Updated by Jim Nelson 6 months ago
-
Target version deleted (
<strike>
_0.15.0_</strike>
)
--- Bug imported by chaz@yorba.org 2013-11-25 21:56 UTC ---
This bug was previously known as bug 4166 at http://redmine.yorba.org/show_bug.cgi?id=4166 Imported an attachment (id=262294) Imported an attachment (id=262295)
Unknown version " in product shotwell. Setting version to "!unspecified". 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. Resolution set on an open status. Dropping resolution