https://bugs.kde.org/show_bug.cgi?id=402379
--- Comment #8 from Maik Qualmann ---
Git commit db18a967f684e7c35e27f9c4c06b72b7fc7d170d by Maik Qualmann.
Committed on 23/12/2018 at 13:15.
Pushed by mqualmann into branch 'master'.
disable external album scans when processing internal files
M +6
https://bugs.kde.org/show_bug.cgi?id=402379
--- Comment #7 from Maik Qualmann ---
Git commit a24ab41458ec5a73a6aeb470cccefdd7ffbe449f by Maik Qualmann.
Committed on 23/12/2018 at 08:08.
Pushed by mqualmann into branch 'master'.
reset grouped items cache
M +4-0core/libs/database/item/co
https://bugs.kde.org/show_bug.cgi?id=402379
--- Comment #6 from Maik Qualmann ---
I could reproduce the problem. The fact that it did not occur in digiKam-5.9.0
is also a bug when writing metadata to the database. Now that we use the
modification date from either the image or the sidecar, it can
https://bugs.kde.org/show_bug.cgi?id=402379
Maik Qualmann changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Latest Commit|
https://bugs.kde.org/show_bug.cgi?id=402379
--- Comment #4 from Maik Qualmann ---
It definitely does not matter, because SQLite has always saved with 3
additional digits. Such a date is scanned at most once and now the more
accurate date is stored. But no metadata are lost. Are there any LR sidec
https://bugs.kde.org/show_bug.cgi?id=402379
--- Comment #3 from meku ---
I have not enabled "Cleanup Database". I am testing with a single collection,
on a single partition.
I believe there is an additional condition that triggers this bug and it is
related to the filesystem timestamps of the ph
https://bugs.kde.org/show_bug.cgi?id=402379
--- Comment #2 from Maik Qualmann ---
I can not confirm or reproduce the loss of metadata. Therefore, I suspect that
you have enabled the metadata option "Cleanup Database ...". The creation of a
new image ID is done only when moving between different c
https://bugs.kde.org/show_bug.cgi?id=402379
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
--- Comment #1 from Maik
