Bug 386291

It is not quite clear which images disappear? What action? The database is updated immediately. Only the changed metadata will be written into the images only when the sync button is pressed or when the program was finished.

Maik

I've been explained that the database won't be updated until sync button is pressed. 
I don't want the search results (e.g. face recognition) to be updated when I change/add a property (e.g. person tag).

When I do face recognition and change and/or confirm a recognized face it disappear immediately from the Unconfirmed collection (same in other collection). As digiKam takes a moment to refresh the collection and thumbnails moving up and down until all non relevant photos are disappeared I've already confirmed some face tags accidentally although the tag is wrong.
Is it possible to prevent auto-refresh and have it be done by the users themselves?

any chance to add option that it will be possible to prevent auto-refresh and have it be done by the user themself?
It's getting really nasty to find wrongly tagged faces again and again

Can you reproduce the dysfunction using the last digiKam 6.0.0-beta3 just
released ?

https://www.digikam.org/news/2018-12-30-6.0.0-beta3_release_announcement/

Will to next week as I currently away

There is no change in the function here because the operation is misunderstood for Lazy synchronization. Of course, the database is always updated, where else should all changes be saved, which should later be written to the files? The desire that images after the taggen not remove from the face recognition view, is also not realizable. The image model filters for unknown faces, when they get a name they are no longer unknown.

Maik

For clarification, lazy synchronization (Settings - Metadata - Behavior tab) is supposed that digikam won't sync database, sidecars or images (depending where metadata shall be stored) until you click on the sync icon in the bottom bar, isn't it? 

Digikam is also supposed to sync when you close it regardless of the above setting,isn't

If that is the case my mentioned observations in the OP should not happen. If I misunderstande something, could you explain what? 
In the second case how can I prevent things to happen as observed?

Lazy synchronization is about the delayed writing of metadata FROM the database into the images / sidecar.
The database is always up to date, otherwise digiKam would not work.

Maik

first of all the obligatory, happy new year :)

so how can I prevent 

>When I do face recognition and change and/or confirm a recognized face it disappear immediately from the *Unconfirmed* collection (same in other collection).
>As DigiKam takes a moment to refresh the collection and thumbnails moving up and down until all non relevant photos are disappeared I've already confirmed some face tags accidentally although the tag is wrong.

Hallo Maik,
if the described behaviour cannot be prevented I would like to have a stop/start screen refresh or un-/freeze database operations button. It may need to be activated first in the options menu. As soon as the button is pressed DK won't alter the refresh the thumbnail windows or the database and thus the displayed images won't be updated.

Any change on the metadata shall lead either to a strikethrough of the deleted tag or mark new ones yellow (or whatever color you prefer).

That would spare not little frustrations and thus save me a lot of energy.

Hi,

Can you check if this problem still exist with last weekly bundle build of digiKam 7.0.0 available here:

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

Thanks in advance

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

digiKam 7.2.0 official release is published with more than 360 files closed from bugzilla:

https://www.digikam.org/news/2021-03-22-7.2.0_release_announcement/

Can you reproduce the dysfunction with this version ?

Thanks in advance for your feedback

Gilles Caulier

the issue is still there (latest published version).

The problem statement is the following:
When we map faces to people (using sqlite or MySQL with lazy sync on) - large collection from the people/individual folder :
1. Digikam (on windows) holds for 30 sec after I map few faces (sometimes one, sometimes 10)
2. In practice, Digikam is doing some processing on the pictures and map the face(s), then the pictures move from "to be confirmed" to "confirmed"

In order to make the user experience better:
1. Is it possible to delay this processing so it does not block DigiKam?
2. Is it possible to map the faces in-line: when the faces are mapped, they should no move under the "confirmed" section right away because when it happens, the screen is changing and if we clicked somewhere while DigiKam was blocked, we are not sure which action was made.
Does it clarify?

Again, the whole thing here has nothing to do with lazy synchronization at all. The lazy synchronization writes the metadata into the images at the end of the program or manually. We cannot delay writing to the database. As long as the thumbnail view has the focus, the view updating could be suspended. However, this could lead to other problems.

Maik

Hi Maik,
What could be done to make the mapping face process faster for the user and less error prone (avoiding refresh on the screen)?

@stefan

digiKam 8.0.0 is out. Problem still reproducible ?

Best regards
Gilles Caulier

Created attachment 158225 [details]
attachment-3941976-0.html

Cannot tell at the moment, I don't use it currently (travelling)

sent from a fair mobile

On Thu, 20 Apr 2023, 07:40 , <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=386291
>
> --- Comment #17 from caulier.gilles@gmail.com ---
> @stefan
>
> digiKam 8.0.0 is out. Problem still reproducible ?
>
> Best regards
> Gilles Caulier
>
> --
> You are receiving this mail because:
> You reported the bug.

Git commit 3d71acc72593534c2a1398d2945992fbbf45935a by Gilles Caulier.
Committed on 16/05/2023 at 03:00.
Pushed by cgilles into branch 'master'.

Switch bundles from Exiv2 0.27 maintenance branch to new 0.28 release
Related: bug 452567, bug 468830

M  +11   -8    project/bundles/3rdparty/ext_exiv2/CMakeLists.txt

https://invent.kde.org/graphics/digikam/commit/3d71acc72593534c2a1398d2945992fbbf45935a

Git commit 3d71acc72593534c2a1398d2945992fbbf45935a by Gilles Caulier.
Committed on 16/05/2023 at 03:00.
Pushed by cgilles into branch 'master'.

Switch bundles from Exiv2 0.27 maintenance branch to new 0.28 release
Related: bug 452567, bug 468830

M  +11   -8    project/bundles/3rdparty/ext_exiv2/CMakeLists.txt

https://invent.kde.org/graphics/digikam/commit/3d71acc72593534c2a1398d2945992fbbf45935a

@stefan.mueller.83@gmail.com,


This problem still reproducible with the new digiKam 8.2.0 pre-release Windows
installer available at usual place:

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

This new bundle is based on last Qt framework 5.15.11 and KDE framework 5.110.

Thanks in advance

Gilles Caulier

@stefan,

digiKam 8.3.0 stable version is released and available at usual place :

https://www.digikam.org/download/

Can you reproduce the dysfunction on your computer ?

Thanks in advance

Gilles Caulier