SUMMARY Hangs on Startup, with Album on Network share STEPS TO REPRODUCE 0. Mount your Pictures on a AFP Networkshare (not sure if the fileshare type is important) 1. Configure DK to use external MySQL DB 2. add a collection in a AFP network share (add no other collection) 3. Wait until albums are imported, make sure DG is working fine. 3.1 uncheck scan for new Items at startup 4. Quit DG 5. Restart DG 6. DG will show the splash screen forever. 7. The slash screen is showing "checking ICC Profiles" 8. when started from the commandline '/opt/digikam/Applications/KF5/digikam.app/Contents/MacOS/digikam' there is no error displayed, the last line is `digikam.general: Added root album called: "bilder@schapp"` OBSERVED RESULT 6. DG will show the splash screen forever. 7. The slash screen is showing "checking ICC Profiles" 8. when started from the commandline '/opt/digikam/Applications/KF5/digikam.app/Contents/MacOS/digikam' there is no error displayed, the last line is `digikam.general: Added root album called: "bilder@schapp"` The digikam process is flagged from the OS as not responding. Even after several hours this is not recovering. EXPECTED RESULT The process should not get flagged as not responding, even if there is background work to do. If there is a long running background task, there should be a indicator that something going on. But as I have disabled scan for new images at startup, I don't expect that there is a long running task ongoing. Frequent monitoring of the process via lsof doesn't show any file interaction with the files on the network share. There is not high CPU load. If the network share is not mounted at startup, digikam starts in an expected amount of time. When mounting the networkshare after startup in most cases DG works then as expected. Not seeing all this on Fedora 31 and DG 6.0. using the same DataBase and the same networkshare SOFTWARE/OS VERSIONS Windows: N/A macOS: 10.14.3 (18D109) Linux/KDE Plasma: N/A (available in About System) KDE Plasma Version: N/A KDE Frameworks Version: N/A Qt Version: N/A ADDITIONAL INFORMATION Unfortunately there is no easy way to strace and execution on MacOs anymore, therefor I need some guidance how to collect more troubleshooting information.
Can you please test the currently available pre-release OS X package from 22.04.2019? https://files.kde.org/digikam/ Maik
(In reply to Maik Qualmann from comment #1) Hi Maik Installed https://files.kde.org/digikam/digiKam-6.2.0-git-20190422T204358-MacOS-x86-64.pkg unfortunately with the same result. Thomas
Please try with digiKam-6.2.0-git-20190519T124258-MacOS-x86-64.pkg that i just uploaded at the same place... Gilles Caulier
(In reply to caulier.gilles from comment #3) Hi Gilles, more or less the same. Don't get the main DG Windows. But all seems to be a little bit more responsive, because in the past if I brought another windows to the foreground, I was not able to bring the splash screen back in front, but now it is possible. But hoovering over the splash screen, shows the MacOS Ball of Death. Thanks Thomas
Git commit 82642420797415e6e56a3a2f8b3983a4d6853d4d by Maik Qualmann. Committed on 19/05/2019 at 15:37. Pushed by mqualmann into branch 'master'. only a small attempt for this problem M +4 -1 core/libs/album/manager/albummanager_collection.cpp https://invent.kde.org/kde/digikam/commit/82642420797415e6e56a3a2f8b3983a4d6853d4d
Not sure if it is related, but DG is not shutting down cleanly here. Like reported in 407235, maybe this unclean shutdown triggers some recovery or so the next start, which will fail if Albums are on a network share.
As written, if DG starts with network share mounted, the last line of the console output is: `digikam.general: Added root album called: "bilder@schapp"` But if the network share is not mounted DG will start. With an unmounted network share the next line on the console output is: `digikam.general: Failed to find parent tag for tag "Bettina" with pid 6` Maybe this triggers some repair or so.
Have observed another behavior. If I unmount the network share, while DG is hanging: 1. the unmount is possible and happens immediately (so no file is open on this network share) 2. DG immediately stops hanging and starting, in the same why as there where not network share mounted from the beginning.
Git commit 26f171ef2b4960d0eeccc1a0a3e4bb64d6830264 by Maik Qualmann. Committed on 21/05/2019 at 06:02. Pushed by mqualmann into branch 'master'. add more debug M +4 -4 core/libs/album/manager/albummanager_palbum.cpp https://invent.kde.org/kde/digikam/commit/26f171ef2b4960d0eeccc1a0a3e4bb64d6830264
It's pretty clear in what function digiKam is stuck. I once created a special debug version. Gilles, would be nice if you can create a new Mac version. Maik
Hi Maik, I just started MacOS PKG building... Gilles
@Thomas Can you please look again, which messages will be displayed in the console until digiKam hangs? Maik
Hi Maik, here the output: ``` QFSFileEngine::open: No file name specified digikam.geoiface: ---- digikam.geoiface: ---- digikam.general: Added root album called: "bilder@schapp" digikam.general: Added root album called: "Pictures" digikam.general: In: CoreDbAccess().db()->scanAlbums() digikam.general: Out: CoreDbAccess().db()->scanAlbums() digikam.general: In: insertPAlbum() true digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() true digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() digikam.general: In: insertPAlbum() false digikam.general: Out: insertPAlbum() ... ``` The in/out pair repeats round 359 times (718 lines) in a few seconds, then the progress is very slow (a pair per minute). I have round about 2700 folder (including hidden) and round 1500 with Photos in this network share. Will leave it running to see, whats going on, but if it stays with this speed and there is an pair per folder, than it will need >> ten hours. By Thomas P.S. The root album "Pictures" is a local one. That I have added for some tests. It is a local one, but the behavior is same. This album is empty.
Ok, interesting. Do I understand it correctly that always an in-out pair is displayed immediately, it takes only in between long? I have a guess that the QFilesystemWatcher triggers blocking. I'm creating a new test version tonight. Maik
Git commit 8a2cbc6917d48bbc5d0b02b78d7bcda4176688cb by Maik Qualmann. Committed on 23/05/2019 at 19:10. Pushed by mqualmann into branch 'master'. QFileSystemWatcher can now be disabled. The setting is on the collection page. The default is off. Related: bug 406224, bug 403073, bug 398921 M +21 -13 core/libs/album/engine/albumwatch.cpp M +2 -0 core/libs/settings/applicationsettings.cpp M +3 -0 core/libs/settings/applicationsettings.h M +10 -0 core/libs/settings/applicationsettings_albums.cpp M +3 -0 core/libs/settings/applicationsettings_p.cpp M +3 -0 core/libs/settings/applicationsettings_p.h M +16 -14 core/utilities/setup/collections/setupcollections.cpp https://invent.kde.org/kde/digikam/commit/8a2cbc6917d48bbc5d0b02b78d7bcda4176688cb
With the next packages for MacOS, we'll see if I'm right. One more note to the QFileSystemWatcher, this only works with local drives. Mounted network drives do not work (even on Linux) with the QFileSystemWatcher. Maik
(In reply to Maik Qualmann from comment #14) > Ok, interesting. Do I understand it correctly that always an in-out pair is > displayed immediately, it takes only in between long? Not only one a lot of coming fast and then it gets slower and slower. Bye Thomas
Ad if I unmount the network share, it stops showing pairs and going to start like before.
Good news, Digikam (digiKam-6.2.0-git-20190524T080110-MacOS-x86-64.pkg) is starting now. It still stays on the "checking ICC Profiles" for a minute or to and is not responding in that phase, but after that it works as expected. Thanks for all your efforts! Thomas
Not sure if it is related or introduced by another change in in the latest build. While going through my photos in preview mode (Thumbs at the top, preview underneath) DG is randomly switching back to Thumbnail view.
I can not reproduce a problem here and a connection with the change is not possible. Without an action from you, the preview changes back to the icon view? Maik
No interaction is not true, I flipped through just imported photos and deleted a few of them. Tested a little bit. Flipping forth and back doesn't trigger is. But a delete. But not instantly it needs a several seconds and an image change (pressing an arrow key). Because of the delay is doesn't happen right with the first image, but a image flip is necessary to trigger the switch back to the thumbnail view. Bye Thomas
I cannot reproduce the problem here too. can you record the desktop when this behavior happen and shre the video on the cloud, just to be sure to understand the problem. Gilles Caulier
(In reply to caulier.gilles from comment #23) > I cannot reproduce the problem here too. > > can you record the desktop when this behavior happen and shre the video on > the cloud, just to be sure to understand the problem. Haven't seen this again. It is all fine now. Thanks for all the support. The case can be closed. Thomas