Bug 449315

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