Bug 339916

Summary: SCAN : on startup, scanning collection stops advancing (i.e. at 88%) and digikam shows 100% cpu for one core.
Product: [Applications] digikam Reporter: Jasper <jasper.mackenzie>
Component: Database-ScanAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: major CC: caulier.gilles
Priority: NOR    
Version: 4.5.0   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In: 7.3.0
Sentry Crash Report:

Description Jasper 2014-10-13 00:44:35 UTC
On launching digikam the progress indicator for scanning collection quickly progresses to a point (88% for me) then halts.
At this point one core can be seen to go to 100% and stay there (and digikam similarily shows 100%) as seen from 'nmon'. The core that is at 100% sometimes changes a few times, but the process never ends, even given a day.
The scan can can be cancelled and normal tagging can work. Refresh on an album usually works.
But when quitting digikam there is still a process that has 100% CPU and must be killed with s9 or s15.
 
I assume that this is a 'ScanCollection' process as 'pstree -pluc' shows a daughter process "Digikam::ScanCo".
I have tried removing the last file on the list of files being scanned (repeatedly), often they are large xcf or avi, but no change.

Sometimes if the scan is cancelled digikam will crash some minutes later. This is too random for me to draw strong causal inference, but it is likely related.

Reproducible: Always

Steps to Reproduce:
1. Start digikam ('dbus-launch digikam' OR just 'digikam' from terminal)

Actual Results:  
Digikam Launches, 
Scan collection runs through to a point
Scan collection stops advancing and a CPU core goes to 100%

Expected Results:  
Digikam Launches,
Scan collection runs and ends promptly

System is Ubuntu 14.10, amd64 (Xeon)
Digikam from git (dk), all dependencies satisfied except libgpod.
Digikam accessed exclusivly via ssh with X forwarding.
Comment 1 caulier.gilles 2014-10-13 08:12:47 UTC

*** This bug has been marked as a duplicate of bug 281959 ***
Comment 2 caulier.gilles 2021-04-04 07:47:36 UTC
Fixed with #281959