Using darktable-3.0.0rc1-win64.exe.
The darktable manual says, “Sidecar files automatically synchronize with your work without the need to press a “save” button.” I find that the xmp doesn’t change until I go from darkroom to lighttable. Is there a way to update the xmp while staying in darkroom?
Good question…
Adobe Lightroom does so and users switch it off for performance 
My PC is off for today, but I wonder whether a terminal with watch ls - l ~/.config/darktable/*.db would show, at least the data base gets updated online…
Would be very useful to have the xmp and/or database keep up with edits - in my experience it doesn’t save your edits until you stop working on the image (by quitting, changing image or going back to the lighttable). Darktable doesn’t crash very often but when it does I often find myself having to redo quite a bit of work (it happens more often on images with complicated edits)…
You could have an auto-save interval defined in the preferences, so it saves progress ever x minutes.
…maybe aligned with CPU-load to avoid performance issues?
If I want to be sure my work is saved, I just toggle to light table view with L, then back to darkroom view with D.
I suppose that is not really all that much trouble. I have had that problem of losing work because of a crash.
Yes, being many steps into an edit and have DT crash, which it occasionally does, is a pain. Toggling to lighttable view is a work around, but I don’t want to have to switch modes just to ensure my work is saved. I agree having the sidecar updated right from darkroom mode would be best. Couple of options come to mind - it could either be updated once a new develop module is selected (so it always saves the last module used), or make the “compress history stack” button do double duty to write the sidecar at the same time.
Hi,
if I am not wrong dt DO automatically synchronization while working BUT on the database.
Exiting the darkroom mode then also the XMP file is updated.
In this case it means in case of chrash you can have ONE file not synchronized (and you know exactly on which image you were working).
So you could start dt with the option of synchronize the XMP files on startup, open that folder and your XMP file should be aligned with the database.
I see an option (dt 2.6) to “look for updated xmp files on startup” but that looks like the opposite of what you’re suggesting. Where would I find the “synchronize xmp files on startup” option? Or is it new?
I wonder what the impact of this would be for a large catalog, the “synchronize xmp files” feature already can have a big toll in DT startup.
I think there are two issues here (1) Making sure that you don’t lose edits when dt crashes (2) Making sure the xmp is up-to-date with the database.
I don’t know about the internals of darktable but it would seem to make sense to solve (1) within the database alone - i.e. make sure the history stack is regularly saved to the database using one of the suggested methods. Issue (2) could be resolved by ensuring that darktable knows the last time it updated the history stack in the database and the last time it synchronised the database to the xmp. Then on startup it could re-sync any where the database has a later date. That would probably minimise any performance impact.
This could work independently of the ‘synchronize xmp files on startup’ option which would compare the date/time on the actual xmp files to the ‘xmp last updated’ date in the database. This would have more of a performance impact but in most use cases would not need to be switched on.
I document all my development in a Word file taking screenshots of all the setup in each module, e.g., the masking, all along the way. Periodically, usually depending on what I have accomplished, I switch to lighttable, copy the xmp, and rename it including the file date and time in the name. The xmp name goes into the documentation.
With this method, whenever I want to do something different in the development process, I load the xmp pertaining to the stage at which I want to start over and go from there. I don’t know how the database works, so I don’t know if it could be used this way. If the database can be used to recover the work lost in a crash, I would be interested in learning how to do that.
If you want to take snapshots of your development, the best way to do this would be to create a duplicate of your history stack in the lightroom and then tag each duplicate appropriately (perhaps even with a summary of what you did). You shouldn’t need to copy the xmp file externally to darktable.
This is a different issue, in that I suspect the updated history stack isn’t being written to either the database or xmp file until you exit the editing session.
Looking at the library database it appears there is a ‘write_timestamp’ (which I assume is the time that the xmp was last written) but nothing to record when the database history stack was last updated.
I’ve raised a feature request: Synchronise history stack during edit · Issue #3713 · darktable-org/darktable · GitHub
Thanks. I really didn’t know how to use the database, but when I read your comment about duplicates, I read up on it, and I see how that can be useful for what I want to do. So, thanks for motivating me to learn more.
Bill Martz
@Underexposed @elstoc Just to further things…you edits are stored with your exported JPG…it can be loaded as a sidecar …in the past there could be reasons to keep xmp for very large edits with lots of masks etc but basic edits will be stored in jpg metadata and can be reapplied in lightable via the load sidecar but using the jpg instead of the xmp
@elstoc triggered by change to lighttable or compress stack which can be done at any time or location in the stack…the setting in the preferences is key…I always have it set to check for new files as I edit from multiple sources and I want the local database updated…basically it flags a difference between your database and xmp file …shows you the date and asks whether to update the database with the xmp file or the reverse…if your files were all corrupt and you had a recent backup of your database then you could restore them all otherwise the corrupt files if newer could overwrite settings in your database …basically its a mismatch check and a good one to have its not an automatic resync…
Reading through this tread there’s something I’ve stumbled on that might be of help to some. With regards to crashes while working in darktable, this was a constant source of agony for me. While looking into this, Windows likes to have many programs running in the background (not startup) using memory. My PC has a reasonable amount of memory, 12 gigs for it’s age (10 yrs) running i7 CPU 920 @ 2.67 GHz. Ctrl Alt del to open task manager. Check Apps, processes and background processes. The performance tab might also be of help.
After the last major Windows 10 update, programs were reset to the Window’s default which is ON. For the life of me finding source of the crashes and freezing was frustrating. These problems were most common when using darktable. Maybe loading the large raw folders and files took the memory beyond it’s limits and hence the problems? Since making adjustments the problems have gone.
This is a little off topic about saving the sidecar files but felt it might be relevant. Lots discussions here are way above my pay grade with regards to tech, but maybe by chance this can help someone else who suffers from constant crashing.
Thanks to the team of amazing darktable developers. The program is so much fun to use! You’re all amazing!