digiKam freezes when scanning a new collection

[Stuart T Rogers]

Running digikam 5.4 from a konsole I see

digikam.dbengine: Database is locked. Waited 0
digikam.dbengine: Database is locked. Waited 250
digikam.dbengine: Database is locked. Waited 500
digikam.dbengine: Database is locked. Waited 750
digikam.dbengine: Database is locked. Waited 1000
digikam.dbengine: Database is locked. Waited 1250
digikam.dbengine: Database is locked. Waited 1500
digikam.dbengine: Database is locked. Waited 1750
digikam.dbengine: Database is locked. Waited 2000
digikam.dbengine: Database is locked. Waited 2250
digikam.dbengine: Database is locked. Waited 2500
digikam.dbengine: Database is locked. Waited 2750
digikam.dbengine: Database is locked. Waited 3000
digikam.dbengine: Database is locked. Waited 3250
digikam.dbengine: Database is locked. Waited 3500
digikam.dbengine: Database is locked. Waited 3750
digikam.dbengine: Database is locked. Waited 4000
digikam.dbengine: Database is locked. Waited 4250
digikam.dbengine: Database is locked. Waited 4500
digikam.dbengine: Database is locked. Waited 4750

on the first run after a boot up of Linux, subsequent starts do not see 
this but I dont often run digikam more than once on any given day. I 
should add that my database is the same one I used to use on digikam V4, 
I have never deliberately recreated it.

Because I dont use digikam all the time I guess this database locked is 
happening whenever I start digikam for the first time after any reboot 
and it is this which appears to make digikam sluggish for me.

Stuart

On 23/01/17 11:41, Gilles Caulier wrote:
> The scan process run already in a separated thread.
>
> The registration of data to the database is also delegate to a thread.
>
> Database access can introduce time latency with concurrent request. This
> is true with remote database and network access, as i can see here with
> my computer.
>
> I tested here the scan of a whole collection from scratch with many type
> of images and videos. More than 30.000 items located in a SSD. Computer
> is an i7 3Ghz with 32Gb of RAM. There is no visible time latency. I run
> digiKam from a console and i can see all files scanned step by step very
> quickly. While this process is done, the progress manager report the
> advance of scanning as expected. This is done with a sqlite database,
> also located on a SSD.
>
> To identify where is the problem, i recommend to always run digiKam from
> a console. On MacOS it's simple, as under Linux. For Windows, the use of
> and extra application to catch console trace as debugview is mandatory.
> It's explained on web site contrib page :
>
> https://www.digikam.org/contrib
>
> Gilles Caulier
>
> 2017-01-23 11:53 GMT+01:00 Stuart T Rogers <stuart at stella-maris.org.uk
> <mailto:stuart at stella-maris.org.uk>>:
>
>     Although I do not see long hangs/freezes when digikam scans new
>     collections or for new images I do see that in general the process
>     slows down digikam so that the gui either is very very slow or even
>     non-responsive while the process finishes. In my case the
>     directories being scanned contain only image files from my cameras.
>     While the scanning of new collections is not used a huge amount the
>     process looking for new images in existing collections does slow
>     down the initial use of digikam on every start of the program. I am
>     running using an AMD quad core processor with 8meg memory running
>     openSUSE Tumbleweed.
>
>     Stuart
>
>
>     On 23/01/17 10:01, Simon Frei wrote:
>
>         What makes you think that? This is also an issue when importing
>         a folder
>         that only contains image files.
>         Pure speculation on my side: To me it seems that there is something
>         wrong with priority handling (however that is done). Finding new
>         files,
>         which does happen in background, still influences other digikam
>         functionalities to the point where the UI freezes. This looks
>         like the
>         background process takes all resources and any normal operations
>         have to
>         wait, while it should be the other way around: Normal operations
>         (e.g.
>         user interaction with GUI) should always get the resources it
>         needs and
>         background process whatever resources are left.
>
>         On 23/01/17 10:14, Gilles Caulier wrote:
>
>             I think the problem is the registration in DB of non image
>             files and
>             all hidden files.
>
>             There is patch in bugzilla to introduce a settings to filter
>             unwanted
>             dirs/files while scanning. It's not yet finalized and need to be
>             review. Look here :
>
>             https://bugs.kde.org/show_bug.cgi?id=123097
>             <https://bugs.kde.org/show_bug.cgi?id=123097>
>
>             Gilles Caulier
>
>
>
>     --
>     Website: http://www.stella-maris.org.uk
>     or:      http://www.broadstairs.org
>
>

-- 
Website: http://www.stella-maris.org.uk
or:      http://www.broadstairs.org