Version: 1.7.0 (using KDE 4.5.1) OS: Linux Reproducible: Always Steps to Reproduce: View a picture Set one tag (or unset or edit comment or ...) Hit Ctrl-1 to assign rating one star Actual Results: rating hasn't changed Expected Results: rating should change to one star I tried to fix this on my own but to no avail so far. Found out the following: First MetadataManagerDatabaseWorker::assignRating is called and sets the correct rating Then via DigikamView::slotDispatchImageSelected a call to MetadataManagerDatabaseWorker::applyMetadata happens, but here the hub is still filled with the old rating, so the picture rating gets overwritten again with the old value.
Marcel, Do you see this entry ? // --------------------------------------------------------------- To Reporter, Can you test with 1.8.0, or 1.9.0 (current implementation) I cannot reproduce the problem with 2.0.0. Can you confirm ? Gilles Caulier
I have no 1.8.0 or 1.9.0 installed, but in 2.0.0-beta3 the problem still exists according to my tests.
This problem still persists in version 2.5 To reproduce: - Modify settings to embed metadata in image files - open a image with normal albumview - Press Ctrl-3 to assign rating 3 (you see the rating changed to ***) - assign a tag by clicking with the mouse in the tags-Tab. (or assign a pick label/color label) - DON'T press the Apply-Button, it needs to be active (not greyed out) - Press Ctrl-1 What happens: rating gets changed to 1 star (*) (you sometimes can see that). then the tag info gets applied automatically and rating returns to 3 star (***), since thats what is still under the description-Tab Expected Results: rating should change to one star
I can reproduce the problem with one additional step after "Press Ctrl-1": - select another picture (triggering to apply changes from the right side tab) Problem: ImageDescEditTab::slotReloadForMetadataChange() bails out if there have been user edits. Solution: change tracking, which adds another level of complexity to metadata hub
Marcel, We have fixed something following your comment #4 with 3.x serie ? Gilles Caulier
I doubt anything has been changed. It's a not trivial amount of work for a detail.
*** Bug 330924 has been marked as a duplicate of this bug. ***
Rolf, This file still valid using last digiKam 5.0.0 ? Gilles Caulier
Any feedback with current AppImage bundle for Linux ? https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM Gilles Caulier
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
@kde@schreiber-rolf.de digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
@kde@schreiber-rolf.de, 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
I can confirm, that the bug still exists in version 7.5.0. I will test on 8.2 once I've installed that one.