Bug 386291 - lazy synchronization
Summary: lazy synchronization
Status: REPORTED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Hub (show other bugs)
Version: 7.3.0
Platform: Microsoft Windows Microsoft Windows
: NOR major
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-28 19:57 UTC by stefan.mueller.83
Modified: 2024-03-28 07:03 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
attachment-3941976-0.html (966 bytes, text/html)
2023-04-20 05:48 UTC, stefan.mueller.83
Details

Note You need to log in before you can comment on or make changes to this bug.
Description stefan.mueller.83 2017-10-28 19:57:48 UTC
Lazy synchronization (Settings - Metadata - Behavior tab)
It is supposed that digikam won't sync until you click on the sync icon in the bottom bar. Digikam is also supposed to sync when you close it. 

Is not working, pictures disappear immediately after name is set/confirmed. Settings - Metadata - Behavior tab -> uncheck Rescan doesn't help either.
Comment 1 Maik Qualmann 2017-10-28 20:28:41 UTC
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
Comment 2 stefan.mueller.83 2017-10-28 20:35:36 UTC
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?
Comment 3 stefan.mueller.83 2018-02-28 12:44:59 UTC
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
Comment 4 caulier.gilles 2018-12-31 11:51:00 UTC
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/
Comment 5 stefan.mueller.83 2018-12-31 13:44:28 UTC
Will to next week as I currently away
Comment 6 Maik Qualmann 2018-12-31 14:00:08 UTC
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
Comment 7 stefan.mueller.83 2018-12-31 19:55:24 UTC
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?
Comment 8 Maik Qualmann 2019-01-01 07:51:15 UTC
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
Comment 9 stefan.mueller.83 2019-01-01 10:01:50 UTC
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.
Comment 10 stefan.mueller.83 2019-01-05 22:08:18 UTC
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.
Comment 11 caulier.gilles 2020-07-14 09:41:33 UTC
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
Comment 12 caulier.gilles 2020-08-04 16:38:31 UTC
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
Comment 13 caulier.gilles 2021-03-30 08:32:12 UTC
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
Comment 14 hgx9j8a34lvl 2021-11-18 12:38:04 UTC
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?
Comment 15 Maik Qualmann 2021-11-18 13:08:54 UTC
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
Comment 16 hgx9j8a34lvl 2021-11-18 13:44:38 UTC
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)?
Comment 17 caulier.gilles 2023-04-20 05:40:27 UTC
@stefan

digiKam 8.0.0 is out. Problem still reproducible ?

Best regards
Gilles Caulier
Comment 18 stefan.mueller.83 2023-04-20 05:48:21 UTC
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.
Comment 19 caulier.gilles 2023-05-16 03:02:25 UTC
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
Comment 20 caulier.gilles 2023-05-16 03:02:33 UTC
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
Comment 21 caulier.gilles 2023-10-15 12:48:58 UTC
@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
Comment 22 caulier.gilles 2024-03-28 07:03:13 UTC
@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