1. import .mp4 file which Digikam can read Expected: mp4 file should have a date stamp according to the file mtime Actual: mp4 file has a date stamp of "now, today" (= time of import) This makes it very hard to import movie files together with the image files because the movies will be sorted at the end. Strangely using the date string to create subfolders (in the import dialog) works correctly - it is just the Digikam timestamp which is not saved. Please have look. Thanks!
In order to use video metadata in digiKam-6.0.0 import tool you have to activate the option "Use file metadata (makes connection slower)" in the camera setup (Behavior Tab). Maik
Note: this does not work with a Gphoto2 driver. Maik
I don't use the camera drivers because I preprocess my images. Most images are added using "Import from folder" or "Import picutures ..." menu item. IMHO: For these menu items, and for any files that do not have any non-filesystem (EXIF, IPTC, XMP, whatever) metadata, for example video files, the option you mentioned should defintively be the default setting. Otherwise you lose information during import. Don't you agree?
Why this option is not the default : because parsing file to handle metadata with Exiv2 will slow down Import tool. Gilles Caulier
True, but losing metadata is (IMHO) not an excuse for speed. I don't care how long the import takes, it runs in the background and does not need to be monitored. But I *do* care if I have to reassign file dates to 100 movie clips after the import. Please make the option the default and then maybe offer a checkbox "[x] speed up import (warning: this will not import file metadata, e.g. time stamps for movie files)" or something.
No metadata is lost if the option are not enabled in the Import tool. It may be e.g. not the correct date available if we use the rename equal in the import tool. My workflow is, for example, that I rename the images only in lower case and then download. If later renamed in digiKam, all metadata is always available. Maik
Even if this were the case it does not seem to work correctly. Example with the most current appimage from yesterday (20180514xxx). The first screenshot shows timestamps in file manager (mtime) and Digikam's import preview (with file metadata *activated*). You can see that Digikam's timestamps show an incorrect file date, not equal to the the date shown in the file manager. When I import this file, this incorrect date is kept with the file, although Digikam knows about the (correct) file mtime (screenshot two). I can modify it manually but I cannot use BQM to batch correct the dates since it is not possible to write a new date (e.g. file mtime), because then the mtime will be set to $NOW. Please tell me there is a way to import all my movie clips with the correct time stamp into Digikam. These mp4 files have no EXIF or XMP or whatever metadata, just the file modification time, and currently, Digikam cannot import, or batch-correct, these after import. Thank you!
I'm surprised that MP4 has no date-time internally. Can you share a video sample that i can parse with the ffmpeg DK interface to handle metadata. Perhaps something is wrong in DK code... Gilles Caulier
Created attachment 112663 [details] video files with incorrect time stamps during import
Created attachment 112664 [details] video files with incorrect time stamps after import
OK, after some more research it seems I created this problem by myself. Sorry ... Here's why: I recompress my smartphone and camera videos using a HandBrakeCLI script before importing because this saves 90% of space while visually not lowering quality. In the past this script was also necessary because my smartphone's gyro sensor was broken and I had to manually rotate all images and videos - images were easy to rotate in Digikam but videos aren't, so the script was required. The smartphone's mp4 files never had any metadata I could see, and using "touch -mr $OLD $NEW" was sufficient to copy the "date taken" to make Digikam recognize the date correctly. But since *some* versions ago either HandBrake adds some "Date encoded" tag or Digikam now interprets this tag as "Date taken" tag - which is at least debatable because the file is *re*encoded, this is not the "date taken". After some research I found out Handbrake cannot copy the correct "Date encoded" from the source file, but ffmpeg directly can, so I'll use this in the future. Sorry to bother you - but this was really a confusing issue. PS: The bug about not being able to copy the file mtime to the "Digikam timestamp" (database) in the BQM still exists. This would have helped me too ...
I can not reproduce a problem here with Time Adjust tool in BQM when setting a new file modification time. The date / time is set correctly (test with file manager) and is also displayed correctly in the digiKam Icon view. Can you perhaps describe the problem more exactly? My guess is that it's not possible to set a new file creation date if the file contains no metadata and is read-only. Maik
The issue I had was about using the file mtime as the "digikam date" (= the date that is displayed below the thumbnails). You can write a new date to almost everywhere (EXIF, XMP, IPTC, ...) but not to the Digikam DB. Right?
Git commit bdf9b3bfd1fcb13934816c6e50448409d777612a by Maik Qualmann. Committed on 06/11/2018 at 18:54. Pushed by mqualmann into branch 'master'. keep the source file modification time for files from UMS drives FIXED-IN: 6.0.0 M +2 -1 NEWS M +2 -2 core/utilities/import/backend/cameracontroller.cpp https://commits.kde.org/digikam/bdf9b3bfd1fcb13934816c6e50448409d777612a