Re: "scan for new items" always scans the entire collection

--000000000000faeacf06562bd52f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Look at the comments in is report :

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

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

Best regards

Gilles Caulier



Le jeu. 9 juil. 2026 =C3=A0 12:41, Thomas <[email protected]> a =C3=A9crit :

>
> On 2026-07-09 07.33, VAL=C3=8DK 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
>
>

--000000000000faeacf06562bd52f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div><br></div><div>Look at the comments in =
is report :</div><div><br></div><div><a href=3D"https://bugs.kde.org/show_b=
ug.cgi?id=3D522695">https://bugs.kde.org/show_bug.cgi?id=3D522695</a></div>=
<div><br></div><div>I&#39;m not sure if it&#39;s close to the problems list=
ed here.</div><div><br></div><div>Best regards</div><div><br></div><div>Gil=
les Caulier</div><div><br></div><div><br></div></div><br><div class=3D"gmai=
l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=
=A0jeu. 9 juil. 2026 =C3=A0=C2=A012:41, Thomas &lt;<a href=3D"mailto:sdktda=
@gmail.com">[email protected]</a>&gt; a =C3=A9crit=C2=A0:<br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex"><br>
On 2026-07-09 07.33, VAL=C3=8DK Robert wrote:<br>
&gt; Hey there!<br>
&gt;<br>
&gt; After upgrading Digikam to version 9.1, I have also noticed this weird=
 <br>
&gt; behavior.<br>
&gt;<br>
<br>
<br>
Oh, I thought it was only me. I experience this too. Hopefully, this can <b=
r>
be fixed.<br>
<br>
A complete scan on my collection takes several days. So this has <br>
effectively been preventing me from using DK for some time.<br>
<br>
In fact I think a lot could be done to improve the whole experience <br>
regarding scanning collection. For one, the progress reporting could be <br=
>
MUCH better. Currently, it has an almost useless progress bar. It gives <br=
>
a percentage but nothing in terms of how many pictures/folders it has <br>
scanned and how many remaining. (I am aware that exact number of <br>
remaining objects might be impossible to give, but then estimate it like <b=
r>
other tools does, e.g. rsync will just update the number of remaining <br>
items as it learns about them...). There is also no estimate of how long <b=
r>
it will take or the processing rate (how many items per minute, etc.) <br>
All these infos would be useful. Especially if trying to make it faster <br=
>
and see what works.<br>
<br>
I also think the scanning could be sped up quite a bit by using multiple <b=
r>
threads. I have my collection on a NAS. I believe a lot of the time <br>
spent on scanning/indexing is really spent on network latency: waiting <br>
for the samba server to list files, open file handle, etc.<br>
<br>
When I look at resources on the DK client machine, it is mostly idle on <br=
>
both CPU, network and disk I/O. Same with the NAS server, it is mostly <br>
idle on those resources as well. So I think a lot of time is pent <br>
waiting for network packages. If I could allow 2, 4, 8, .., parallel <br>
threads, I think we could see this wait time reduced significantly and <br>
CPU/net/disk utilization increased.<br>
<br>
<br>
BR<br>
<br>
Thomas<br>
<br>
</blockquote></div>

--000000000000faeacf06562bd52f--