Re: Collections are suddenly gone in DK

On 14/09/2025 19.14, Maik Qualmann wrote:
> The problem is, even if digiKam couldn't read the collection for some reason,
> the root album names should still be displayed. But you don't have them,
> right?


Yes, that is indeed the case. Or it was: I originally did not have my 
actual photo collection root folders in the albums list. However, after 
having let it run for a very long time (days), they eventually showed 
up. So the root folders are there. But the folders /inside/ those root 
folders are missing a lot.

Here is an example:


In this example, you can see 3 collection root folders.

The "photo" collection is the largest one.

As you can see, it has a folder per year going back to the 1900s.

As you can also see, the most recent one on the list is 2024. There is 
no 2025.

And when I expand the 2024 folder, it is not complete. It does not 
contain all the 2024 subfolders/albums.


Now, I thought this might be due to DK needing more time to find new 
items. However, this is /not/ the case, becase DK pops up after a while 
with the "Processing done" popup indicating that it finished scanning 
for new items.


Last lines of DK debug log says:

digikam.database: Complete scan took: 412969 msecs.
qt.svg: QSvgHandler: Image filename is empty
qt.svg: QSvgHandler: Image filename is empty
digikam.general: Event is dispatched to OSX desktop notifier


So I guess DK has decided that there are no more images...


I have just sent you a new digikam debug log via private email.



> Your log doesn't show any anomalies or error messages from the database. But I
> can only imagine some kind of database problem.


One thing I noticed in the logs is this:

digikam.database: Creating new Location  "/"  uuid 
"networkshareid:?mountpath=/Volumes/photo&fileuuid=***"
digikam.database: Creating new Location  "/Users/***/Pictures" uuid  
"volumeid:?uuid=******&fileuuid=****"
digikam.database: Creating new Location  "/"  uuid 
"networkshareid:?mountpath=/Volumes/*****/photos&fileuuid=****"
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::checkRequested(QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::checkDone(Solid::ErrorType, 
QVariant, QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::repairRequested(QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::repairDone(Solid::ErrorType, 
QVariant, QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::checkRequested(QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::checkDone(Solid::ErrorType, 
QVariant, QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::repairRequested(QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::repairDone(Solid::ErrorType, 
QVariant, QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::checkRequested(QString)
qt.core.qobject.connect: QObject::connect: No such signal 
Solid::Backends::IOKit::IOKitStorageAccess::checkDone(Solid::ErrorType, 
QVariant, QString)



Granted, I do not know what those IOKit calls are. But I could imagine 
this is something relating to accessing the file shared that fails?



> If you haven’t already, please try the digiKam-8.8.0 pre-release version from
> here:https://files.kde.org/digikam/

I will try with the proposed pre-release version and report back.

BR

Thomas