https://bugs.kde.org/show_bug.cgi?id=526500
Bug ID: 526500
Summary: MTS: H264 recording timestamp visible in metadata but
ignored by date views; Time Adjust also fails
Classification: Applications
Product: digikam
Version First 9.1.0
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: Metadata-ExifTool
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 196742
--> https://bugs.kde.org/attachment.cgi?id=196742&action=edit
Screenshot showing 00000.MTS with recording and filesystem timestamps in 2009,
while the thumbnail still displays 2025. Unrelated files and personal images
are blurred.
Title: MTS: H264 recording timestamp visible in metadata but ignored by date
views; Time Adjust also fails
Version: digiKam 9.1.0
Platform: Windows
ExifTool: 13.59
Summary:
digiKam displays the correct recording timestamp in the ExifTool metadata panel
but does not use it in the thumbnail or Dates view. Rereading metadata does not
correct the date. Adjust Time & Date also fails when attempting to update the
date from a corrected filesystem timestamp.
Problem 1: Recording timestamp is visible but not used
For 00000.MTS, digiKam’s ExifTool panel shows:
H264 = 2009:04:16 11:29:43+02:00
However, the thumbnail displays 11.11.2025 23:34, matching the file’s former
filesystem creation timestamp. The video does not appear under 16 April 2009 in
the Dates view.
“Use ExifTool backend to read metadata from files” is enabled.
Rereading metadata does not correct the displayed date.
In Adjust Time & Date, selecting “EXIF: original” or “EXIF: created” produces
“not valid”, despite the H264 recording timestamp being visible in the ExifTool
panel.
Problem 2: Time adjustment fails
The filesystem creation and modification timestamps were corrected externally
using the recording timestamp. Adjust Time & Date now correctly previews
16.04.2009 11:29:43 when “File created” is selected as the source.
Steps to reproduce:
Select 00000.MTS and open Adjust Time & Date.
Select “File created” as the source.
Select “Copy value”.
Select only “File last modified” as the update target, with EXIF/IPTC/XMP
targets unchecked.
Click Apply.
Actual result:
“Failed to update metadata timestamp” is shown. The old 2025 date remains in
the thumbnail and Dates view.
Expected result:
digiKam should recognize the embedded H264 recording timestamp as the recording
date, or provide a way to select it as the date source. Rereading metadata
should update the database accordingly.
Updating only the filesystem modification timestamp should succeed without
requiring writable embedded metadata.
Additional investigation:
The following was reproduced on a local copy of the video, independently of the
NAS where the collection is stored.
In the 9.1.0 source, TimeAdjustTask calls DMetadata::load without
videoAll=true, even when only the filesystem modification timestamp is
selected.
Reproducing the corresponding ExifTool EXV extraction using -TagsFromFile with
-all produces:
“No writable tags set”
“Nothing to write”
Using -all instead successfully creates an EXV file containing:
[ExifIFD] DateTimeOriginal = 2009:04:16 11:29:43
TimeAdjustTask suppresses signalDateTimeForUrl when META_TIME_ERROR is set.
This appears to explain why the failed adjustment leaves the database date
unchanged.
The relevant loading behavior also appears unchanged in the development source
inspected on 1 October 2026. A 9.2.0 weekly binary has not been tested.
The two problems may be related, but the failure to use the embedded recording
date occurs before any adjustment is attempted.
--
You are receiving this mail because:
You are watching all bug changes.
