works as designed: see comments in Compress history stack erase snapshots · Issue #12766 · darktable-org/darktable · GitHub
I learned from earlier versions of Darktable, that you’d better restart darktable anytime you change a style, preset, or keyboard shortcut, as they only get saved at shutdown, but will get lost if darktable crashes. And from painful experience, it will crash.
But so far, with this version, it has been rock-solid.
Well as long as you walk through your xmp and leave it intact and don’t compress you will be fine so I guess it depends on that. If you settle on an edit and want to compress I guess you don’t need the snapshots anymore anyway unless you want to keep it for the next image and then you would have to leave the stack alone.
I tested the latest nightly build today …7f06.zip. Exported the same pictures from lighttable as before and did not see any “freezing” anymore. However, when watching my Task manager I also did not see any GPU activity. When using darkroom, i get export, however, the software freezes; After double clicking in the selector pane the same or any other picture I see “working…” Closing down, does not shut down completely; I need to kill darktable in the taskmanager to restart. In darkroom, however, I also see GPU activity.
darktable-log-f706-built.txt (10.4 KB)
IT also doe not seem to be linked to a specific file (photo). If I use files from other folks downloaded from the “processing” section; tried nikon (NEF) and canon (cr2) files I seee xactly the same behavior.
Thanks for the log file.
Can you do the same steps you did but this time turn off the OpenCL tunning (set to nothing)?
Turning off OpenCL, does not produce any freeze. I did not stop times, but it felt like it’s actually a little bit faster than with OpenCl enabled.
darktable-log-without-OpenCL.txt (4.5 KB)
But what about OpenCL on, but tunning set to nothing?
Ive been trying to recreate this issue on Windows and I cant. I’ve set my resources to mini to force tiling, adjusted to memory/transfer tunning on, and adjusted the openCL mandaroty timeout to 10; but I still cant reproduce. I’ve been using my compiled version, but current URCT.
So far Ive seen 3 reports and they seem to have in common that 1) D&S fails during a tiling and 2) Transfer tuning in ON. After the failure then the GPU is no longer use with a process running in the background.
If there is an issue, we will discover it with more users using 4.2 in windows.
If you tell me which parameter to change. I’ll do, sure, however, when selecting OpenCl I did have set tune OpenCl performance for memory and transfer. Should I restrict that?
IF you give me some guidance what other options to try (command line or otherwise), I am happy to do. we are having a rainy day here, not much to do today
I have this same issue , but not with this build . Mine is a couple of weeks old.
I thought it was opencl related , but i didn’t test yet without. If people here are saying they also have the problem without opencl , it must be something else :(.
(I recently tried setting the micronap lower , and selecting the gpu to be used for both preview and export… So when it does an export but then stops at ‘working’ for the next image to load i WAS suspecting one of those parameters).
My opencl tuning is off (AFAIK). I just set it to ‘very fast gpu’ (even though it really isn’t , but it is much faster than my cpu).
Use these settings and export like you did before. Lets see if you can get the same issue and post the log like you did before.
These settings seem to do it. log file is attached.
darktable-log-without-OpenCL.txt (4.5 KB). The other change to what you had recommended is darktable resources. I have a computer with 48GB RAM, so I thought I can use “large”, sometimes also using “unrestricted”; watching the task manager I never got beyond 16GB memory usage, though.
Thanks for all your patience and help.
Does this mean you get the freeze with these settings?
The difference between default, large and unrestricted is how much memory darktable is allowed to use. I think default is ~50%, large is ~70% and unrestricted is it can try to use it all. I would not use unrestricted unless you plan to only run darktable (keep chrome and other app off).
Let me try one more time to activate some of the settings and report back, so that we potentially can track what causes this.
When using “unrestricted” resources: this just happened:
[dt_pthread_create] info: bumping pthread’s stacksize from 0 to 2097152
warning: failed to restrict file handles (87)
handle #0: 0000000000000060 (type 2, handle info (1) 0
handle #1: 00000000000015ac (type 3, handle info (1) 0
handle #2: 0000000000000314 (type 1, handle info (1) 1
This is a bug; please report it at
To suppress this warning, please set the environment variable
SUPPRESS_HANDLE_INHERITANCE_WARNING=1
warning: failed to restrict file handles (87)
handle #0: 0000000000000060 (type 2, handle info (1) 0
handle #1: 00000000000015ac (type 3, handle info (1) 0
handle #2: 0000000000000314 (type 1, handle info (1) 1
This is a bug; please report it at
To suppress this warning, please set the environment variable
SUPPRESS_HANDLE_INHERITANCE_WARNING=1
[export_job] exported to `e:\Users\bvogl\Pictures\darktable-edit\12-11-2022_K118407_07.jpg’
software is frozen again.
Same happens if I enable tune OpenCl “memorysize and transfer”
setting tune OpenCL to “Memory transfer” is working
Setting tune OpenCl to “Memorysize” again freezes the software
What resource settings do you have with all these setting test that you did?
I run Win 11 Nvidia 3060ti. I leave opencl tuning to none as that is the fastest. I use large and very fast GPU. I build every few days. I haven’t seen this issue. No freezing. Tried unrestricted and it was actually the slowest when I tested. I just upgraded to 527.56 driver also to test and it’s fine… The only issue I have noticed and really it was only when I went looking was the drawn mask issue mentioned by @kofa and others
this works for me. Also the setting you originally suggested.
My NVidia driver version is: 31.0.15.2698
