I can access the Albums residing on an NFS share, digiKam shows the content of all those. But when moving an image to such an Album, or creating a new Album there, I get an error "Das Album XYZ existiert nicht mehr" (msgid "Album %1 does not exist anymore") .) I can write to the according folder in the shell. .) digiKam still can write to Albums residing on the local fs. .) The folder/file names are withour special characters. .) It worked for the same Albums/Folders about 1 month ago. .) The messages in the shell look unsuspicious: -- digikam.general: Using 4 CPU core to run threads digikam.general: Action Thread run 1 new jobs digikam.general: Event is dispatched through a passive pop-up QLayout: Attempting to add QLayout "" to QWidget "", which already has a layout digikam.iojob: Thread Finished digikam.general: One job is done --
There is no error message in the output. Can you post more of the console output? I also do not think that we have changed anything in the last time. Please try the latest beta AppImage for testing from www.digikam.org. Maik
Created attachment 106003 [details] Encoded location path problem
Thanks for the comment. I logged all output from startup and viewing it I found the problematic symptom early in the startup logs: -- digikam.database: location for "%2Fdata%2Fmaccheroni%2Fpic" is available false digikam.database: location for "/home/kdi/Bilder" is available true digikam.database: location for "/data/local/Bilder" is available true -- So it seems that for whatever reason by whatever process the path to the location has been URL encoded or something similar. When looking into digikam's settings I could confirm it (I seemed to have overlooked that issue before). So for correction I created the same location again (see screenshot) and deleted the old one. Now it took about 3hrs to scan the folder again (I hope the local database has not lost any information), but it works. You can close the ticket, but I don't know, maybe it's worth the effort to find out what caused the path encoding, and maybe there is a more efficient way to fix it than to re-create the new location.
The wrong path came through the update from digiKam-4.x to digiKam-5.x. I close the bug report now. Maik