I had to wait 90 seconds before the Import window showed that I have 2052 raw photos on a 32B memory card. During these 90 seconds I could have configured the import settings, e.g. worked on the custom file renaming format, but I couldn't. The 90 seconds were completely non-productive. Reproducible: Always
Probably related to thumbnail loading, which is related to other downloading tasks I think. See also #314953.
*** Bug 314951 has been marked as a duplicate of this bug. ***
The duplicate bug entry is related to informing the user about the amount of photos available, and is thus related to this one.
*** Bug 314950 has been marked as a duplicate of this bug. ***
*** Bug 296649 has been marked as a duplicate of this bug. ***
*** Bug 283054 has been marked as a duplicate of this bug. ***
Git commit 880354561b9ecd2a799def6aa0847cc80dcfa567 by Teemu Rytilahti. Committed on 29/12/2013 at 16:44. Pushed by rytilahti into branch 'master'. Speed-up the UI, first step to fix 314952. - Fix caching by using QWriteLocks when the cache is being written. We need to do this, because QCache is not thread-safe. - Don't request image data from the camera just to get the name of it when requesting a thumbnail, because we have the list already available after getting the file list. M +5 -5 utilities/importui/backend/cameracontroller.cpp M +1 -0 utilities/importui/main/importui_p.h M +16 -3 utilities/importui/models/importthumbnailmodel.cpp http://commits.kde.org/digikam/880354561b9ecd2a799def6aa0847cc80dcfa567
Git commit 0c836cb940f4276eaecfbf2995f75d974b794752 by Teemu Rytilahti. Committed on 29/12/2013 at 23:58. Pushed by rytilahti into branch 'master'. Add previewPossible field to CamItemInfo that is used to decide whether the thumbnail is being queried from the backend. This speeds up loading of thumbnails as it'll just use the mimetype icon when the backend says the thumbnails are not supported. This is especially crucial for gphoto2 backend as it'll otherwise throw a lot of errors and slows down remarkably. Also probably speeds the UMS backend too as we don't try to parse the unsupported files. Note, that CamItemInfo's operators were not changed except the debugging one. M +3 -0 utilities/importui/backend/camiteminfo.cpp M +1 -0 utilities/importui/backend/camiteminfo.h M +5 -0 utilities/importui/backend/gpcamera.cpp M +7 -1 utilities/importui/backend/umscamera.cpp M +4 -1 utilities/importui/models/importthumbnailmodel.cpp http://commits.kde.org/digikam/0c836cb940f4276eaecfbf2995f75d974b794752
Those commits I made are relevant to this bug, but the main issue is that getting the folder listing is blocking and it takes long time (at least with PTP backend of gphoto2). The next step is to make that incremental and then this bug should be fixed.
Git commit c64fea2e8545d97628c282752f74082f2d2e7812 by Teemu Rytilahti. Committed on 02/01/2014 at 09:18. Pushed by rytilahti into branch 'master'. Don't block the import UI by waiting for a complete folder listing for the whole device, but build the model gradually. The new flow goes like this: 1. When a connection to a camera is made, call methods for loading files and subfolders for the root folder. 2. The backend reports via signal about the subfolders in given folder. 3. Request is being made to download file listing for the returned subfolders, and then check for their subfolders. 4. Repeat until finished. FIXED-IN:4.0.0 M +22 -13 utilities/importui/backend/cameracontroller.cpp M +2 -1 utilities/importui/backend/cameracontroller.h M +1 -1 utilities/importui/backend/dkcamera.cpp M +6 -3 utilities/importui/backend/dkcamera.h M +17 -46 utilities/importui/backend/gpcamera.cpp M +1 -2 utilities/importui/backend/gpcamera.h M +37 -38 utilities/importui/backend/umscamera.cpp M +1 -1 utilities/importui/backend/umscamera.h M +7 -1 utilities/importui/main/importui.cpp M +1 -0 utilities/importui/models/importthumbnailmodel.cpp http://commits.kde.org/digikam/c64fea2e8545d97628c282752f74082f2d2e7812
Actually let's reopen this. While the commits help as you don't have to wait so long anymore, the widgets themselves are still disabled while there is something going on in the background...
In next 4.1.0 (current implementation from git/master) i re-introduced a thumb cache controller for import tool. This problem still exist using this code ? Gilles Caulier
DrSlony, Do you seen my previous comment ? Can you reproduce this problem using last digiKam 4.2.0 ? Gilles Caulier
Hello Tested now in 4.2.0 with just over 1192 raw photos on an SD card. I cannot reproduce the delay - within a second the Windows fills up and shows me I have 1192 items on the card. Thank you for fixing it.