Been doing so since using it after update of Arch (currently 6.2.7-arch1-1) on Saturday evening, so probably Sunday or Monday.
Lots of coincidences, so not convinced it is a darktable problem, simply trying here to narrow it down. I update Arch usually every Sunday but did so on Saturday this week. So whatever happened could have happened any time during the past ten days or so. I note there was a DT updated release 10 days ago.
But there have also been problems seen reported online regarding Gnome Desktop Manager, my GUI handler of choice. Also, glitches can and do happen with a release update. So it could be Arch or the Linux kernel itself.
Waded through the journal entries for the system, couldn’t see anything obvious there but then I’m no expert. Hundreds of entries for a GDM glitch but nothing to say what it is affecting other than being a nuisance.
Ran darktable -d all which gave out all the entries for /usr/src/debug/darktable/darktable-4.2.1 without revealing any clues other than this, the final line, which may or may not be useful:
66.065746 [sql] /usr/src/debug/darktable/darktable-4.2.1/src/common/database.c:3838, function dt_database_optimize(): exec "PRAGMA optimize"
Any useful pointers gratefully received. I’ve loaded thousands of images onto this, my newly built (end Nov - early Dec) midi tower PC and was happily pushing them into the library when this fault occurred.
Thanks @paperdigits. I wanted to add images to the darktable library, not to kill darktable so this still leaves me bemused. Nothing like it has never occurred in the past with DT.
I have preferences > storage > database set to once a week so it should be happening, umm, perhaps, weekly? and not timed to only when I want to import another batch of images?
The system only hangs on that instance, click on the import facility. Clicking on the darktable icon at the top of the screen, then quit, brings the screen back to life so I can do anything else in DT. I simply can’t use the import facility.
I have subsequently discovered that I can add them one at a time by using the system’s file manager to open them in DT and they stay there, within the DT library, all in the same date-oriented file. All the darkroom modules work perfectly well with images imported that way. But trying to open multiple images simultaneously that way crashes DT.
My suspicion remains that the problem is either with Gnome and its Display Manager or, less likely, with the compilation of DT v.4.2.1 for inclusion in the Arch repos. Or even with GDM’s compilation into Arch.
Having said all that, I can’t find any evidence of recent similar problems being reported in any of those either.
Having had a test run on a couple of other machines, I am none the wiser.
The midi tower this machine replaced runs on Arch with Gnome as the GUI. DT would not start until I clicked on the choice given to update the database rather than to exit. I ran pacman to update Arch before attempting to start anything.
My laptop also runs Arch but has Xfce as its GUI. It gets updated at the same time as this PC, i.e. every Sunday. The “import” facility runs flawlessly.
I use Rapid Picture Downloader to take images from the camera, but I can’t see that it would have any bearing on this problem. Most of the images I am trying to “import” - enter into the DT library without moving them - have been copied from the old PC including their sidecar files.
My suspicion is turning to a corrupted DT database on this PC. Does anybody here have any pointers as to where I can look to find out how to fix it please?
Thanks @g-man. On listing ~/.config/darktable the list looked a bit complicated so I moved that directory to ~/.config/darktable.orig then opened DT in the GUI interface. It’s all working again.
I need to re-import everything, not being sure which of the files I could safely move back into the newly system-created ~/.config/darktable/ - would that be everything showing as created before 19th March or is there some way of identifying which file caused the problem in the first place?