"scan for new items" always scans the entire collection

[Gilles Caulier]

Hi,

Look at the comments in is report :

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

I'm not sure if it's close to the problems listed here.

Best regards

Gilles Caulier



Le jeu. 9 juil. 2026 à 12:41, Thomas <sdktda at gmail.com> a écrit :

>
> On 2026-07-09 07.33, VALÍK Robert wrote:
> > Hey there!
> >
> > After upgrading Digikam to version 9.1, I have also noticed this weird
> > behavior.
> >
>
>
> Oh, I thought it was only me. I experience this too. Hopefully, this can
> be fixed.
>
> A complete scan on my collection takes several days. So this has
> effectively been preventing me from using DK for some time.
>
> In fact I think a lot could be done to improve the whole experience
> regarding scanning collection. For one, the progress reporting could be
> MUCH better. Currently, it has an almost useless progress bar. It gives
> a percentage but nothing in terms of how many pictures/folders it has
> scanned and how many remaining. (I am aware that exact number of
> remaining objects might be impossible to give, but then estimate it like
> other tools does, e.g. rsync will just update the number of remaining
> items as it learns about them...). There is also no estimate of how long
> it will take or the processing rate (how many items per minute, etc.)
> All these infos would be useful. Especially if trying to make it faster
> and see what works.
>
> I also think the scanning could be sped up quite a bit by using multiple
> threads. I have my collection on a NAS. I believe a lot of the time
> spent on scanning/indexing is really spent on network latency: waiting
> for the samba server to list files, open file handle, etc.
>
> When I look at resources on the DK client machine, it is mostly idle on
> both CPU, network and disk I/O. Same with the NAS server, it is mostly
> idle on those resources as well. So I think a lot of time is pent
> waiting for network packages. If I could allow 2, 4, 8, .., parallel
> threads, I think we could see this wait time reduced significantly and
> CPU/net/disk utilization increased.
>
>
> BR
>
> Thomas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20260709/a3267203/attachment.htm>