I had approx 2200 photos on a local SSD with a combined size of 36 GiB which I attempted to rename by selecting them all and pressing F2. This caused the UI to freeze while the program presumably read all of the selected images' meta data. There was no progress indication, status information or a way to cancel the operation - only the spinning cursor was displayed. After a significant amount of time the UI became responsive again and the rename dialogue appeared. I've also attempted this on a collection from a network share with 7600 images / 122 GiB of data which I gave up on after waiting over 20 minutes. STEPS TO REPRODUCE 1. Select 1000 images of approx 10 MiB or more in size from the Album view 2. Press F2 to rename them OBSERVED RESULT UI hangs with no ability to cancel operation. Also no progress bar or status information. digiKam's RAM usage slowly increased to 18 GB and then stabilised. EXPECTED RESULT Responsive UI with ability to cancel the operation. Progress bar and name of current file being read. SOFTWARE/OS VERSIONS Windows: 10 22H2 19045.4529
Created attachment 172833 [details] Debug log Seems to be the metadata loading using Exiv2 taking the time. Is this info not stored in the local DB?
I think the advanced rename operations do not run in a separated thread, at least to prevent the GUI freeze. Gilles Caulier
If you use a metadata option (meta:) in your (last) rename string, the metadata of all images must be read. Only selected metadata is contained in the DB. Since digiKam-8.4.0 we even use a metadata cache so that the content does not have to be read again and again every time the rename string is changed. It will not get any faster... A thread would be conceivable, but the metadata still needs to be read... Maik
In addition to the single threading, from my perspective, it seems wrong that pressing F2 does not immediately display the rename dialogue before doing anything else. Should the source metadata-read only occur if the pattern options require it? If they are basic options already stored in the local DB, could it not skip the full metadata-read? If the patterns are changed by the user from something that requires additional metadata to something that is already in the local DB, then the existing additional metadata-read operation should be aborted. If additional metadata information is required, it would be nice if the rename list/table in the rename dialog highlighted the current files that it is reading for additional data with a small status string displaying what is occurring. I know this is no small task to implement and just intended as a suggestion.
If the background operations (database, exiv2) works in a separated thread, well the GUI will appears immediately... Gilles Caulier
The problem only arises if you use the metadata option (meta:). Since we save the rename string, the problem arises immediately when opening. Try not to use the metadata option, date e.g. you can get also from the DB option. Maik
Unfortunately I had to use the extended metadata for it to grab the correct ms value for my files. zzz returned 000 for all files. I think I saw a related bug about this.
digiKam handle sub-seconds, at least with the SQLite database if they are available in the creation date of the metadata. In my experience, this is relatively rare. I would use the unique modifier instead. Maik