https://bugs.kde.org/show_bug.cgi?id=446201
guenael <g...@zai.re> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |g...@zai.re
--- Comment #15 from guenael <g...@zai.re> ---
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
--
You are receiving this mail because:
You are watching all bug changes.
