SUMMARY I've got a lager collection of photos, which I would like to manage centraly with a Synology NAS. We've got Windows & Apple Computer and with the last named we've got problems. I created on the NAS a MySQL database on which the computers connect. I loaded a bunch of photos in a folder on the NAS. In the setting of digicam database & collections are propper linked to the NAS-folder. The NAS-folder is on Windows & macOS mounted with the login of the user. On Windows everything works fine, but on macOS, after it worked once, I get when I click on a photo the following error: "The storage location of this image is currently not available" STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: BigSur 11.3 Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION Synology NAS DS918+ Database: MariaDB 10
The image folder should be added as a network collection. Was it done like that? Maik
Yes, the folder is added as network collection //ds-educdesign-e/home/Drive/Moments
Hmm, testing a network collection to see if it's online is easy. We check whether there is at least one file or folder in the mount path, if not, we take the collection offline. So the question is why there are apparently no files in the mount path under MacOS. Maik
Hi Maik, I just had 5min to retest digikam a bit more. I copied the path out of the network connection in the preferences of digikam, then I deleted the path, an I pasted the path which I copied before in, and it solved my problem. What actualy the reason for this problem was, I don't know, but thanks for your help. Now I've got a other problem with the tag symbols under macOS, but for this I will make a new post
I have the same problem running on macOS BigSur 11.5.2 with Digikam 7.3.0. The workaround described in https://bugs.kde.org/show_bug.cgi?id=438845#c4 is only fixing it temporarily. A more reliable way to access network share from MacOS would be better.
The log from the terminal when starting digiKam would be interesting to see whether the network collection is recognized. Here is a description of how the environment variable is set and how the log can be obtained in MacOS: https://www.digikam.org/contribute/ Maik
Created attachment 140898 [details] Terminal Output macOS 11.5.2, Digikam 7.3.0, network path not working
Yes, the network collections are recognized as not available. This must be a MacOS specific problem. The network path must contain at least one file or folder. The QDir::entryList() returns no entries. Either MacOS "sleeps" or the file system is mount during the first access. I have an idea for a workaround I'll test. Maik
Regardless of this problem, we can not determine the currently available memory size under MacOS because the function not supported MaOS. We only create a cache of 60MB for preview images. Normally, it is approximately cache from 400MB for a memory size of 8GB. We need to fix this. Maik
Maik, The memory info is not supported from kmemoryinfo code in digiKam core, for MacOS. This code come from the memory_stats.c part from libststgrab : https://libstatgrab.org/ Code is on github : https://github.com/libstatgrab/libstatgrab/tree/master/src/libstatgrab As MacOS is a freebsd like system this can be easy to patch... Gilles
A possible solution is given in this post using sysctl: https://stackoverflow.com/questions/8782228/retrieve-ram-info-on-a-mac Gilles
About the comment #8 : What's about the right access to the mount path from client applications under MacOS ?
(In reply to caulier.gilles from comment #12) > About the comment #8 : What's about the right access to the mount path from > client applications under MacOS ? Since the second attempt works, through the workaround in Comment 4, since CollectionManager::updateLocations () is triggered again, it cannot actually be a rights problem. Maik
Git commit 40d09500b9c94333e74473da98da37bc1f64097d by Maik Qualmann. Committed on 21/08/2021 at 13:51. Pushed by mqualmann into branch 'master'. try with QFileInfo to wake up and use QDirIterator M +3 -3 core/libs/database/collection/collectionmanager_location.cpp https://invent.kde.org/graphics/digikam/commit/40d09500b9c94333e74473da98da37bc1f64097d
Sorry for a noob question, how can I test this change? Should I wait for the next version of Digikam to come out or is there a better/faster way?
Hi, The daily bundles build machine is down since 15 of august due to a power shutdown. This machine build a PKG installer for MacOS which is published online in a download area. This machine will be up later next monday, not before. sorry. Gilles Caulier
A new MacOS package is available. Can the problem still be reproduced? https://files.kde.org/digikam/ Maik
I can still reproduce this problem with latest build as of 9/1/2021
Maik, I just discovered that KMemoryInfo is in KF5::KCoreAddons module here since KF5 5.95 : https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/util/kmemoryinfo.h ... and it support Windows, Linux, FreeBsd, Android, and... MacOS. It don't use libstatgrab backend, it's a pure Qut implementation as i can see. I think it safe to replace DK core class as well (KF5 5.95 is too young for the moment)... Gilles
Git commit 930de78b3fc3171b87846877a66ec64a45011510 by Gilles Caulier. Committed on 20/06/2022 at 16:39. Pushed by cgilles into branch 'master'. use new class from DK core to handle memory device information M +0 -1 core/app/DigikamCoreTarget.cmake M +0 -1 core/libs/CMakeLists.txt M +15 -12 core/libs/dialogs/libsinfodlg.cpp M +10 -7 core/libs/dimg/loaders/dimgloader.cpp D +0 -20 core/libs/kmemoryinfo/CMakeLists.txt D +0 -215 core/libs/kmemoryinfo/kmemoryinfo.cpp D +0 -127 core/libs/kmemoryinfo/kmemoryinfo.h D +0 -847 core/libs/kmemoryinfo/libstatgrab/kmemoryinfo_backend.cpp M +1 -0 core/libs/threadimageio/CMakeLists.txt M +3 -3 core/libs/threadimageio/fileio/loadingcache.cpp https://invent.kde.org/graphics/digikam/commit/930de78b3fc3171b87846877a66ec64a45011510
Git commit e4fbd86ff7be46b388aaf8ba78b780d45f2029a5 by Gilles Caulier. Committed on 20/06/2022 at 16:52. Pushed by cgilles into branch 'qt5-maintenance'. DMemoryInfo: sync with master M +0 -1 core/app/DigikamCoreTarget.cmake M +0 -1 core/libs/CMakeLists.txt M +15 -13 core/libs/dialogs/libsinfodlg.cpp M +11 -9 core/libs/dimg/loaders/dimgloader.cpp D +0 -20 core/libs/kmemoryinfo/CMakeLists.txt D +0 -215 core/libs/kmemoryinfo/kmemoryinfo.cpp D +0 -127 core/libs/kmemoryinfo/kmemoryinfo.h D +0 -847 core/libs/kmemoryinfo/libstatgrab/kmemoryinfo_backend.cpp M +1 -0 core/libs/threadimageio/CMakeLists.txt A +547 -0 core/libs/threadimageio/engine/dmemoryinfo.cpp [License: GPL (v2+)] A +162 -0 core/libs/threadimageio/engine/dmemoryinfo.h [License: GPL (v2+)] M +3 -4 core/libs/threadimageio/fileio/loadingcache.cpp https://invent.kde.org/graphics/digikam/commit/e4fbd86ff7be46b388aaf8ba78b780d45f2029a5
Hi all, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
@Stefan, digikam 8.2.0 pre-release have been rebuilt using last Qt 5.15.11 + KDE 5.110 frameworks. Installer is available at usual place : https://files.kde.org/digikam/ Can reproduce the problem with this version? Thanks in advance Gilles Caulier
Git commit d472489b5457710d44c83ed6bac61c795e607646 by Maik Qualmann. Committed on 25/04/2024 at 19:18. Pushed by mqualmann into branch 'master'. show an error icon if the collection/album root is not available Related: bug 481888, bug 467766 M +17 -0 core/libs/album/engine/albumthumbnailloader.cpp M +1 -0 core/libs/album/engine/albumthumbnailloader.h https://invent.kde.org/graphics/digikam/-/commit/d472489b5457710d44c83ed6bac61c795e607646