"scan for new items" always scans the entire collection

[VALÍK Robert]

Sorry, attaching now.

1. started Digikam, let the scan run for a few seconds
2. cancel the index
3. refresh Photos-Import/2026/20260704
4. refresh Photos-Import/2026/20260704 second time
5. refresh Photos-Import/2026 - and the "Find new items" stays at 0% 
(watching the logs - it reread [and rewrote the data in DB] the first 
folder 20260101 quickly than paused for like a minute and continued after)
6. I then aborted the refresh, digikam shows "No active process" but the 
output and MariaDB binlog show that it still runs and scans... Stops 
after I close digikam.

Than I started digikam again and the full scan and rewrite of data in 
the DB start again...

If you need the full scan to finish, I can let it run during the night 
(but already did that a few times with no change).

Robert

On 7/17/26 20:11, Maik Qualmann wrote:
> The AppImage log looks fine so far, aside from the fact that the color profile
> isn't being detected—though that’s a separate issue.
> Why isn't there a log from your Arch version? A debug build isn't necessary
> for terminal output.
>
> Maik
>
> Am Freitag, 17. Juli 2026, 09:17:17 Mitteleuropäische Sommerzeit schrieb VALÍK
> Robert:
>> Hello,
>>
>> the 9.2.0 debug AppImage does not show the weird behavior. It correctly
>> starts, scans for new items for a fraction of a second and is done. I
>> also tried to refresh one existing folder and it was immediate without
>> rewriting all  image metadata data (logs attached) to the DB like the
>> Arch extra/digikam 9.1.0-6 does.
>>
>> Robert
>>
>> On 7/16/26 06:39, Maik Qualmann wrote:
>>
>>> Please test the digiKam 9.2.0 pre-release version available here:
>>>
>>>
>>>
>>> https://files.kde.org/digikam/
>>>
>>>
>>>
>>> It includes debug code to investigate the issue further. Please post a
>>> log
>>> from a digiKam startup that includes a scan, as described here:
>>>
>>>
>>>
>>> https://www.digikam.org/contribute/#freezes-and-other-run-time-issues
>>>
>>>
>>>
>>> Maik
>>>
>>>
>>>
>>> Am Freitag, 10. Juli 2026, 07:02:28 Mitteleuropäische Sommerzeit schrieb
>>> VALÍK
>   Robert:
>>>> No,
>>>>
>>>>
>>>>
>>>> a) that disables the whole functionality - detecting new items and albums
>>>> in
>   the collection b) as I regularly create new albums (folders) I
>>>> cannot refresh them as they do not exist in Digikam. I have to refresh
>>>> the whole subtree (folder above them) to let Digikam detect them and it
>>>> takes almost an hour and the result is almost the same, every existing
>>>> image in tget path gets scanned again and it’s metadata (abd thumbnail)
>>>> are rewritten c) I do import photos from different sources and different
>>>> dates so it is quite impossible to know every folder I should refresh
>>>>
>>>>> On 9 Jul 2026, at 20:34, Rainer J.H. Brandt<rjhb at bb-c.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>> Diego writes:
>>>>>
>>>>>> In our case (no faces involved), "scan for new items" should only scan
>>>>>> new items; without this option checked, it should scan the entire
>>>>>> collection. The problem reported here (for DK 9.1.0) is that
>>>>>> regardless
>>>>>> of whether you ask to "scan for new items" or not, it will scan the
>>>>>> entire collection. This is not the expected behavior.
>>>>> I use the "Refresh" item of the album context menu, in the album tree
>>>>> opened from the left edge controls.  That only scans the selected album
>>>>> for new items.  Does that work for you?
>>>>>
>>>>>
>>>>>
>>>>> Cheers, Rainer
>>>
>>>
>>>
>> -- 
>> *Robert Valík*
>> https://robert.valik.sk/
>>
>> Sent from my MUA
>
>
>
-- 
*Robert Valík*
https://robert.valik.sk/

Sent from my MUA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20260718/f1983a07/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digikam_arch_910.tar.gz
Type: application/gzip
Size: 195932 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20260718/f1983a07/attachment-0001.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x60874026DA8B0D6F.asc
Type: application/pgp-keys
Size: 3805 bytes
Desc: OpenPGP public key
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20260718/f1983a07/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20260718/f1983a07/attachment-0001.sig>