https://bugs.kde.org/show_bug.cgi?id=528171
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOT A BUG Status|REPORTED |RESOLVED Version| |9.2.0 Fixed/Implemented| | In| | --- Comment #3 from [email protected] --- Hi Andy, Let me clarify and expand on my previous answer. Why two simultaneous instances cause problems : while MariaDB itself handles concurrent connections fine, digiKam is not designed as a multi-user client. Each digiKam instance keeps a large amount of state in memory (album hierarchy, tags, thumbnails, face data, item properties) and writes back to the database on its own schedule, expecting to be the only writer. There is no cross-instance notification mechanism: nothing tells a running instance that another instance changed the database. So instance A can overwrite or undo changes made by instance B, and stale in-memory state gets flushed back to the database which is how you end up with ghost albums referencing folders that no longer exist, and why "Scan for new items" or "Refresh" cannot fix it: those operations reconcile against what the instance believes from its cache, not a full reload of the schema. This is a known architectural limitation, not a bug in the sync logic. The database can be shared, but only by one running instance at a time (for example, one machine after the other, or via a periodic "switch" workflow). How to recover your current setup First, make sure only one instance runs at a time from now on. Then, with a single instance running: Stop the other digiKam instance completely (including the VM one). Run Tools → Maintenance → Database cleanup, which forces the album hierarchy to be re-scanned from disk and reconciled with the database. About your SQLite idea Switching to one local SQLite database per PC would avoid the corruption problem, but it would not synchronize anything: each PC would then have a fully independent database with no link to the other. Your shared library of 132,000 files, the shared tags, and especially the shared face-recognition data would no longer be common to both machines. So no SQLite per PC does not give you automatic synchronization; it gives you two isolated libraries. What I'd suggest for your workflow Keep the central MariaDB, but strictly alternate: only one digiKam instance open at a time. When your wife needs to work, close yours first (and vice versa). The VM instance can still be used as a viewer (read-only image browsing via the filesystem), but not against the same database. Face recognition on a single PC is exactly the right approach that part of your setup is fine, as long as no other instance is running while it processes. Longer term, making digiKam a proper multi-user client (with database change notifications and per-user write isolation) has been discussed, but it is a significant architectural project, not something on the short-term roadmap. We have bug reports about this topic... Best regards Gilles Caulier -- You are receiving this mail because: You are watching all bug changes.
