Bug 222401 - Write only changed metadata to file using single button or on exit
Summary: Write only changed metadata to file using single button or on exit
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Hub (show other bugs)
Version: 3.0.0
Platform: openSUSE Linux
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-12 17:05 UTC by docali
Modified: 2020-08-30 15:43 UTC (History)
3 users (show)

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

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description docali 2010-01-12 17:05:57 UTC 
Version:            (using KDE 4.3.4)
OS:                Linux
Installed from:    openSUSE RPMs

When tagging photos in the collection, eventually covering multiple albums sometimes only few pictures are actually changed. 
At the moment you can choose  to let changes directly be written to file or store them in the database only via the configuration menu - write tags to keywords. After finishing you can sync the database and all metadata is rewritten. This is quite time consuming when the collection is big. So an additional field in the database "Changed since last sync" might be useful to speed up the process by writing only to the files with changed metadata. 
At the moment you have to change the settings, choose the write to file options, sync every album where you changed something and turn off write to file for speed reasons again. 

Is this possible?
Comment 1 caulier.gilles 2011-12-17 09:27:49 UTC 
Docali,

This file still valid using digiKam 2.x serie ?

Gilles Caulier
Comment 2 julien.t43+kde 2013-02-21 18:46:01 UTC 
Related to Bug 227814 - "Write metadata immediately" option
AFAIC, I would say still valid for 2.x and 3.0
Comment 3 caulier.gilles 2014-08-28 15:56:46 UTC 

*** This bug has been marked as a duplicate of bug 227814 ***
Comment 4 caulier.gilles 2020-08-30 15:43:30 UTC 
Fixed with bug #227814