Try with out quotes maybe I steered you wrong I was going from memory
1 Like
1 Like
It takes out the backslashes too
I try not to use paths with spaces but it may be that you need to add _ character where you have spaces or pick a simpler path but it should work and the quotes are needed I believe…I posted a screen shot of mine…it does have an underscore as well but in this case that is actually in the name of the folder
1 Like
I am on thin ice here, but on my (working) Windows installation, here is what my standard installation reports:
1 Like
HOLY SHIT THAT WORKED. Idk even know why or how but it did it. They aren’t reverting & I can work in different folders and everything. How do I make sure not to screw it up again since i don’t really understand what just happened very well at all? Thank u thank u thanks u so much tho. I was about to give up. Whew. U all are super awesome.
I’m just gonna leave that shortcut & the config file alone on my desktop and hope it stays all good. I would tag u all to say thanks but as a new user I can’t. But thank u so much.
NP Bronson…so this is what I do with DT. I run it with that command line change. That keeps my config files in a folder that I specify different from my install folder where DT puts them. I can routinely or in any fashion back this folder up. So now when I install a new version I can just install over the last one and not worry as much as it will only alter files in my install directory. Then when I run the new version the first time with the command slash it will modify modify my database files in the alternate directory but if it messes them up I have a backup handy and I can just do a reinstall of a previous version and then copy back my files from the back up and I am good to go…lots of ways to do it…if you look in the manual it lists near the start all the command line switches that you can use…
1 Like
Just back up that config dir that you created before you run a new version of DT for the first time. DT now does do a backup of your previous databases when it upgrades but as an extra precaution why not have a back up of the intact original files…then you can easily revert…
1 Like
Ok that makes sense. Those files control all ur presets & custom settings & stuff? So when u install a new version & it wigs out u can take the old config files & tell it what’s up.
The configuration and operation files of darktable.pdf (183.9 KB)
This is a little old and many DT users don’t really know about this level of detail but I think its good to know how the nuts and bolts fit together…
@Claes
2 Likes
o wow this is cool. I’m really trying hard to get to know this kind of stuff better because super technical issues like this are just a solid brick wall if you don’t get it. I really appreciate the help.
1 Like
I’m so excited haha. I’ve been trying to fix this for like 2 weeks & I super need it for my business. U guys are the shit
I’m not a Windows users since many many years so I won’t be able to help on this issue. But to me it really looks like a permissions or antivirus issue.
Next time you may want to try running from the command line to see if darktable outputs any errors.
“Look for updated XMP files on startup” is only required if you modify the XMP files (e.g. from another darktable instance, or DAM software that can add tags), and want to merge the changes into your library DB. In other words, most probably you won’t need it, and turning it on may cause issues (if you accidentally update such a file, it may corrupt your DB).
I am pretty sure it’s a problem of permission on the database file, it happened to me as well, after a Windows update.
So I suggest the following:
navigate to C:\Users\AppData\Local\darktable
right click on library.db and choose “properties” from the context menu
make sure that “read only” checkbox is not selected
What scenario would you accidentally update your file…I would think any changes would accidentally update your database too…I guess if you ran two different databases or computers and wanted those to be discrete databases working with the same pool of images then you might run in to an issue corrupting one database with an xmp modified from the other system…just curious. I turn it on because I have 3 PC’s so my edits are tracked in my xmp files…in fact I really make no use of the library for ratings and tags etc so I have move to using no library and just rely on the xmp files then I have no update issues to worry about …although this won’t work for everyone
What scenario would you accidentally update your file
You try a fancy new image viewer that, by default, start recognising faces or analysing sharpness and exposure to automatically find ‘good’ shots, but it has a bug / does not understand the darktable-specific data in the XMP file and thus corrupts it.
I would think any changes would accidentally update your database too
The chances of others software touching library.db (tucked away in an application-specific directory) is way smaller than touching files of a commonly used sidecar format that are stored next to the images.
I admit the chances are small, of course, and that your use case is perfectly valid. I wrote that
“Look for updated XMP files on startup” is only required if you modify the XMP files (e.g. from another darktable instance
Which is exactly your use case. So if you need this feature, by all means, turn it on; if you don’t need it (‘although this won’t work for everyone’), I think it makes sense to keep the default and handle the database as a master, XMP as output (or input when importing, but only then).
Gottcha…I was not thinking about other software in the mix only DT ….