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.

[GregDunn]

Sorry to necro this thread, but I left dt running with debug enabled for over a week and several photo albums, hoping to see this issue again. Naturally, it worked perfectly the whole time. I have a number of photo shoots coming up so I’ll keep trying to reproduce it.

I do want to say, though, that with shortcuts defined to assist my editing workflow, dt just flies through large albums with great results. At this point, I’m getting ready to dump all my other (paid) photo editors.

[Thad_E_Ginathom]

@GregDunn

with shortcuts defined to assist my editing workflow, dt just flies through large albums with great results.

I don’t bother to use GIMP+jpeg any longer for quick tweaks. I can be almost as fast in darktable+raw.

It almost feels like I’m doing something wrong when I edit an image really quickly — because isn’t raw processing supposed to be slow? lol.

[rvietor]

@Thad_E_Ginathom

It almost feels like I’m doing something wrong when I edit an image really quickly — because isn’t raw processing supposed to be slow? lol.

The camera is still faster than you can ever be (3-10 images/s including saving?)

[GregDunn]

I stopped using JPEG when I kept getting blown highlights in my action/street photos. The DR wasn’t large enough to compensate by underexposing, and many other issues finally pushed me to RAW. Even though I have a much better camera these days, the flexibility of RAW capture is still very much worth it. I can take the occasional shot where my strobe misfires and correct it surprisingly well.

I gave up on Lightroom years ago because of Adobe’s predatory pricing, and have been using ON1. Unfortunately, their software just sprouts bugs with every new release, runs slower every minute the app is open, and they have discontinued their free forums so that you have to depend on their mediocre tech support team. I will not be upgrading to the next release.

Long live Darktable!