Bug 317606 - SCAN : When adding 1444 pics to an registered directory, it takes time for ever
Summary: SCAN : When adding 1444 pics to an registered directory, it takes time for ever
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Scan (show other bugs)
Version: 3.0.0
Platform: Ubuntu Linux
: NOR grave
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-03-30 13:42 UTC by Axel Krebs
Modified: 2021-08-25 14:38 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.4.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Axel Krebs 2013-03-30 13:42:40 UTC
I added yesterday 1444 pics (1/2 NIKON raw NEF-format, 1/2 NIKON jpgs)
Since then digiKam is busy to "search for new entries" (GERMAN: "Neue Einträge suchen")

This is not an import progress rather than interference issue between KDE and digiKam (my guess).

What happens? 
How to avoid these extrem "search-new-entries"-times?



Reproducible: Always

Steps to Reproduce:
1. adding pics to a directory, which is already selected in digiKam settings s a directory. 
2. when observing Task manager in Kubuntu, I see, that needed memory is huge- now about 2 GB, whereas needed memory was less than 900 MB, as long as all pics were located within one top-directøry. 
3.
Actual Results:  
Unsatisfying slow work performance. 


Expected Results:  
"Incorporating new pics" should be a background process not harming productive work time.

Since yesterday, I have to wait for the pics I took yesterday. 

This is definitely not "using opensource and working like a professional!!

If I can provide, please, let me know!
Comment 1 Axel Krebs 2013-04-01 20:56:37 UTC
In the meanwhile, I updated on digiKam 3.1
When importing (incorpüorating) 2646 pics, it just took about 2" 50'

Besides, digiKam uses only CPU between 15 and 22 %, whereas in the
previous version pic importing was extremely slowly. It rather looked
like as a "hanging process".

>> You may ant to close this bug <<


Axel

Am 30.03.2013 13:42, schrieb Axel Krebs:
> https://bugs.kde.org/show_bug.cgi?id=317606
> 
>             Bug ID: 317606
>            Summary: When adding 1444 pics to an registered directory, it
>                     takes time for ever
>     Classification: Unclassified
>            Product: digikam
>            Version: 3.0.0
>           Platform: Ubuntu Packages
>                 OS: Linux
>             Status: UNCONFIRMED
>           Severity: grave
>           Priority: NOR
>          Component: Database
>           Assignee: digikam-devel@kde.org
>           Reporter: axel.krebs@t-online.de
> 
> I added yesterday 1444 pics (1/2 NIKON raw NEF-format, 1/2 NIKON jpgs)
> Since then digiKam is busy to "search for new entries" (GERMAN: "Neue Einträge
> suchen")
> 
> This is not an import progress rather than interference issue between KDE and
> digiKam (my guess).
> 
> What happens? 
> How to avoid these extrem "search-new-entries"-times?
> 
> 
> 
> Reproducible: Always
> 
> Steps to Reproduce:
> 1. adding pics to a directory, which is already selected in digiKam settings s
> a directory. 
> 2. when observing Task manager in Kubuntu, I see, that needed memory is huge-
> now about 2 GB, whereas needed memory was less than 900 MB, as long as all pics
> were located within one top-directøry. 
> 3.
> Actual Results:  
> Unsatisfying slow work performance. 
> 
> 
> Expected Results:  
> "Incorporating new pics" should be a background process not harming productive
> work time.
> 
> Since yesterday, I have to wait for the pics I took yesterday. 
> 
> This is definitely not "using opensource and working like a professional!!
> 
> If I can provide, please, let me know!
>
Comment 2 caulier.gilles 2014-08-07 07:40:07 UTC
Axel,

We need a fresh feedback using last digiKam 4.2.0

Gilles Caulier
Comment 3 caulier.gilles 2014-08-07 12:17:10 UTC

*** This bug has been marked as a duplicate of bug 281959 ***
Comment 4 caulier.gilles 2021-08-25 14:38:25 UTC
Fixed with #281959