digiKam freezes when scanning a new collection

[Gilles Caulier]

I updated the patch from bug :

https://bugs.kde.org/show_bug.cgi?id=123097

It's ready for testing with current implementation from git/master. This
add new settings in database config panel :

https://www.flickr.com/photos/digikam/32441766536/in/dateposted-public/

Gilles Caulier

2017-01-23 12:41 GMT+01:00 Gilles Caulier <caulier.gilles at gmail.com>:

> 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/f4f6753b/attachment.html>