| Summary: | Import .mp4 files does not preserve file mtime as date stamp | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Jens <jens-bugs.kde.org> |
| Component: | Import-Gphoto2 | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version First Reported In: | 6.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | https://commits.kde.org/digikam/bdf9b3bfd1fcb13934816c6e50448409d777612a | Version Fixed/Implemented In: | 6.0.0 |
| Sentry Crash Report: | |||
| Attachments: |
video files with incorrect time stamps during import
video files with incorrect time stamps after import |
||
|
Description
Jens
2018-05-13 19:32:25 UTC
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 |