Module controls sometimes unresponsive

[GregDunn]

I’m running darktable 5.0.1 on MacOS 15.4.1 and occasionally I will be in the middle of an edit session when the module controls stop having any effect. I.e., you can move the controls but they do nothing. It seems to happen in all the modules at once. It is still possible to change views, open and close modules, etc. and the program will quit when asked; however editing is not possible. This happens maybe once or twice a week. Re-launching the program seems to fix the issue.

Where is the error log on Mac? I can submit a copy next time this happens.

[Thad_E_Ginathom]

Similar stuff, and even an occasional crash, happens to me. The trouble is that it doesn’t happen often enough for me to think of enabling the debug option. I suppose we could do it every time. Just configure our menu entries, or however we start it, to use the appropriate -d option.

[GregDunn]

OK, so at least one other person has this - good to know. I have a lot of photo shoots coming up, so maybe I should just enable debug until it happens again. Meanwhile, if this is the only issue I find with dt, I can’t be too mad.

[Thad_E_Ginathom]

I most often encounter a freeze, which, after a few seconds becomes a crash. I think it might most often happen when I am exporting.

So our question to the experts here, is which -d option(s) should we use?

-d {all,cache,camctl,camsupport,control,dev,fswatch,imageio,input,
ioporder,lighttable,lua,masks,memory,nan,opencl,params,perf,
pwstorage,print,signal,sql,undo}

… From “man darktable” on LInux

Do we have to add (Linux/Mac) 2>path-to-logfile to the command?

This from the documentation

-d {all,act_on,cache,camctl,camsupport,common,control,dev,expose,fswatch,imageio,input,ioporder,lighttable,lua,masks,memory,nan,opencl,params,perf,pipe,print,pwstorage,signal,sql,tiling,undo,verbose}
Enable debug output to the terminal. There are several subsystems of darktable and each of them can be debugged separately. You can use this option multiple times if you want to debug more than one subsystem (e.g. darktable -d opencl -d camctl) or debug all of them at once (with -d all). The -d common switch is provided to give information about most relevant subsystems while debugging darktable or if you want to provide a log for reporting a darktable issue. Some debug options (like -d opencl) can also provide more verbose output, which can be invoked with the additional option -d verbose. The verbose option must be explicitly provided, even when using -d all.

But does “To the terminal” mean STDOUT, STDERR? Sorry: I am a 20-years-rusty techie. Which possibly makes me worse than someone who never knew any of that stuff in the first place!

[kofa (István Kovács)]

all really logs a lot.
I’d start with common:

The -d common switch is provided to give information about most relevant subsystems while debugging darktable or if you want to provide a log for reporting a darktable issue.