https://bugs.kde.org/show_bug.cgi?id=527286

            Bug ID: 527286
           Summary: Write Metadata to Files for a list of items
                    (selection, saved search or tag) from the command
                    line, DBus or the Batch Queue Manager
    Classification: Applications
           Product: digikam
      Version First 9.1.0
       Reported In:
          Platform: Microsoft Windows
                OS: Microsoft Windows
            Status: REPORTED
          Severity: wishlist
          Priority: NOR
         Component: Maintenance-Metadata
          Assignee: [email protected]
          Reporter: [email protected]
  Target Milestone: ---

Feature Request.

Hi - I maintain a 137,000-item digiKam 9.1.0 library on a MariaDB backend
(NVME), Windows 11). Tags and labels are applied in bulk.

I use my own PY scripts that write to the Maria database while digiKam is
closed. Each batch say 10,000 files then needs "Write Metadata to Files"
applied for just those items, so today the only way I know how to do this is by
hand cranking via the GUI. I would like a scriptable entry point.

My Current WORKFLOW
1. The script creates a DigiKam saved search containing all the affected item
ids this is (Searches.type 2, field "imageid", relation "oneof", the same XML
the duplicates finder writes).
2. next I bring online DigiKam and In digiKam, I open the saved search, press
Ctrl+A, choose the Item menu > [Write Metadata to Files], wait, till processed
- then delete the saved search.
3. This I repeat for every batch. This week that was four batches covering more
than 50,000 items in total.
A full Tools > Maintenance > Sync Metadata is not a substitute: as on this
library it takes about 20 hours
(see bug 526185 on the single-CPU limit). The manual step also sits next to
"Reread Metadata From Files", which overwrites the database from the files, so
an unattended way to run the writes would also remove a risk.

What I see that the code already has -
core/utilities/maintenance/tools/metasync/metadatasynchronizer.h lines 48-56:
MetadataSynchronizer this has a constructor taking an ItemInfoList with
SyncDirection WriteFromDatabaseToFile. The GUI selection action uses it,
therefore I think syncing an arbitrary id list needs no new engine code.
- core/utilities/maintenance/main/maintenancesettings.h lines 45-49: the
maintenance tool can already be restricted (scoped)  to albums or to tags, but
only through the dialog.
- core/app/main/org.kde.digikam.xml: the DBus interface exposes downloadFrom,
downloadFromUdi and autoDetect only,
  and digikamapp.cpp registers it only under HAVE_DBUS, so not on the Windows
build.
- core/app/main/main.cpp lines 254-265: command-line options are download-from,
download-from-udi, detect-camera,
  database-directory and config. None concerns metadata.
- The Batch Queue Manager has no option to "write metadata from database to
files" tool. Bug 144858 asks for batch metadata
  *editing* in BQM, which I think is a different request.

My Request 
Any one of these would solve it:
1. A command-line option, for example digikam --write-metadata <i tag name>,
that runs
   MetadataSynchronizer(ItemInfoList, WriteFromDatabaseToFile) headless or
against the running instance and exits ideally with a count. A separate,
clearly named --read-metadata would
2. A DBus method (and a Windows equivalent such as a local socket or a command
file in the config directory):
   writeMetadata(ids) / syncSearch(name), with a finished signal.
3. A Batch Queue Manager tool "Write metadata to files", so a queue can be
built from any selection or search and run in the background.
Minimal variant: allow Tools > Maintenance > Sync Metadata to be restricted to
a saved search in addition to albums and tags. The settings struct already
carries an AlbumList for taed to create the search.

some additional info which may help
Related: bug 526185 (full Sync Metadata duration on large libraries), bug
144858 (BQM metadata editing, different scope). I am willing and happy to test
a patch on this library.

Thank you.

A

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to