Bug 324287

Summary: SCAN : frequent image scans slow
Product: digikam Reporter: Rainer Lay <rainer.lay>
Component: Database-ScanAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 3.2.0   
Target Milestone: ---   
Platform: Ubuntu Packages   
OS: Linux   
Latest Commit: Version Fixed In: 4.4.0
Attachments: log from mysqld-slow.log with queries longer one sec, while importing images

Description Rainer Lay 2013-08-30 19:15:05 UTC
on startup, the following sql is executed serveral times, which costs ~5 sec each.
--
SELECT creationDate FROM ImageInformation  INNER JOIN Images ON Images.id=ImageInformation.imageid  WHERE Images.status=1;
--
also, when I import pictures, this sql is executed for every imported picture (5sec each!).

I just wonder, why the creation datefor all pictures (80.000 in thi collection) is neccesary that much. Since this costs my lots of time, please have a look at this.

For your information: the sql itselve is very fast, but fetching the 80.000 creationDates costs the 5 sec,even when I fetch them on the server (synology DS213+).
Comment 1 Rainer Lay 2013-09-01 21:20:21 UTC
Created attachment 82096 [details]
log from mysqld-slow.log with queries longer one sec, while importing images
Comment 2 Marcel Wiesweg 2013-09-03 17:58:53 UTC
So you have the MySQL on a NAS server and the network is the bottleneck?

The query is done to update the timeline view, and is usually relatively fast. There is a timer defined in AlbumManager that limits this scan to be done not more frequently than every 5 sec. Unfortunately, as it takes 5 secs for you, this is ineffective.
Comment 3 Marcel Wiesweg 2013-09-03 20:09:40 UTC
Git commit 145b25c573164111b75c1a8586b5aea50656572c by Marcel Wiesweg.
Committed on 03/09/2013 at 20:08.
Pushed by mwiesweg into branch 'master'.

The DAlbums scan can be costly for some setup as it sends large amounts of data over the SQL connection.
- reduce the timer limit to one minute
- do not kill the running job if the timer fired again while the job was running.

M  +13   -2    digikam/album/albummanager.cpp
M  +1    -0    digikam/album/albummanager.h

http://commits.kde.org/digikam/145b25c573164111b75c1a8586b5aea50656572c
Comment 4 caulier.gilles 2014-08-08 10:40:10 UTC
We need a fresh feedback using a recent digiKam release as last 4.2.0.

Gilles Caulier
Comment 5 Rainer Lay 2014-09-16 03:58:01 UTC
With digikam 4.2., windows, the query is no longer reported as slow (>1s) query. So I suggest to close this bug.

Rainer