[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 caulier.gil...@gmail.com changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Version Fixed In||8.1.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #14 from Ervan Darnell --- Confirming the bug does not replicate in 8.x. Can be closed. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #13 from caulier.gil...@gmail.com --- @Ervan Darnell digiKam 8.1.0 pre-release AppImage bundle is now ported to Exiv2 0.28 which come with a huge list of bugfixes : https://github.com/Exiv2/exiv2/issues/2406#issuecomment-1529139799 AppImage file is available here : https://files.kde.org/digikam/ How to use AppImage under Linux : https://docs.digikam.org/en/getting_started/installation.html#digikam-on-linux Thanks in advance for your feedback Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 caulier.gil...@gmail.com changed: What|Removed |Added CC||caulier.gil...@gmail.com --- Comment #12 from caulier.gil...@gmail.com --- @Ervan digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #11 from David Haslam --- Created attachment 140199 --> https://bugs.kde.org/attachment.cgi?id=140199=edit Tags after metadata is re-read -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #10 from David Haslam --- Created attachment 140198 --> https://bugs.kde.org/attachment.cgi?id=140198=edit Test tags assigned to image -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #9 from David Haslam --- Created attachment 140197 --> https://bugs.kde.org/attachment.cgi?id=140197=edit Creation of test tags -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 David Haslam changed: What|Removed |Added CC||dch.c...@gmail.com --- Comment #8 from David Haslam --- I came across a similar problem, while working with a large tag hierarchy where the same word is used at different levels. I've been able to reproduce the problem with a clean database and doing these steps: 1. Use the tag manager to create these tags: - "2020/11 Bob" - "2020/2020/11 Bob" See image tag-hierarchy-1.jpg 2. Create a blank test image, with no metadata. Refresh to view the new image in digikam. 3. Select the image and assign "2020" and "2020/11 Bob" to the test image. See attachment tag-hierarchy-2.jpg 4. Click Apply to write the metadata (I have digikam configured to write to XMP sidecars). The XMP file contains: 2020 2020/11 Bob Which looks correct. 5. Click "More"->"Read Metadata from file to database". 6. Observe that "2020/2020" and "2020/2020/Bob" are now erroneously ticked. See attachment tag-hierarchy-3.jpg The fault lies in TagsCache::tagForPath in file core/libs/database/tags/tagscache.cpp. This function doesn't properly handle the case of a path with only one level, and multiple tag paths with the same name. I've been testing a fix, and a pull request will be sent shortly. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #7 from Ervan Darnell --- Ok, there is an easy work around: 1) Create tag "temp" 2) Select all 2020/2020/11 Bob pics from the tag manager and assign them to "temp". 3) Delete 2020/2020/11 Bob and 2020/11 Bob tags completely. 4) Rename temp to 2020/11 Bob I'm still happy to help debug if you care. Also, the original parsing of x.y is tags somehow buggy and I can help drill down on that if you care. Thanks for all of the quick replies. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761
--- Comment #6 from Ervan Darnell ---
All *xmp files are *.mp4.xmp in the relevant directory, so a duplicate .xmp is
not the answer. I unchecked 2020/2020/11 Bob, checked 2020/11 Bob (in the Tags
UI), then clicked "apply". The log follows.
Your theory there is some problem with the database makes sense as the .XMP
seems fine. I imported many files with x.y keywords. Some of the get parsed
as x/y, some as x/x.y, and some as x.y (where '/' is the hierarchy separator
in digiKam:TagsList). I was able to clean many of these by manually assigning
tags. So, things are usually working, but there are several cases, 2020/11 Bob
one of them, where I cannot clean them up. I mean that other very similar .XMP
files worked, so that only leaves the theory there is something in the database
different in this case.
It seems odd to me that digiKam should be keeping any of this state when I
explicitly request a metadata reread. Something is both munged in the database
and not being cleaned out. I'm not willing to share the whole database (as
there is a lot of confidential information in there), but I can open it and
look at some tables if you tell me where to start on that.
For instance, the tags table contains:
119722 11 Bob
1199119111 Bob
The pid of 22 is 0. The pids for 1191 (in TagsTree) are:
11910
119122
and 22 in Tags:
22 0 2020
apparently representing 2020/11 Bob and 2020/2020/11 Bob both, but that doesn't
explain why I cannot reassign tags.
Digikam::DMetadata::loadUsingFFmpeg: Parse metadada with FFMpeg:
"/home/ervan/Pictures/Personal/2020/11 10 Yosemite/PXL_20201108_232847662.mp4"
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg video stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "und"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg audio stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "eng"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg root container metadata entries
:
Digikam::DMetadata::loadUsingFFmpeg: QMap(("compatible_brands",
"isommp42")("creation_time", "2020-11-09T00:24:02.00Z")("major_brand",
"mp42")("minor_version", "0"))
Digikam::DMetadata::loadUsingFFmpeg: --
Digikam::MetadataHub::writeTags: Writing tags
Digikam::MetadataHub::writeTags: -- New Keywords
("Bob", "11 Bob")
Digikam::MetaEngine::setIptcKeywords: "/home/ervan/Pictures/Personal/2020/11 10
Yosemite/PXL_20201108_232847662.mp4" ==> New Iptc Keywords: ("11 Bob", "Bob")
Digikam::MetaEngine::save: MetaEngine::metadataWritingMode 3
Digikam::MetaEngine::save: Will write Metadata to file
"/home/ervan/Pictures/Personal/2020/11 10 Yosemite/PXL_20201108_232847662.mp4"
Digikam::MetaEngine::Private::printExiv2ExceptionError: Cannot save metadata to
image using Exiv2 (Error # 11 : "/home/ervan/Pictures/Personal/2020/11 10
Yosemite/PXL_20201108_232847662.mp4: The file contains data of an unknown image
type"
Digikam::MetaEngine::save: Will write XMP sidecar for file
"PXL_20201108_232847662.mp4"
Digikam::MetaEngine::Private::saveOperations: wroteComment: false
Digikam::MetaEngine::Private::saveOperations: wroteEXIF: true
Digikam::MetaEngine::Private::saveOperations: wroteIPTC: true
Digikam::MetaEngine::Private::saveOperations: wroteXMP: true
Digikam::MetaEngine::save: Metadata for file "PXL_20201108_232847662.mp4"
written to XMP sidecar.
Digikam::DMetadata::loadUsingFFmpeg: Parse metadada with FFMpeg:
"/home/ervan/Pictures/Personal/2020/11 10 Yosemite/PXL_20201108_232847662.mp4"
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg video stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "und"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg audio stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "eng"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg root container metadata entries
:
Digikam::DMetadata::loadUsingFFmpeg: QMap(("compatible_brands",
"isommp42")("creation_time", "2020-11-09T00:24:02.00Z")("major_brand",
"mp42")("minor_version", "0"))
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #5 from Maik Qualmann --- Can it be that 2 xmp files exist with you? A BASENAME.xmp file could also be available from which the tag path is read. The order digiKam searches for xmp files is first BASENAME.xmp and then BASENAME.EXT.xmp. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #4 from Maik Qualmann --- The cause must be different. I cannot reproduce it. What happens if you move "11 Bob" to the top "2020"? If it doesn't work, the tags table is probably damaged. Please then post the messages during the tag move. Maik -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761
--- Comment #3 from Ervan Darnell ---
Thanks for the quick reply. I installed 7.2.0, and let it reread the metadata.
The results are unchanged. The debug log follows. I'm using the default
SQlite database.
I cannot find the exact issue, but this arose because of the handling between
dc:subject and digiKam:TagsList tags in the XMP file. Originally, it was
2010.11 Bob, where '.' was a hierarchy separator, but that got changed to just
'11 Bob' for dc:subject, but digiKam:TagsList kept the full form
2020/11 Bob
So, it's a munged XMP file at fault in a way, but still when digiKam reparses
the XMP file on reread it should not create something completely broken, which
2020/2020/11 Bob is.
Digikam::ScanController::slotRelaxedScanning: Starting scan!
Digikam::DMetadata::loadUsingFFmpeg: Parse metadada with FFMpeg:
"/home/ervan/Pictures/Personal/2020/11 10 Yosemite/PXL_20201108_232847662.mp4"
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg video stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "und"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg audio stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "eng"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg root container metadata entries
:
Digikam::DMetadata::loadUsingFFmpeg: QMap(("compatible_brands",
"isommp42")("creation_time", "2020-11-09T00:24:02.00Z")("major_brand",
"mp42")("minor_version", "0"))
Digikam::DMetadata::loadUsingFFmpeg: --
Digikam::CoreDB::clearMetadataFromImage: Clean up the image information, the
file will be scanned again
Digikam::MetaEngine::getDigitizationDateTime: DateTime (Exif digitalized):
QDateTime(2020-11-09 00:24:02.000 PST Qt::LocalTime)
Digikam::MetaEngine::getDigitizationDateTime: DateTime (XMP-Exif digitalized):
QDateTime(2020-11-09 00:24:02.000 PST Qt::LocalTime)
Digikam::ItemMarkerTiler::slotSourceModelReset:
Digikam::MetaEngine::getXmpTagStringSeq: XMP String Seq ( Xmp.digiKam.TagsList
): ("Friends/Bob", "2020/11 Bob")
Digikam::ItemScanner::scanTags: Pick Label found : 0
Digikam::ItemScanner::scanTags: Assigned Pick Label Tag : 15
Digikam::ItemScanner::scanTags: Color Label found : 0
Digikam::ItemScanner::scanTags: Assigned Color Label Tag : 5
Digikam::ItemScanner::commit: Scanning took 96 ms
Digikam::ItemScanner::~ItemScanner: Finishing took 7 ms
Digikam::DMetadata::loadUsingFFmpeg: Parse metadada with FFMpeg:
"/home/ervan/Pictures/Personal/2020/11 10 Yosemite/PXL_20201108_232847662.mp4"
Digikam::DMetadata::loadUsingFFmpeg: Parse metadada with FFMpeg:
"/home/ervan/Pictures/Personal/2020/11 10 Yosemite/PXL_20201108_232847662.mp4"
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg video stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "und"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg audio stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "eng"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg root container metadata entries
:
Digikam::DMetadata::loadUsingFFmpeg: QMap(("compatible_brands",
"isommp42")("creation_time", "2020-11-09T00:24:02.00Z")("major_brand",
"mp42")("minor_version", "0"))
Digikam::DMetadata::loadUsingFFmpeg: --
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg video stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "und"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg audio stream metadata entries :
Digikam::DMetadata::loadUsingFFmpeg: QMap(("creation_time",
"2020-11-09T00:24:02.00Z")("handler_name", "ISO Media file produced by
Google Inc. Created on: 11/08/2020.")("language", "eng"))
Digikam::DMetadata::loadUsingFFmpeg: -
Digikam::DMetadata::loadUsingFFmpeg: -- FFMpeg root container metadata entries
:
Digikam::DMetadata::loadUsingFFmpeg:
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 --- Comment #2 from Ervan Darnell --- Created attachment 135579 --> https://bugs.kde.org/attachment.cgi?id=135579=edit extra hierarchy level for tag "11 Bob" even on version 7.2.0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 432761] reread of XMP metadata leaves tag hierarchy scrambled
https://bugs.kde.org/show_bug.cgi?id=432761 Maik Qualmann changed: What|Removed |Added CC||metzping...@gmail.com --- Comment #1 from Maik Qualmann --- I cannot reproduce the problem here. It is created quite normally /2020/11 Bob. Tested here with MySQL, what kind of database do you use? Otherwise, please post the output from the terminal with activated debug mode when a re-read of the metadata is carried out. As described here: https://www.digikam.org/contribute/ Furthermore digiKam-6.4.0 is quite old, please try the current AppImage release candidate from digiKam-7.2.0-RC from here: https://files.kde.org/digikam/ Maik -- You are receiving this mail because: You are watching all bug changes.
