Bug 314952

Summary: Import window should not lock the interface while reading photos
Product: [Applications] digikam Reporter: DrSlony <bugs>
Component: Import-Gphoto2Assignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: wishlist CC: bugs, caulier.gilles, pochini, tpr
Priority: NOR    
Version: 3.0.0   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In: 4.3.0

Description DrSlony 2013-02-12 00:27:22 UTC
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
Comment 1 Teemu Rytilahti 2013-12-05 00:40:36 UTC
Probably related to thumbnail loading, which is related to other downloading tasks I think. See also #314953.
Comment 2 Teemu Rytilahti 2013-12-05 00:42:32 UTC
*** Bug 314951 has been marked as a duplicate of this bug. ***
Comment 3 Teemu Rytilahti 2013-12-05 00:43:38 UTC
The duplicate bug entry is related to informing the user about the amount of photos available, and is thus related to this one.
Comment 4 Teemu Rytilahti 2013-12-05 00:44:33 UTC
*** Bug 314950 has been marked as a duplicate of this bug. ***
Comment 5 Teemu Rytilahti 2013-12-05 01:00:34 UTC
*** Bug 296649 has been marked as a duplicate of this bug. ***
Comment 6 Teemu Rytilahti 2013-12-05 01:04:47 UTC
*** Bug 283054 has been marked as a duplicate of this bug. ***
Comment 7 Teemu Rytilahti 2013-12-29 16:57:43 UTC
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
Comment 8 Teemu Rytilahti 2013-12-29 23:59:07 UTC
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
Comment 9 Teemu Rytilahti 2013-12-30 00:01:26 UTC
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.
Comment 10 Teemu Rytilahti 2014-01-02 10:37:13 UTC
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
Comment 11 Teemu Rytilahti 2014-01-02 10:40:57 UTC
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...
Comment 12 caulier.gilles 2014-06-16 12:27:57 UTC
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
Comment 13 caulier.gilles 2014-09-01 07:46:49 UTC
DrSlony,

Do you seen my previous comment ? Can you reproduce this problem using last digiKam 4.2.0 ?

Gilles Caulier
Comment 14 DrSlony 2014-09-01 12:57:21 UTC
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.