Bug 329976

Pressing F5 in when album do not fix the issue ?

Gilles Caulier

(In reply to comment #1)
> Pressing F5 in when album do not fix the issue ?

No, it doesn't. Only 'reread metadata from image' works.

You can easily reproduce this bug, and it is even not necessary to open / close digikam as I mentioned above:
0) create a folder with "picture 1.jpg" "picture 2.jpg" "picture 3.jpg" etc... ; to simply view an effect of this bug, say that all the pictures are in landscape (orientation=top-left) and "picture 17.jpg" is in portrait (orientation='left-bottom')
1) open digikam and view that album -> all OK
2) delete one picture (say "picture 15.jpg")
3) rename all the pictures (so that "picture 16" takes the place of deleted "picture 15" etc...) (batch renaming program, for instance multiple renaming from dolphin)
4) see what happens in digikam ...

PS: you have attached this bug to the "Thumbnails" component: for me it's not really the thumbnails themselves: it's the fact that digikam associates to the new "picture 16.jpg" information from the old "picture 16.jpg" (now "picture 15.jpg") etc.
The thumbnails are correct, I mean they are related to the correct picture, but are eventually not correctly orientated (I can add that if you click on the thumbnail to see the picture 'full screen', it is in the same way badly orientated. Once again, only 'reread metadata from image' works).

Digikam sees the filename as a relatively strong property of a file.
Assume you edit your file with gimp. Afterwards, the file contents and file size will have changed, only the filename remains. 

For certain operations done from outside digikam, the explicit "Reread metadata from file" is necessary. 

If digikam is running during the rename operation, with working Linux notification services, the renaming should be recognize, I would be interested if it works.
If you rename from within digikam, it must work as well.

(In reply to comment #3)
> If digikam is running during the rename operation, with working Linux
> notification services, the renaming should be recognize, I would be
> interested if it works.
Yes and no:
If I rename outside digikam while digikam is running (or not: no impact), digikam sees that files have changed since their names are automatically updated.
However, the metadata are not automatically reread, hence strange behaviors as explained above.

*** Bug 329390 has been marked as a duplicate of this bug. ***

Are you able to reproduce the issue with 5.0.0 version?

In a new folder, I have a list of pictures:
- picture 01.jpg
- picture 02.jpg
...
- picture 5.jpg

1) digiKam reads the images fine.
2) Outside digikam (digikam is closed), I delete 'picture 3.jpg' and rename the next pictures:
'picture 4.jpg' becomes 'picture 3.jpg'
'picture 5.jpg' becomes 'picture 4.jpg'

3) When I open digiKam again, these images are correctly identified, with their respective properties....

This issue is not reproducible with 5.0.0

Feel free to reopen if you still face this and provide necessary updates, if any.

Hello
I reopen the bug because it is still valid for me.
I made the same manipulation, and there are still problems.

I have 14 files 'Test 01.jpg ... Test 14.jpg'

1) Eveything is fine in digikam. See 1st screenshot [1] with details about 'Test 10.jpg'. See for instance that this picture is geolocalised (map icon) and camera is Panasonic.

2) I delete 'Test 07.jpg' and rename Test 08 -> Test 07 etc...  (outside digikam)

3) Now in digikam, NOK: see 2d screenshot [2] with details about 'Test 09.jpg' (which was 'Test 10' before, so same picture as above). See that this picture is no more geolocalised (map icon) and camera is Canon. These are the properties of picture 08 (old 09), so all the picture properties are 'shifted'.

Note: comparing [1] and [2], you see immediately that there is a problem with the map icon (top-right side of thumbs) AND with the date (from 'Test 08', there is now a 'Modification Date')

[1] http://nicofo.tuxfamily.org/tmp/Digikam-1-Before.jpg
[2] http://nicofo.tuxfamily.org/tmp/Digikam-2-After.jpg

Which dtatabse type you use ? sqlite or mysql ?

Gilles Caulier

the default one: sqlite
(I just freshly installed digikam 5.0 in Fedora 24, using default settings)

What's about this file using digiKam AppImage bundle 5.4.0 pre release given at
this url :

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier

Hi Gilles,

I tested again with DK 5.3.
There is progress, this problem is nearly solved, but not with the Tags.

I made the same test as in comment #8
I have no problem anymore related to the properties of the pictures (geolocalisation icon is OK, 'modified date' is ok, ...) BUT well with the tags.

The tags are not correct anymore. And the behaviour is different depending if I make the renaming while DK is running or not. Say that picture 3 has a tag 'TAG'. If I delete picture 2 and rename the other (picture 3 becomes 2 ...):
-> I expect that picture 2 has now the 'TAG', BUT:
- if DK is running: now picture 2 and 3 have 'TAG'
- if DK is not running: after restart of DK, the tags are 'shifted' to the neighbour picture: now picture 3 has the 'TAG'
-> so in both situations it is not good.

(hope the explanation is clear ;) )

What's about this file using 5.8.0 pre-release buncle :

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier

(In reply to caulier.gilles from comment #13)
> What's about this file using 5.8.0 pre-release buncle :

Hello Gilles,
unfortunalety still the same (see comment #12).
Tags and labels (e.g. rating) NOT OK (while other properties OK)

You can immediately see the problem in the following screenshots made before and after picture 07.jpg deletion (deletion+renaming made while DK not running): the rating does not 'follow' the correct picture and tag 'Nicolas' from old_14.jpg disappears in new_13.jpg :-(
http://nicofo.tuxfamily.org/tmp/DK5.8-1-Before.png
http://nicofo.tuxfamily.org/tmp/DK5.8-2-After.png

digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best regards

Gilles Caulier

I tested again with DK 7.0.0:
result is exactly the same as in previous comment (comment #14) -> not OK with tags and ratings.

Hi Gilles,

Correct me if I'm wrong:

I was wondering why some attributes are correct and others not after the manipulation described in comment #8 (rename pictures outside of digikam).
 - attributes that are correct after manipulation: orientation, geotagging, ... Seems to be attributes coming file metadata (EXIF)
 - attributes that are lost after manipulation: tags or ratings, i.e. attributes NOT in file metadata (added in digikam)

My guess: after renaming outside of digikam, renamed pictures are seen as new pictures by digikam. So digikam rereads metadata:
 - attributes from file metadata (EXIF) are therefore correct again
 - other attributes (tags or ratings) are lost (or "shifted" from neighbor picture depending on the setting "Clean up metadata from the database when rescan files"). I suppose these attributes, in digikam DB, are attached to a picture that digikam does not recognize anymore because of the renaming and are therefore lost ?

Is it correct ? If so, I suppose there is nothing more digikam can do, except automatically reread metadata of files whose name has been changed outside of digikam (which was the main issue when I raised this bug report but is solved since comment #12).
Do you agree with that ?

Hi Nicofo,

Renaming a file is not seen as a new picture, as the contents still the same. Remember that the registration in database to identify a (new) file is based on a checksum of the first 100 bytes of file. If the file is just renamed and have been registered previously in the database, the algorithm will re-detect the previous file as well. It's not a new one.

Also, remember that the digiKam settings has an option to monitor external changes from collection contents:

https://docs.digikam.org/en/setup_application/collections_settings.html

Best

Gilles Caulier

Maik, 

I'm not sure if we can do something better for this entry. What do you think about ?

Best

Gilles

I tested the external renaming scenario again. Anyone who makes such external changes must activate the metadata option for "Rescan file when files modified". Then the metadata of the renamed images will be updated correctly.

Maik

Hi Maik,

Well i do not see what's we can improve for this entry... 

Gilles

(In reply to caulier.gilles from comment #18)
> If the file is just
> renamed and have been registered previously in the database, the algorithm
> will re-detect the previous file as well. It's not a new one.

Hi Gilles, Maik. Thanks to continue the bug triage ;)

I'm a bit confused with your sentence above: if digikam re-detected the previous file, why is digikam not able to reapply the correct attributes ?
 -  I have well activated the option "Rescan file when files modified".
 -  I suppose that it is why the metadata are well correct after the rename operation (e.g. orientation, Camera model, Geolocalisation, ...)
 -  But I don't see why Database-only information is not correct (Ratings, Label, Captions, ...)

See results in screenshots from comment #14 (still valid with DK 8.0)

Of course, a re-scan assumes that the information is also available in the image metadata. I can't reproduce the issue when the color or rating label metadata is present. From the pure database information, this is difficult to resolve, as Marcel writes, the name is an important part. If we change that, we have completely different problems.

Maik

(In reply to Maik Qualmann from comment #23)
> Of course, a re-scan assumes that the information is also available in the
> image metadata. I can't reproduce the issue when the color or rating label
> metadata is present.
You mean that you have color or rating label in the picture's metadata ?
Then of course the re-scan (due to "Rescan file when files modified") solves the problem.
In my case, color or rating label is NOT in the picture's metadata (only in the database).
Can you reproduce the problem with things only in your database ?

If well, based on what you write below, I suppose you can close this issue:
> From the pure database information, this is difficult
> to resolve, as Marcel writes, the name is an important part. If we change
> that, we have completely different problems.

@Nicofo,


What's about this file using current 8.2.0 AppImage Linux bundle ? It's
reproducible ?

https://files.kde.org/digikam/

Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110.

Thanks in advance

Gilles Caulier

Hello Gilles,

yes, problem still reproducible.

My settings:
 - Settings > Metadata > "Rescan file when files are modifies" is checked
 - Settings > Metadata > (Write to metadata) Captions and titles / Rating / ... is NOT checked
 (I understand that these options replace the old "Clean up the metadata from the database when rescan files" option ?)

My pictures:
 - has no Captions / titles / Rating in the metadata (these are ONLY in digikam DB)

After renaming operation (outside of digikam) -> same problem as comment #14

After your explanations and those of Maik, I understand that, since the file name is changed outside of digikam, it is difficult to "reassign" the proper Capions / Rating / ... to the proper pictures. As I said in comment #24, I suppose you can close this issue.