I have a pic.jpg in folder1 and a different pic.jpg in folder2 (different pictures with same filename). Remove folder1/pic.jpg via mouse menu to trash and then copy folder2/pic.jpg to folder1/ works. Remove folder1/pic.jpg via delete key and then copy folder2/pic.jpg to folder1/ does not work. Thumbnail and metadata of the copied picture are from the previously deleted picture. Manual re-reading metadata from picture repairs the situation. Delete key should work like remove from the mouse menu. All operations are from within digikam, not from any external file browser. I'm running digikam 7.5 on OpenSuSE Thumbleweed, the database is SQLite.
I can't reproduce the problem. It doesn't matter that both images have the same name. Also whether you delete via context menu to the trash or with the delete key. Or do you mean direct deletion without the trash? For the problem to occur, both image UUIDs would have to be identical. Do the imahes come from a Samsung camera/smartphone? Maik
If I test using the same image (identical UUID) then I can reproduce the behavior. However, this behavior is normal and intended. With a deleted image in the recycle bin, we want to keep the metadata when restoring it. The metadata must also be preserved when copying images. We only know the problem with an identical image UUID from Samsung. However, the problem has been fixed in current digiKam versions. However, older images must be rescanned. Maik
(In reply to Maik Qualmann from comment #1) > I can't reproduce the problem. It doesn't matter that both images have the > same name. Also whether you delete via context menu to the trash or with the > delete key. Or do you mean direct deletion without the trash? For the > problem to occur, both image UUIDs would have to be identical. Do the imahes > come from a Samsung camera/smartphone? > > Maik One image from Olympus TG-4, one from IPhone 12. Menu deletion to trash bin, key deletion without shift.
Copy was done by dragging from folder to folder, not via Cntrl C / Cntrl V Jens
Can you provide both images? If not public to my private mail? Maik
Another observation: folder1/pic.jpg is portrait, folder2/pic.jpg is landscape. Copy folder1/pic.jpg -> folder3/ Copy folder2/pic.jpg -> folder3/ => folder3/pic.jpg is displayed as portrait Jens
Hi Maik, I tried to reproduce - without success (I took 2 pictures from an Android Phone). Back to the original setup, I used one IPhone picture -> the problem still exists. Attached the pictures. pic works, pic1 has the problem. Greetings, Jens. Am 29.01.22 um 15:54 schrieb Maik Qualmann: > https://bugs.kde.org/show_bug.cgi?id=449315 > > --- Comment #5 from Maik Qualmann <metzpinguin@gmail.com> --- > Can you provide both images? If not public to my private mail? > > Maik >
I cannot reproduce the problem with different images. Can you please start digiKam in the terminal with the Qt-Debug variable active and post the output when you copy the image and the problem occurs. Qt-Debug ist described here: https://www.digikam.org/contribute/ Maik
Git commit aae03cc83f645803579e488a2d3161935e7dbc03 by Maik Qualmann. Committed on 29/01/2022 at 21:26. Pushed by mqualmann into branch 'master'. if there is a copy hint, this has priority over found deleted item A ScanController hint is valid for 5 minutes. If the hint exists, we'll use it now instead of a possible same deleted entry. If a item is restored from trash within the 5 minutes, the copy hint item will also be used. FIXED-IN: 7.6.0 M +2 -4 core/libs/database/item/scanner/itemscanner_database.cpp https://invent.kde.org/graphics/digikam/commit/aae03cc83f645803579e488a2d3161935e7dbc03
As I understand, you had been able to reproduce the issue, so the debug log is not required anymore. One question regarding the fix. The given use scenario was a pretty much reduced use case to make arbitrary behavior reproducible. The original scenario is as following: - Use an external scan program to scan a sequence of slides into a directory. The scan program gives filenames in ascending order. - Have this folder open in digikam and do (tagging, ...), renaming, deleting, moving into other albums in digikam while the scanner is working. - The scanner re-uses the freed-up filenames. In this case sometimes I see the thumbnails and other meta data from previous pictures on these new scans. With the description of the "5 minutes ScanController hint" miracle, my assumption is, that the fix will not solve my original issue. Correct? Thanks for your support, Jens
Your debug log would still be interesting. I couldn't reproduce the problem with your image. The image scanner in digiKam is quite complex to recognize copied/moved and deleted images to reuse the existing metadata and not start a deep scan of the image again. An image is unlikely to have the same name AND file size AND unique hash. So I tried to reproduce the problem with the same image. Here I was able to reproduce that the metadata from a deleted image was used and not the metadata from my currently copied image. The fact that a wrong thumbnail could sometimes appear with identical file names is a cache problem and would also be fixed if you changed the current view. I'm planning some fixes here in the near future. Maik