All the discussion is here : http://digikam.1695700.n4.nabble.com/Date-taken-tag-for-video-files-td4704861.html#a4708154 Excerpts : Hi :) After analyse a video file metadata with Digikam 6.0.0, it find a new field displayed in file view : "dititalized date". It seems to display the same date that "created date". Anyway, this is what i see and understand about differents date fields in list view : <http://digikam.1695700.n4.nabble.com/file/t376394/gfH5Sh1.png> 1- File name : file is named with the actual date as soon as i start video capture. It isn't a metadata but it is the real "taken date". 2- Last modified. File date attribute is writed at the end of the capture. It isn't the good "date taken" because it is the "end" of the video, not the "start". I think it have more sense to use "beginning date". 3- Created date : it is the end of the video but not the good : it has an error of "one hour". I think it is about "GMT" ? 4- Digitalized date : new field sinc Digikam 6.0.0 but same problem that created date (one hour less). Because the "file name" is the only good "taken time", i only use it and not the others fields. For that i just rename it to match my others file names preferences (yyyymmddhhmmss). It is ok but when i explore my videos, i have to sort them by "name", not by "date"... then : I made complete tests with my different video recording devices and applications. Issues (start video not used and difference of time) are present only with my Android Devices, not with my "real" camera devices. You can consult my sheet comparative here https://docs.google.com/spreadsheets/d/1vHiruk7Y0XZmNdMOSt0ifCuassatx0LwbW-xLHCpTPE/edit?usp=sharing I will share my video samples files soon when they will be uploaded. Thanks
That the creation date is set to the end of the video date, I think is not standard when I look at Exiftool. I will test how cameras handle this in a long time exposure. The file modification date is also not a good source. We know the running time of the video and can calculate an end date. But this is just for the Advanced Rename. The problem with the time is known, unfortunately some cameras store local time and other UTC time. Maik
A test with my Nikon and a long exposure shows that the "created date" and the "digitalized date" are identical and contain the starting time of the exposure. Maik
Hi Maik :) Thanks for your reply. My tests show me that issues (start video not used and difference of time) are present only with my Android Devices, not with my "real" camera devices. If you have an android device, maybe you could try with yours ? Thanks
For me Apple devices only here, no Android... Gilles Caulier
I have an Android device, I check it tonight. Maik
Hi, I finished to upload my video samples. You can download them from here : https://mega.nz/#F!M6YySIxQ!caN28HIAeVqNS0stzubHqg Bye
I can reproduce the problem with a video here from an Android device. It stores correctly in UTC and the displayed time in digiKam is one hour back (my time is UTC + 1). But I see Exiftool here for reference and it shows the same time as digiKam. At the moment, I see no way to automatically detect which time is stored in the video as local time and which time as UTC. Maik
*** Bug 401964 has been marked as a duplicate of this bug. ***
Hi, This is an excerpt of a reply on the nabble forum at Apr 01, 2019; 9:58pm — by Anders Kamf Anders Kamf "...Older cameras using AVI file format often created a .THM beside the movie with correct timestamp..." My Panasonic FZ18 create these .THM files. I didn't keep them with samples i uploaded. Tell me if it can be useful that i create a new video and upload both the video and its .thm file. Bye
Git commit f172937814e3524bfcde25d19c4e1350c0c1ba4d by Maik Qualmann. Committed on 22/06/2019 at 15:42. Pushed by mqualmann into branch 'master'. prefer "com.apple.quicktime.creationdate" for video date Related: bug 409038 FIXED-IN: 6.2.0 M +2 -1 NEWS M +26 -17 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/kde/digikam/commit/f172937814e3524bfcde25d19c4e1350c0c1ba4d
Git commit c938087700c20dc3f129444e455ad1596c365063 by Maik Qualmann. Committed on 22/06/2019 at 16:42. Pushed by mqualmann into branch 'master'. check if the Android version is available and keep the UTC extension M +12 -8 core/libs/metadataengine/dmetadata/dmetadata_video.cpp https://invent.kde.org/kde/digikam/commit/c938087700c20dc3f129444e455ad1596c365063
All videos (incorrectly date from the Android devices) provided are now recognized correctly in the creation date. I close the bug now, if necessary open again. Maik
Hi, Thanks Maik, i will test it as soon as possible :) Are changes include in last git version ?
Hi, Sorry for my late reply. So, with 6.3.0 (and since 6.2.0) : difference of time issue is resolved. Thanks a lot for that :) But there is always the second issue : start video time not used; it is the end time (for android devices). Do you know why android devices store the end time instead of the start time like others video recording devices ? Do you know any solution ? Could it be calculated by Digikam ? (recorded date less duration) Thanks
There is no end time in the metadata. You could use the file name with the Time Adjust tool to correct the time. Time Adjust can guess the time from the filename. Another possibility would be to add up the running time. But I do not know if there are other programs that do this and if it complies with the standard. But as I wrote before, even cameras store the start time in long exposures. Maik
Hi, Maybe i didn't explained myself well : i want start time, but all my android videos has the end time in metadata. Thanks for the tip with time adjust tool; it work and it is a perfect solution; when the date is in the filename. It seems to be the case for all my android videos :) Do you know why the end time is used as metadata with android video ?
Ah yes, with Anroid it was the end time. We can not always tell from the metadata if it's Android. So subtracting the runtime would not always be possible. I've just tested the Android samples again with Exiftool, also Exiftool displays the end time. For me Exiftool is the reference here. Maik
Ok. So, there isn't really a solution for this :( So with android videos i have to : Deal with the end time or use the time adjust tool. Thanks a lot for the fix with difference of time and the tip for adjust time based on filename :) Bye