Bug 446201

Hmm, I've never seen a problem like this before. It might help us if you post a debug log from the terminal when the problem occurs. The creation of the log is described here: 

https://www.digikam.org/contribute/

Maik

Created attachment 144038 [details]
Screenshots of the crash 1

As you can see I use the appimage that I placed on my desktop. On the right you can see the frozen digikam window.

Created attachment 144039 [details]
Another screenshot

This time the program crashed on a different picture with a differenz histogram waiting for imformation. I am pretty sure the the histogram does not cause the problem.

Created attachment 144040 [details]
Screenshot after several seconds

After a long time the log output changes. But the program is still frozen.

Created attachment 144042 [details]
report file

I used command 
  ./digiKam-7.3.0-x86-64.appimage debug > test.txt
to write some information into a text file.

You have to set the debug variable, otherwise no digiKam debug messages will be displayed: 

export QT_LOGGING_RULES="digikam*=true"

If you are using the Debug AppImage you have to start it with the "debug" option, then with "bt" we can also see the backtrace where digiKam is possibly hanging. 

Maik

Wait a minute, in digiKam-7.3.0 we have a possible "freeze" in the TagsCache which has already been fixed. Please make a backup of the database and test digiKam-7.4.0 from here: 

https://files.kde.org/digikam/

Maik

Is there any feedback? Has the pre-release of digiKam-7.4.0 been tested?

Maik

I am on a business trip at the miment and cannot do any tests. But I was able to create the freeze in version 7.4 too. But it took more time. In 7.3 the problem occured after 20-35 pictures (no fix number) but in 7.4 I had to browse thru approx 50+ pictures. But I am not sure if this significant or just a coincidence. 
So far I also could not see a relation to the file size. I am working here with pictures (in different folders) with a file size of approx 1 MB, 6 MB or 13 MB.

Which kind of database time did you use exactly ?

Gilles Caulier

Hi here,

when you said digiKam freeze, it come alive after a few seconds or not ?

I'm not sure if it's a crash. We need a gdb backtrace taken with the "debug" version of appimage bundle 7.6.0 pre-release available here :

https://files.kde.org/digikam/

Also, don't forget to set the QT debug variable before to start digiKam from a console. This will enable the log traces :

export QT_LOGGING_RULES="digikam*=true"

To run the appimage bundle in gdb, use "debug" argument on command line when you start digiKam. When it crash, use "bt" gdb command to get the backtrace.For ex :

./digiKam-7.6.0-20220121T100515-x86-64-debug.appimage debug
...
___crash_here___
>bt
___backtrace is here___
...

Gilles Caulier

@d.boller@web.de

digiKam 8.0.0 is out. Problem still reproducible ?

Best regards
Gilles Caulier

Maik,

Just a generic Q about Qt 5 used in AppImage. We currently build the bundle with Qt 5.15.7. Qt 5.15.9 is available. Do you know if special fixes can improve the digiKam run-time if i update Qt in the bundle now, or i can wait next release ?

Best

Gilles

@d.boller@web.de,

What's about this file using current 8.2.0 AppImage Linux bundle ? It's
reproducible ?

https://files.kde.org/digikam/

Thanks in advance

Gilles Caulier

Hi,

Sorry in advance for the long post, I'm just trying to give as much details as possible.

My father is having this issue while using 8.2 on Windows 10 (latest version). It's very frequent, several times per hour, sometimes more. It has been happening for a few weeks, since he started using Digikam heavily again (rather than casual uses, once or twice per week. 

Symptoms:
- 3 to 20, sometimes 30 seconds freezes
- after some time, Windows says that the program is "not responding". We never closed it the hard way, waiting patiently Digikam to become responsive again 
- the task manager indicates around 20% of the processor being used. My guess is 100% of 1 of the 8 cores + the system - but take that for what it is: an amateur guess. On normal usage, this figure is attained during maintenance like thumbnails recreating, rarely otherwise (as far as we can tell...)
- no disk usage at all (unexpected by me), no network usage (as expected)
=> digikam is "thinking hard" :-/

Different operations can lead to 3-to-20-second freezes: mostly, moving images to another album (by dragging) or moving an album into another album. Anything related to reorganizing albums and images.

My father and I have spent quite some time trying to pinpoint specific circumstances, but nothing emerges (except what I described).

So I have extensively duckduckducked the issue, read forums,  and tried many things: 
- deep maintenance
- moving all Digikam directories to a directory directly on C:\, put digikam.exe, exiftool.exe out of scan by security services (Defender etc) and other stuff like OneDrive etc, checked access rights. 
- we moved all archives to an external hard drive, keeping all digikam collections are on the SSD. This was to reduce the SQLite database size (to around 50 Mo, 60 Mo before). No change, after full maintenance of course.
- I manually deleted all the databases from the Digikam db directory except the main one, so that they would be re-created from scratch through maintenance. It hugely decreased the size of the thumbnails database from 7.6 to 3.1 Go, but very little on other databases. We thought we nailed it, but nope: no change. 
=> NB: this was done before the archives were moved to an external drive, so the decrease is not linked to that. I find this decrease a bit too huge for a db that I had "deeply" cleant before (using the proper options in the maintenance panel). But the performance was not better after than before, as surprising to me as it is.
- I migrated the SQLite to another directory, using the "migrate" function: the main database size was reduced to around 40 Mo (for around 56 000 pictures, but I'd to check those figures again if you need them, that's from memory)
- The disk is a quite recent 2To SSD with good performances with plenty of room available. The computer is rather old, with a i7 4770, eg 4th generation processor and 16 GB of RAM. All Windows "checks" are green. Windows 10, Store programs, drivers are all up to date. 
- the computer has 2 video-cards: one on-chip, the other is a NVIDIA (I can check the reference, but this is a 6 or 7 year old gamer laptop to give you an idea). I deactivated the NVIDIA card completely and rebooted: no change. Digikam processes often uses that card according to the task manager.
- I considered moving to MySQL but the help pages and forums were not in favor of that option, considering the number of images. I have used MySQL extensively so I can quickly set up a MySQL server on my father computer and migrate the db - if you think it useful.
- ... I certainly have forgotten some stuff I tried but please point me what I could have tried, I'll give you a feedback within 24h (we live in France), often more quickly.

So I install DebugView and checked the relevant option in digikam settings. It works, we can record logs as expected. The freezes always finish with a "one job done" and nothing more. 
=> My guess is the path to the solution, but could you tell me exactly what data are needed? 
- Obviously, we'll write down the action leading the the freeze and the precise time HH:MM:SS. The seconds figure will be an approximation for sure, but we'll do our best.
- The corresponding logs using DebugView 
- how many freezes to record? 5? 10? more ? It's easy to make them appear, even if they seem anything but regular.

My father has tens of thousands of pictures to sort, comment, organize. And we like Digikam. So we are committed and available to spend the time necessary to give the data needed to spot that bug. On Windows. I use KDE Neon but my digikam collection is much thinner and I have no freeze. I don't have a SSD big enough to copy my father's db on my computer, so I can't tell if this is a Windows 10 bug or a general one.

Best regards,

Guénaël

Hi,

Under windows, digiKam 8.2.0 has a major dysfunction with the database which we have quickly fixed in 8.3.0.

A pre-release 8.3.0 installer is available and safe to use in place of 8.2.0 as well. File is here:

https://files.kde.org/digikam/

Thanks to test and report is the 8.3.0 solve your problem.

Best regards

Gilles Caulier

Hi,

My father installed the 8.3 pre-release last week as directed and it solved the issue immediately. We wanted to be sure (eg trying in real conditions) before reporting it, the official release came, and we tested on that one also: everything is fine on both versions, no freeze anymore. 

Thanks!