After upgrading to DK 8.6 no images can be opened in my collection

[Thomas]

Hi Maik,

Thanks!
This seemed to do the trick!

That leads me to the following questions:

0: What is  DK actually doing when I click this button and initiate this 
operation? It seems to require siginifanct amount of work. But the I/O 
throughput on the network between the NAS and the client does not seem 
to be too heavy. Rather it seems to be a lot of small operations. So I 
do not think it is re-reading all the photos. Is it just reading the 
metadata (e.g. what files are present, when were they changed, what 
size, etc.) and comparing to the database/inserting to the database?


1: Why does this happen? - that DK sometimes "forgets" about big chunks 
of my collection and thus stops being able to see files/folders in it? 
This has happened multiple times now. Am I doing something wrong outside 
of DK that triggers this issue?


2: This operation takes a /long/ time on a big collection. On my 
specific collection it has taken several days in which I must have the 
Mac up and running with DK doing this huge indexing operation. This 
means that I can effectively not use DK for those days, and worse: I 
cannot take my laptop anywhere, because I must leave it on the network 
during this whole time... Would it be possible to pause/resume this 
somehow across DK process start/stop?


3: I have a hunch that this might be relating to how macOS mounts SMB 
shares. Would it be possible to have DK talk to the SMB host directly 
rather than having the OS mount the files and have DK treat them as 
"local"ish files? I know some other application that does this where 
they talk directly to a given smb:// url that is not mounted on the OS. 
Would that be feasible - and would it even help solve this issue?


4: As a follow up to #0: IFF DK is merely indexing all the files and 
reading their metadata and then comparing with the local SQLite 
database, I think it might be possible to speed this up significantly by 
using a producer-consumer approach is done like this:

  * First, in one thread (producer thread): traverse through the
    collection root (e.g. something similar to "find /path/to/collection
    -ls") stream all metadata discovered to the consumer thread.
  * Second, in a different thread (consumer-thread): consume all the
    metadata in the buffer and query the SQLite db based on the incoming
    metadata, process thumbnails, etc..


I suspect what is happening is that DK is traversing through the 
collection, and when it spots a file, it processes is (query db, process 
thumbnails, etc); then it continues the traversing, and so on. IFF this 
is the case, it means that it will spend /a lot/ of time waiting for I/O.


I just checked my NAS. It is able to do a full "find -ls" on my photo 
collection in the order of a few minutes. That is a /lot/ less than 
several days.

Now, I may be completely (or perhaps only somewhat) off in my analysis.

I would love to learn.


BR

Thomas


On 2026-02-22 20.38, Maik Qualmann wrote:
> Go to the digiKam settings under Collections. Next to the relevant network
> collection, you'll find a tool button (a round icon). Complete all dialog
> boxes, ensuring the path is correct. This will update the UUID for the
> collection in the database.
>
> Maik
>
> Am Sonntag, 22. Februar 2026, 20:19:46 Mitteleuropäische Normalzeit schrieb
> Thomas:
>> Hello Emre,
>>
>>
>> Unfortunately, I have not been able to find a solution.
>>
>> In fact, I have to now use a Windows machine in order to use DK.
>>
>> I have even tried installing various "nightly builds" og Digikam 9.0 but
>> alas, it does not work.
>>
>>
>> I think our setups are very similar:
>>
>>    * DK installed on macOS.
>>    * Photo collection hosted on SMB/NAS.
>>
>>
>> Please let me know if you manage to sort this out. Please describe your
>> problem in detail on thedigikam-users at kde.org mailing list (CC).
>> Someone more experienced than me will hopefully help you out.
>>
>>
>>
>> BR
>>
>> Thomas
>>
>> On 22/02/2026 20.14, Emre Ayhan wrote:
>>> Hello Thomas,
>>>
>>> I had a Problem with Digikam on my MacBook and came by your E-Mail
>>> inside of the Digikam Mailing Archive, where you talked about the same
>>> Problem with Digikam on your MacBook. Specifically it was about the
>>> Digikam 8.6 upgrade and not being able to work with images which are
>>> stored on Network Drives / NAS Storage (which is attached as a Volume
>>> on MacBook) inside of Digikam.
>>>
>>> If it's not a problem for you, I wanted to ask you if you could help
>>> me out with my Digikam problem.
>>>
>>>
>>> I came across the same Problem with my MacBook + Digikam and wanted to
>>> ask you, what exactly made the Problem go away for you? I connected my
>>> MacBook to the NAS via smb and the NAS Storage gets attached in the
>>> Volumes directory. I gave Digikam full disk management rights in the
>>> system settings and I also tried to run it via the terminal with logs
>>> enabled, but I still did not get it to work, meaning that I cannot
>>> open or copy the images inside of Digikam (which are stored on my
>>> NAS). Do you have any other ideas or steps which I could use or try to
>>> get my Digikam "working" again?
>>>
>>> Thanks a lot
>>> Emre Ayhan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20260226/3a9cd3e0/attachment.htm>