Bug 191774 - digikam download sorting slow, and wrong with multiple folders
Summary: digikam download sorting slow, and wrong with multiple folders
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Import-Sort (show other bugs)
Version: 0.9.5
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-06 07:37 UTC by Roger Larsson
Modified: 2017-08-18 06:04 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 1.0.0


Attachments
snapshot of dialog showing four of five images (in wrong order) (206.72 KB, image/png)
2009-05-16 00:14 UTC, Roger Larsson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roger Larsson 2009-05-06 07:37:26 UTC
Version:           0.9.5 (using 3.5.10 "release 21.11" , openSUSE )
Compiler:          Target: x86_64-suse-linux
OS:                Linux (x86_64) release 2.6.27.21-0.1-default

I have a 8GB compact flash (from Nikon D300) with lots (> 1k) of pictures in two folders (created by camera).
Putting this into an external reader (Epson RX620).
Download with "Import" -> "Camera" -> "Browse Media" -> "8.2G Removable media"

This causes two related (I think) problems

* Sorting(?) is VERY slow, close to one minute!
 It says that the files are listed, but then nothing happens...
 Bad sorting algorithm? Sorting on downloaded info not only file name?
 (BTW it is a nice feature to have the newest picture first)
* Sorting is wrong (the sorted folders are put after each other, but with the newer folder after!)
Comment 1 caulier.gilles 2009-05-06 08:14:12 UTC
The long operation is to get thumbs, not to list items.

Look message on the progress bar to be sure.

Also, on the right side of progress bar, a stop button must be available. press on it when thumbs are extracted, and you will be able to play with camera contents. Of course you will not see thumbs everywhere, but at least last shoted items will be generated in first.

Note : if you can, can you take a look to KDE4 version version camera gui have been re-designed...

Gilles Caulier
Comment 2 Roger Larsson 2009-05-06 19:58:51 UTC
progress bar is stuck on 0%
stopping it and you can not mark files without an thumbnail.

So you have to wait...
Comment 3 Roger Larsson 2009-05-06 20:03:18 UTC
Update: after a long time the progressbar does actually start moving! (I had almost given up)
The thumbnail download is actually quite fast, and not the issue here.
So before sorting is, retrieving names and sorting... (and it quickly says that it has retrieved the names...)
Comment 4 caulier.gilles 2009-05-07 08:00:23 UTC
Well, it's strange. Here, using CF reader or directly my camera in UMS mode (Minolta Dynax5D), with around 1500 RAW/JPEG files is fast to shwo icon items without thumbs. 

Thumbnails processing is more slow. In general, i stop it before end, because i just need last items taken with camera.

So, i suspect another problem in your computer.

1/ Try to open CF dir using konqueror. It's slow too ?
2/ Use another CF card. It's the same pb ?
3/ Run digiKam from a console and look all debug messages printed when you go to camera gui. There are some errors messages ?

Gilles Caulier
Comment 5 caulier.gilles 2009-05-13 13:09:27 UTC
Roger, any news ?

Gilles Caulier
Comment 6 Roger Larsson 2009-05-16 00:14:06 UTC
Created attachment 33702 [details]
snapshot of dialog showing four of five images (in wrong order)

Download and extract this file
http://www.theproperbay.org/KDE/bug191774-minimal.tar

Import Images (Ctrl I)
Browse to the extracted catalog
- I do only see four of the five images that should be there...
Comment 7 caulier.gilles 2009-05-25 13:10:22 UTC
Roger,

Fixed in digiKam 0.11.0 (current implementation from svn):

http://farm3.static.flickr.com/2479/3562786846_ee958e4a30_o.png

Gilles Caulier
Comment 8 caulier.gilles 2009-05-25 15:11:28 UTC
Roger,

Fixed in KDE3 code too (digiKam 0.9.6):

http://farm4.static.flickr.com/3404/3562201745_80dfaa277b_o.png

Sort algorithm is a little bit different than KDE4. This is why dcs_1327.jpg and csc_1337.jpg are inverted. In fact this is not a problem because item at the same shoot time-stamp.

Gilles Caulier
Comment 9 caulier.gilles 2009-05-25 15:12:13 UTC
>because item at the same shoot time-stamp.

because items have the same shoot time-stamp, i want mean (:=)))

Gilles Caulier
Comment 10 caulier.gilles 2009-05-25 15:13:45 UTC
SVN commit 972635 by cgilles:

fix sort of items, as KDE4.
BUG: 191842
CCBUGS: 191774


 M  +18 -10    cameraui.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=972635