digiKam freezes when scanning a new collection

[Gilles Caulier]

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>:

> 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
>>>
>>> Gilles Caulier
>>>
>>>
>>
> --
> Website: http://www.stella-maris.org.uk
> or:      http://www.broadstairs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20170123/23ec8ac6/attachment.html>