Try changing database=:memory: in your darktablerc file and see if that changes the behavior? It seem that in theory launching with --library :memory: should do the same thing, but perhaps it does not. On Sun, 2019-04-07 at 16:36 -0400, Patrick Shanahan wrote: > * Benjamin Daines <ben@digitalsand.photography> [04-07-19 13:56]: > > Don't get hung up on the example file names I used in the > > email. Theissue that I'm having is with the database "disabled" > > darktable doesnot recognize additional versions of images that are > > created (viaclicking duplicate in darktable, which creates a second > > xmp file forthe image). What's worse is when you open the folder > > in darktableafter closing it, not only is the version you've > > created gone, but ifyou create the second version again DT > > immediately overwrites thesecond xmp file. Hopefully that makes > > more sense. On Sun, 2019-04-07 at 11:50 -0400, Patrick Shanahan > > wrote: > > > * Benjamin Daines <ben@digitalsand.photography> [04-07-19 11:04]: > > > > Importing the folder doesn't recognize versions > > > > eitherunfortunately. On Sat, 2019-04-06 at 13:54 -0400, Patrick > > > > Shanahanwrote: > > > > > * Benjamin Daines <ben@digitalsand.photography> [04-06-19 > > > > > 12:51]: > > > > > > The issue I'm running into now, with database=:memory: is > > > > > > thatifI'veduplicated an image so that I've got two xmp > > > > > > files forthe sameimage(say IMG1.xmp and IMG1_01.xmp), when > > > > > > I close thefolder andopen itagain, DT only reads the > > > > > > initial image, notthe secondversion. If Ithen create a new > > > > > > version, DTimmediately overwritesIMG1_01.xmp, sounless I've > > > > > > copied all myxmp files to asubdirectory, that work > > > > > > islost. It would be bestto have darktableautomatically > > > > > > create these versionswhen seeingIMG_01.xmp.Hopefully that > > > > > > makes sense. On Tue, 2019-04-02 at07:20 +0300, JuhaLintula > > > > > > wrote: > > > > > > > Hi!I also use darktable only for image processing and > > > > > > > havethesamesetting as Robert; database=:memory: This > > > > > > > settingwillalwaysautomatically read the .xmp files as you > > > > > > > arealwaysstarting with afresh database.-JuhaOn Tue, 2 Apr > > > > > > > 2019at 05:20, Patrick Shanahan <p...@opensuse.org>wrote: > > > > > > > > * I. Ivanov <iv3...@gmail.com> [04-01-19 20:03]: > > > > > > > > > On 2019-04-01 16:34, Patrick Shanahan wrote: > > > > > > > > > > * Benjamin Daines <ben@digitalsand.photography> > > > > > > > > > > [04-01-19 > > > > > > > > 18:46]: > > > > > > > > > > > In my workflow I find myself using multiple > > > > > > > > > > > machinestowork > > > > > > > > on the > > > > > > > > > > > same images. My configuration right now on > > > > > > > > > > > bothmachinesis > > > > > > > > to have DT > > > > > > > > > > > look for updated xmp files on start up and that > > > > > > > > > > > seemstowork > > > > > > > > pretty > > > > > > > > > > > well. I usually just ignore the window that pops > > > > > > > > > > > uptotell > > > > > > > > me about > > > > > > > > > > > newer xmp files, unless the ones that I'm about > > > > > > > > > > > toworkon > > > > > > > > are listed, > > > > > > > > > > > then I select those and let it update > > > > > > > > > > > thedatabase.However, there have been some > > > > > > > > > > > situationswhere myprevious > > > > > > > > work has > > > > > > > > > > > been wiped out when opening a folder on > > > > > > > > > > > anothermachine. > > > > > > > > Because of > > > > > > > > > > > this, I now habitually copy all my xmp files > > > > > > > > > > > toasubfolder > > > > > > > > after > > > > > > > > > > > working on them in order to keep a back up, > > > > > > > > > > > justincase. > > > > > > > > Occasionally > > > > > > > > > > > I need to manually load these sidecar files.Would > > > > > > > > > > > anoption to disable darktable's database and > > > > > > > > > > > usejust > > > > > > > > the xmp > > > > > > > > > > > files be a feasible option? How about > > > > > > > > > > > usingsomethinglike > > > > > > > > syncthing > > > > > > > > > > > (Linux platform here) to keep the database > > > > > > > > > > > syncedbetween > > > > > > > > multiple > > > > > > > > > > > machines? Would doing that cause any > > > > > > > > > > > foreseeableissues?How are other people dealing > > > > > > > > > > > with usingmultiple machinesto > > > > > > > > work onprojects, any tips? > > > > > > > > > > when I use any machine beside my main workstation > > > > > > > > > > toedit > > > > > > > > photos, I issue > > > > > > > > > > darktable as: darktable --library > > > > > > > > > > :memory: importthe photos to be edited finish > > > > > > > > > > the edits closedtand back at my workstation, re- > > > > > > > > > > import the editedphotoswith > > > > > > > > their > > > > > > > > > > accompanying xmp files.have not encountered > > > > > > > > > > anyproblems with this work plan. > > > > > > > > > In theory... if you have 2 identical machines > > > > > > > > > (forexamplelinux)shared network location for DT > > > > > > > > > filessharednetwork location for the DB, configuration > > > > > > > > > filesandcachesame mounting point for the 2 > > > > > > > > > machinesyou coulduse DT on one or the other (one at a > > > > > > > > > time) and the > > > > > > > > changes should > > > > > > > > > be on the 2 machines.BUT... I haven't tested the > > > > > > > > > scenarioplease back up if youwant > > > > > > > > to try it. > > > > > > > > > On the other hand - what Patrick is pointing to is > > > > > > > > > basedon > > > > > > > > experience. > > > > > > > > IF, IF, IF you NEVER run dt at the same time > > > > > > > > ondifferentmachines,onecould share the db placing it > > > > > > > > onnetworked storage. BUT NEVERRUNDT ONTWO MACHINES AT > > > > > > > > THESAME TIME. > > > > > > > > > > > > Thanks. > > > > > > > > > > try instead, to import the image instead of just reading > > > > > thexmpfile. Ihave not seen that happen to me and I do > > > > > haveduplicateimages withdifferent crops. it appears your dup > > > > > imagesare not beingcreated withthe same filenames reflected > > > > > by youroddly number xmpfiles. but ... > > > > > > versions of what?importing an image not in dt's db will utilize > > > the acompanying xmp. you have something irregular wrt your > > > filename and accompanying xmpfiles. if the filenames to the xmp > > > files do not match, iiuc, the xmpis notrelevant, ie: not > > > utilized. you appear to be defeating thevery actionyou wish to > > > utilize. > > I understand what you are saying, but I do not see that from my > systems. in fact, I just tried it again: darktable --library > :memory opened a single image made three dups with different > edits exited dt restarted darktable --library :memory: again > opened previous image all three edits of the single image are there > running dt master git901.e2188ea4bopenSUSE Tumbleweed > 20190403images: 181213_133958_aaa_2622.nef 181213_122731_aaa_2621.n > ef.xmp 181213_133958_aaa_2622_01.nef.xmp 181213_133958_aaa_2622_02. > nef.xmp >
signature.asc
Description: This is a digitally signed message part