https://bugs.kde.org/show_bug.cgi?id=305104
Johannes changed:
What|Removed |Added
CC||johannes.lists+bugs.kde.org
|
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #14 from Johannes
---
How do I fix the "mess of Derived Images and Identical Images that are neither
derived nor identical"? Is this possible to do within digikam? Or do I have to
use a command line tool to remove the non identical images?
https://bugs.kde.org/show_bug.cgi?id=323210
Johannes changed:
What|Removed |Added
CC||johannes.lists+bugs.kde.org
|
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #17 from Johannes
---
I forgot to say in my comment 13 that I encountered that problem in only one
album which is a folder synced with the Dropbox client after editing an image.
It looks like bug 323210 is a duplicate of this one, maybe s
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #18 from Johannes
---
Reading bug 323210#c4 again:
“Dropping the relations table has no side effects, you just lose relations.
Locating identical images is not based on the relations table, it's based on
file hash and file size“ lead me to
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #19 from Johannes
---
Finally I was able to correct the database.
What I did trying to figure it out (using digikam 4.12 on Ubuntu 16.04):
I set up a new digikam collection with only the images from dropbox and dumped
the sqlite database.
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #21 from Johannes
---
I'm sorry for my writing, English is not my native language.
So I don't think that Dropbox is causing that error by adding or changing
Exif.Photo.ImageUniqueID . I think some smart phone cameras create these. I
just g
https://bugs.kde.org/show_bug.cgi?id=305104
--- Comment #23 from Johannes
---
Ok, I see.
It looks like that the test in
https://quickgit.kde.org/?p=digikam.git&a=blob&f=libs%2Fdmetadata%2Fdmetadata.cpp
... at line 966
if (!exifUid.isEmpty() &&
!exifUid.startsWith(QLatin1String("000
https://bugs.kde.org/show_bug.cgi?id=360421
Bug ID: 360421
Summary: After waking from standby mouse clicks and keyboard
input doesn't reach kscreenlocker or other
applications, session kill necessary
Product: plasmashell
https://bugs.kde.org/show_bug.cgi?id=360421
--- Comment #2 from Johannes ---
Did that, it helped (the screen was unlocked and usable again), but the
problems about high CPU load after TTY switching remained.
"Unfortunately" the error only occurred once since your comment, which is odd
since bef
https://bugs.kde.org/show_bug.cgi?id=360421
--- Comment #4 from Johannes ---
Killing kglobalaccel didn't help. The Xorg usage went up to 100% and other
applicatoins (plasmashell, kwalletd5, kwin_x11, ksmserver, yakuake, and
krunner) went up to ~22% cpu usage.
Also afterwards the complete screen
11 matches
Mail list logo
