Bug 165829

Summary: Failed photos during download are not consistent with actual file
Product: [Applications] digikam Reporter: Finn Blucher <finn>
Component: Import-MainViewAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles
Priority: NOR    
Version: 0.9.3   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In: 5.1.0
Sentry Crash Report:
Attachments: Screen shots

Description Finn Blucher 2008-07-06 03:51:40 UTC 
Version:           digikam-0.9.3-70.1 (using KDE 3.5.9)
Installed from:    SuSE RPMs
OS:                Linux

When I download selected files from my memory card using digikam several files will not transfer and show up with a red X. The problem is that the photo that digikam tells me did not transfer is not the file that failed, the file that failed is the one before it.

e.g. If I select photo-1 photo-2 photo-3 photo-4 for download this is the sort of thing that happens.

photo-1 - Digikam shows completed transfer - File is transferred correctly

photo-2 - Digikam shows completed transfer - Contents of file is actually photo-3 but has been named photo-2

photo-3 - Digikam shows failed transfer - File is actually been transferred named as photo-2

photo-4 - Digikam shows completed transfer - File is transferred correctly

So photo-3 gets named photo-2 and photo-2 never gets transferred. As you might guess this makes it VERY confusing to work out which files have been transferred and which haven't. 

I have had this problem on openSUSE 10.3 and openSUSE 11.0. I have tried different card readers, different USB cables and different memory cards. There are no errors on the console other than complaining about Exif size for every file. I have used both the default exiv2 program and an updated SVN source build (exiv2 0.17.91) and both give the same error.

>>>
Warning: Directory Canon has an unhandled next pointer.
Warning: Size 5352 of Exif.Canon.0x4002 exceeds 4096 bytes limit. Not decoded.
>>>

5-10% of files will fail in this way every time I transfer photos. If I reselect the files with the red cross and the files before them and retranser with "overwrite all" then the transfer completes correctly.

I have screen shots to show this happening.
Comment 1 Finn Blucher 2008-07-06 04:04:27 UTC 
Created attachment 25869 [details]
Screen shots

Here are some screen shots with explanations
Comment 2 Arnd Baecker 2008-07-06 16:25:19 UTC 
Wasn't something like this recently fixed for the upcoming 0.9.4?
(I only found http://bugs.kde.org/show_bug.cgi?id=159236).
Maybe you could try to install the release candidate digiKam 0.9.4-rc1
(rc2 is about to come very soon), and check whether the issue remains?

Best, Arnd
Comment 3 Andi Clemens 2008-07-06 16:27:40 UTC 
rc2 is already out: http://sourceforge.net/project/showfiles.php?group_id=42641

I have not prepared a blog entry yet, never done this before... :-) Maybe you, Arnd, want to volunteer?
Comment 4 caulier.gilles 2008-07-07 08:28:57 UTC 
To Arnd #2,

Yes, i have already fixed this problem into 0.9.4.

Gilles
Comment 5 Andi Clemens 2008-07-08 16:41:52 UTC 
Finn,

are you able to compile 0.9.4-rc2 for SUSE? If so, is the problem still existing? If not we might close this one again...
Comment 6 caulier.gilles 2008-12-05 14:24:15 UTC 
Finn, 

What's news about this file ? It still valid using digiKam 0.9.4 ?

Gilles Caulier
Comment 7 caulier.gilles 2009-05-13 11:49:18 UTC 
We need a fresh feedback here. Please use digiKam 0.10.0 for KDE4 and try again...

Gilles Caulier
Comment 8 caulier.gilles 2011-08-04 14:02:45 UTC 
No response since a long time...

Gilles Caulier
Comment 9 caulier.gilles 2015-07-02 05:05:13 UTC 
New digiKam 4.11.0 is available.

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier
Comment 10 caulier.gilles 2016-07-15 16:29:12 UTC 
With digiKam 5.0.0, this problem is not reproducible.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier