Oh help! DT 4.0 won't start after trying insider build (sorta solved!)

So ya in the future… I suggest parallel version…use --configdir “path” where path is a folder for the config files…this leaves your main install intact and then if things are good you can try to move in one direction or the other … Also I turn off xmp writing for expt versions so as not to accidentally mess up xmp files… 2 small steps but worth it… basically this is the recommended path to go as given in the git readme…

I’ll check the git readme later, but do I stick the --configdir “path” on the end when starting dt from a terminal? (daft question probably)

Im on Windows so I do this sort of thing from shortcuts… and yes at the end or your command line… I also use them to redirect my cache directory to a spare drive… there is a section in the manual. All explained here… darktable 4.0 user manual - program invocation

EDIT and if it was not clear “path” should be replaced by the desired destination for your files… I often just make a config directory named that in my exptal DT program folder for temp versions…

Thanks Todd. I reinstalled Bill’s 4.1 version, then used configdir to set a different folder, and it works. And 4.0 is still working this time! I’m not sure how to use a shortcut to do the configdir thing on win 11, though… and I’m still getting a crash with Bill’s version (see other thread)

Seems like some things are jumbled I guess…

As for shortcuts very easy…if you installed DT for windows you should have one…you can just copy it and then rightclick for properties and then edit the command line and likely the description so you know what it does…

You could also right click on the DT exe file and create a shortcut from there…

“C:\Program Files\darktable\bin\darktable.exe” --configdir “C:\DT_configdir” --cachedir “C:\DT_config” --tmpdir “C:\DT_config”

I would use something like this to direct files where I want them…

So it is! Thanks for the example… I was almost right, but I put the --configdir etc. inside the " " instead of after. Not sure why! That was the problem. The fact that it didn’t work made think I must be missing something. And I was, but it was right under my nose. :grinning:
Thanks again for the help!

1 Like

I have tried this with darktable-4.1.0+865~g70da6dcc8-win64
Installed in a separate directory called DTdev
Created an empty directory called config in the darktable folder inside DTdev:

Created from a bat file called run_dt in the darktable folder with the contents:
.\bin\darktable --configdir “.\config” --cachedir “.\config” --tmpdir “.\config”

When it runs it says the database is locked
Tried rebooting, always happens
Any clues to what I might be doing wrong?
If it is really complicated, I will wait till Christmas, as have a lot of other stuff on.
Many thanks!

The database lock is managed using lock files. After the reboot, delete them:

Thanks @kofa.
What I don’t understand is that I am using a different config folder when I run it, rather than the app data/darktable folder so that it doesn’t interfere with my main build.
The config folder is empty, no database or lock files in there.
I must be doing something wrong, but can’t work out what it is, as I have run other experimental builds in this way…

You must have just had a crash or exit from DT that didn’t clean up…where are you running the batch from…is that going to run DT from DTdev??

Can you show the shortcut or batch file you use to launch darktable? Maybe you only think the path was properly altered.

I’m pretty vague about this sort of thing, but if you made your ‘config’ folder in the darktable folder wouldn’t you need to give the full path to it instead of just .\config ? I thought that would make dt look to find the config folder in your home directory…
I mean give the full path at each instance of config in the path I quoted.

But I may well be missing something - :grinning:

+1 I don’t think .\config would work on windows. Use the full windows path (c:.…)

Thanks for the suggestions so far.

It is strange: using
.\bin\darktable --configdir “.\config” in the bat file
Opens darktable but says the database is locked

I have an earlier experimental build using exactly the same method, and there is no problem.

The black command line box shows that it is the DTdev version that is running

If I use the full path name in the bat file
C:\Program Files\DTdev\darktable\bin\darktable --configdir “C:\Program Files\DTdev\darktable\config”
The program doesn’t open at all. Is there something I have typed in wrong?

I am wondering if the problems are the contents of the config directory
Should I start with an empty config directory, or should I have the particular files in there? I believed that if it was empty, then darktable would start with a new database and default settings.
If people are bored with this, then I am happy to call it a day, as it is just looking at my own problem, and not of interest to others…and I still have a perfectly good version of darktable to use.

C:\Program Files\DTdev\darktable\bin\darktable.exe --configdir C:\Program Files\DTdev\darktable\config

Try using the .exe and without the extra " "

There is still a darktable process running in the background. US e the task manager to kill it, then you can restart

I don’t think storing the config directory under C:Program Files is a good idea. Normally, users should place their files under C:\Users\<userName>.
What happens if you change your batch file to --configdir "%USERPROFILE%\DtDevConfig" (also, your post used typographic quotes (“) instead of straight quotes (") → those should be straight quotes.

Alternatively, for an even more Windows-standard solution, use %APPDATA% instead of %USERPROFILE%.

Either way, at the command line, create the DtDevConfig directory. Either
mkdir "%USERPROFILE%\DtDevConfig" or mkdir "%APPDATA%\DtDevConfig".

Then use the same variable in your .bat file.

Let me know if that changes anything.

Many thanks for your help folks
Finally got it to work with this combination:

.\bin\darktable --configdir “C:\Users\Username\Documents\config”

Not sure why, but it works!

1 Like

Probably because writing to C:\Program Files requires extra permissions.

1 Like

Makes sense…