Summary: | The storage location of this image is currently not available | ||
---|---|---|---|
Product: | [Applications] digikam | Reporter: | Stefan Paul <stefan.paul> |
Component: | Database-Media | Assignee: | Digikam Developers <digikam-bugs-null> |
Status: | REPORTED --- | ||
Severity: | normal | CC: | caulier.gilles, eric.moret, metzpinguin |
Priority: | NOR | ||
Version: | 7.4.0 | ||
Target Milestone: | --- | ||
Platform: | macOS (DMG) | ||
OS: | macOS | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Terminal Output |
Description
Stefan Paul
2021-06-18 07:57:53 UTC
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 @Stefan Please try the new 8.5.0 pre-release PKG installer for MacOS Silicon (arm64) available here: https://files.kde.org/digikam/ Thanks in advance Gilles Caulier |