| Summary: | Attempting to rename multiple files hangs UI with no progress or way to cancel | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Matt Baker <kde.bugs> |
| Component: | AdvancedRename-engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | Keywords: | usability |
| Version: | 8.4.0 | ||
| Target Milestone: | --- | ||
| Platform: | Microsoft Windows | ||
| OS: | Microsoft Windows | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Debug log | ||
|
Description
Matt Baker
2024-08-21 21:47:41 UTC
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 Hi, The 8.7.0 pre-release Windows installer from today have been rebuilt from scratch with Qt 6.8.3, KDE 6.12, OpenCV 4.11 + CUDA support, Exiv2 0.28.5, ExifTool 13.27, ffmpeg 7, all image codecs updated to last version (jxl, avif, heif, aom, etc.). Please try with this version to see if your problem still reproducible... https://files.kde.org/digikam/ Thanks in advance Best regards Gilles Caulier |