SUMMARY I create a new folder in the album directory and DigiKam cannot recognise this folder. DigiKam recognises other changes in existing folders without any problems. I have tried several times to update the whole thing manually without success. Please don't try to install a new version, the 8.5.0-QT5 only starts with a white window without anything else so even more problematic. STEPS TO REPRODUCE 1. Create a new Folder in an existing Album that DigiKam managed OBSERVED RESULT none EXPECTED RESULT That DigiKam recognises the new folder of the album so that I can continue. SOFTWARE/OS VERSIONS Windows: Windows 10x64 22H2 (available in the Info Center app, or by running `kinfo` in a terminal window) Linux/KDE Plasma: KDE Plasma Version: KDE Frameworks Version: Qt Version: if then the which DigiKam has installed with ADDITIONAL INFORMATION
Use digiKam-8.5.0 with Qt6 in the name because of the white window. The Qt5 version only exists to verify possible regressions of the Qt6 version. Maik
The same problem also occurs with version 8.5.0 QT 6.
(In reply to Daimonicon from comment #2) > The same problem also occurs with version 8.5.0 QT 6. Small detail forgotten so the error with the folder update not with the white window.
Do you create the folder externally or with digiKam? Maik
(In reply to Maik Qualmann from comment #4) > Do you create the folder externally or with digiKam? > > Maik So far I have created all folders externally but within an existing structure. Album Root -> X ---> Y New Folder 1 New Folder 2 Now I have created a new folder externally below root for the first time and it is not identified. So under "X" or "Album Root" this one will not be updated.
Are you using the album monitoring for external changes in digiKam collection settings so that the external changes are adopted at runtime? If you restart digiKam, do the folders appear? Maik
(In reply to Maik Qualmann from comment #6) > Are you using the album monitoring for external changes in digiKam > collection settings so that the external changes are adopted at runtime? > > If you restart digiKam, do the folders appear? > > Maik I don't know what this "album monitoring" is or where to find it. Even after a restart, the folder is not recognised. I thought it should work because it also recognises externally created folders within an album. However, creating a new album entry in DigiKam itself seems to work and it is recognised.
I have illustrated the whole thing here again in the screenshot in case I have described it badly. I probably didn't realise that all folders are albums ore sub-albums and if I want to have a new folder (album) I have to create it in DigiKam and not externally? So that would be a wrong assumption and not a bug in that sense. https://prnt.sc/-N5cSsTGtu9L
No, created external albums must be found automatically after restarting digiKam. At the moment I have no idea why it shouldn't work for you. What are the exact settings in the digiKam settings under Miscellaneous-> Behavior for "searching for new entries"? Maik
Created attachment 176247 [details] attachment-3931451-0.html Is that this Tab ? https://prnt.sc/dH-Ay0sltfmb Am Sa., 30. Nov. 2024 um 19:27 Uhr schrieb Maik Qualmann < bugzilla_noreply@kde.org>: > https://bugs.kde.org/show_bug.cgi?id=496867 > > --- Comment #9 from Maik Qualmann <metzpinguin@gmail.com> --- > No, created external albums must be found automatically after restarting > digiKam. At the moment I have no idea why it shouldn't work for you. > > What are the exact settings in the digiKam settings under Miscellaneous-> > Behavior for "searching for new entries"? > > Maik > > -- > You are receiving this mail because: > You reported the bug.
Please deactivate the "Schneller Scan". New albums may not be recognized. Maik
Created attachment 176256 [details] attachment-4056377-0.html Thank you, with this setting DigiKam now also recognises all external folder changes. This should solve the problem. Am Sa., 30. Nov. 2024 um 21:39 Uhr schrieb Maik Qualmann < bugzilla_noreply@kde.org>: > https://bugs.kde.org/show_bug.cgi?id=496867 > > --- Comment #11 from Maik Qualmann <metzpinguin@gmail.com> --- > Please deactivate the "Schneller Scan". New albums may not be recognized. > > Maik > > -- > You are receiving this mail because: > You reported the bug.
In "fast scan" mode, the parent modification date of the folder must change. This is not the case for all file operations. This is also explained in the description of the option in the setup. However, if a new folder/file is created, the modification date of the parent folder should definitely change. Can you please test with Explorer whether the modification date changes? It could also be a Windows bug. At least with the current Windows 11, there are currently some problems with the file date during copy operations (date is reset to the current one) etc. Maik
Created attachment 176257 [details] attachment-4067917-0.html In my current version, Explorer has a refresh lag when creating something new (Win 10 22H2 19045.5131) which seems to happen quite often after an update. But if I create a new folder and there is no lag then it immediately updates the date of the parent directory. I usually only update DigiKam when I can actually see the folder in Explorer - but maybe that plays a role in not recognising it. Am So., 1. Dez. 2024 um 09:58 Uhr schrieb Maik Qualmann < bugzilla_noreply@kde.org>: > https://bugs.kde.org/show_bug.cgi?id=496867 > > --- Comment #13 from Maik Qualmann <metzpinguin@gmail.com> --- > In "fast scan" mode, the parent modification date of the folder must > change. > This is not the case for all file operations. This is also explained in the > description of the option in the setup. However, if a new folder/file is > created, the modification date of the parent folder should definitely > change. > Can you please test with Explorer whether the modification date changes? > It could also be a Windows bug. At least with the current Windows 11, > there are > currently some problems with the file date during copy operations (date is > reset to the current one) etc. > > Maik > > -- > You are receiving this mail because: > You reported the bug.