darktable windows insider program 8/14

I ended up ditching everything and reinstalling MSYS2 from scratch. I switched to the UCRT terminal when it said to in the instructions. Up until that point I used the MSYS2 terminal.

I don’t think it matters what terminal you run git from.

The Lua warning probably needs changed to “use a windows terminal”, but I would say that it was an oversight.

I’ll see if I can recreate with a random image.

Thanks Bill…I am in the process of doing the same…did you get that msg about search path/variables that I posted above… if so could you direct me how to deal with that…where would I add those references…

Todd, I think that’s just a warning/FYI. It should not prevent you from building.

Okay thanks I just thought it might be linked to the crash during building looking for GTK3…which is clearly installed…I will track it down…

I don’t recall seeing that error. To check your setting open a UCRT terminal and do
env | grep XDG
and see what it shows.

Mine shows

If I do it in a MINGW terminal it shows /mingw64/share/ as the first directory

If it’s wrong then to fix it in the terminal do
export XDG_DATA_DIRS="/ucrt64/share/:/usr/local/share/:/usr/share/"

Your a champ thanks so much I will try that when I get home…very much appreciate the hand holding…

1 Like

Thanks Bill. I’ll post the image I was working on when I get a chance, but it might be later today. :neutral_face:

Quite fast. I made a series of a exposure adjustments, up and down, then the familiar error box popped up. I’ll try it again, but it might a while till I get time…
One point I probably should have mentioned is that I had the new build using my 4.0 database (after backing it up). I might try it again on a fresh database…

I’m also on my “old” database. Even switched several times between 4.0 and 4.1. No problems so far.

Are you running R darktable too? Or another iteration of darktable?

No, not R-dt, but I do have one other build, one of Todd’s builds with the new HR mode, currently installed. But not running at the time (probably obvious!)
EDIT I have dt4.0 (the workhorse) installed too. Forgot to count it.
@wpferguson, here’s the file where it crashed:
(file is licenced Creative Commons, By-Attribution, Share-Alike.) (I hope this is the right licence!)
DSC_6762.NEF (25.0 MB)
DSC_6762.NEF.xmp (892 Bytes)
Not sure whether the xmp is reflective of the edit - I imagine it crashed without saving the adjustments. Not sure though atm.

Played around for some minutes with this, no problem so far. Your XMP is pretty much empty.

Humph… maybe it’s specific to my system? TBH I’m not too bothered… would it be useful to anyone if I keep poking at it? If not I might just let it go at this point. But is there anything anyone wants me to try, or any info you need?

Have you tried the photo with a fresh config/db? You could temporarily rename your AppData\Local\darktable folder to see if the error is coming from there.

I would remove the other iteration of darktable and then try bill version again.

No… I didn’t. If I have time I’ll try that tomorrow - and @g-man s suggestion too. Thanks!

Just to spell out the consequence of this: users on Windows 8.1 or earlier will need to install UCRT separately.

@apostel338 , I tried using Bill’s version with a clean db (I used --configidir - worked well) but it doesn’t make any difference.
@g-man , I uninstalled both my other version of 4.1 and 4.0 too, so Bill’s latest 4.1 was the only dt on the system. Still no difference.
I’ve isolated the problem slightly more, to reproduce: Close dt. Start dt, then open image in darkroom. Make two consecutive adjustments to exposure. It should crash just after the second adjustment.
BUT! If I make one exposure adjustment, then do something else, like a color balance rgb saturation adjustment, then go back to exposure, it works perfectly. What’s more, if I then open a new image, exposure works fine from the start, and the problem doesn’t reoccur. But if I restart dt the problem returns.
The problem is there with RAWs from both a nikon and a sony.
Hope this helps!
I’m going to reinstall 4.0 now… back to work :wink:

Ok. I think this needs an issue in GitHub.

I had some problems with master today on windows (my build). I need to bisect to find the commit that caused it.