I just edited an image, which was the only one in a folder, as part of a test for another user. I exported it to disk and then went to send the .dop file to the other user.
There was no .dop file in the folder until I selected another folder in the library.
I noticed that too. It takes time, sometime. But after a while it’s written.
I just clocked it, after 35s. In my case.
George
Yes. By thinking about, it’s a normal behavior.
By switching image, PL knows thie end of this phase of the adjustment.
Pascal
Yes, as Pascal confirms, it’s common for PL to take a while to create the sidecar/.dop file - - it usually takes some “action” (like selecting a different folder, in your example) for PL to decide it’s time to spit one out.
John M
Ah, that’s going to be yet another thing to be aware of. I presume/hope they’re writing to the database straightaway? The apps I write update the DB/file after every change, just to ensure that, if the app quits unexpectedly, the loss is minimal.
Yes. I verified it with a crash 
Pascal
I suspect that’s the issue, Joanna; in determining when a change has been made … I doubt (tho I have no way of knowing for sure) that every single “element of change” is written to the DB … it’s more likely that it’s updated only after some triggering event.
John
Why would the dop-file needed to update after every movement/change of an adjustment?
Me personal find it quite normal if it’s backup every 15min or by moving to the next image. Continuous syncing is a bit too much for the need or not?
I perver even a possible selective lock setup, update only on command, to prevent unwanted dopfile updating.
(In preference it’s only write or not in general. And you can manual push dopfile writing.)
If i could select a folder to “lock” and disable auto update for that folder only , then we have protection. ( now do sefond best. When finished a folder i copy the dops into a backupfolder inside the original folder.) need to remember to copy wanted updates doh.
And I would like to have the possibility not writing at all. So just editing without saving the edits. In that case an update of the file would only be after leaving the image.
George
Asynchronous writing of sidecars seems sufficient in most cases, unless the system is so unstable that you fear losing edits almost all the time.
My experience is that PhotoLab’s database is stable enough and maybe it is so on my Mac because I don’t automatically read or write sidecars. I find that managing sidecars manually lets me control exactly, when and which sidecars to read or write. Moreover, as long as keywords are only kept in DPL’s database, sidecars are less useful for information exchange.
It is recommended to NOT write sidecars automatically in Lightroom in order to improve its performance. Why not try this in DPL?
Are we sure this isn’t a disk cache issue? I don’t know how to configure this on Mac, but on Windows I use Intel software to configure the writeback caching behavior for each SATA storage device. Just a suggestion so that we don’t rule anything out too quickly.
I don’t believe that writing to the sidecar/.dop file (by PL) is causing any problem or delay (that I’m aware of) - - and I’ve never encountered any problem with PL’s current timing of updates to sidecar/.dop files.
But, I work the opposite way to you, Platypus - - I depend only on the sidecar/.dop file - and I delete the DB on a regular basis (which I can do as I have no interest in any PL’s DAM capabilities).
John M
… that’s normal as you are dangling head down at the opposite side of the earth (just kidding).
I still use Lightroom because it does what it does. Mostly use it without sidecars as proposed by Lr’s default settings and yes, I use keywords a lot.
Edit: When I started testing DxO OpticsPro a few years ago, deleting the database was often the (only) way to get rid of issues. We’ve come along way. Deleting the database has not been proposed by DxO as a bugfix for a while. How should they propose to flush all the keywords and make users unhappy? I still trash the database every few days or weeks for leaner operations and do it happily because the important stuff is in Lr and in the backups.
I’ve come to like DPL quite a lot, but only use it as a plug-in for Lr in which I also use a plug-in that helps a lot to bring my old negatives alive again.
“The Grotto”, Western Australia, 1988. Follow the path down to the pool!
Even the water swirls/rotate other way around in the sinkdrain. You can’t help it John it’s radiated in you by the earth… 