Version: 0.7.3-beta1 (using KDE 3.4.0, compiled sources) Compiler: gcc version 2.95.4 20020320 [FreeBSD] OS: FreeBSD (i386) release 4.11-STABLE Canon PowerShot A400 When i using "gphoto2 -P" to download pictures from camera everything goes ok. All pictures and movies downloads successfully. When i try to download pictures from camera using digikam often i see error message that told me that digikam could not download image. At this moment camera LED blinking. In normal operation LED blinks only if data transfer active. The only way to download pictures -- switch off camera. switch it on and reconnect from digikam. sometimes i can download 1-2 images and camera hangs. Sometimes 10-15.
try with gtkam and let us know what you see
two times i filled my SD card with shots and two times i've succefully downloaded over 200 imges without any trobles gtkam-0.1.12_3
there is fundamentally no difference between how digikam and gtkam access the camera and download pictures from it. the only difference is that digikam uses threading when doing libgphoto2 operations. i'm wondering if the threading is breaking something
can i turn on debugging to see data transeferring between PC und camera over USB? i know that gphoto has debugging options. is it in digicam? may be i be able to compare communication process in gphoto, digikam and gtkam...
Created attachment 10759 [details] patch to enable gphoto2 debug logging attached is a patch to enable debug logging for libgphoto2 within digikam. messages are spewed out to stderr, so catch them with digikam >& debug.log
no feedback. closing bug
Please reopen. This is still a problem. Version: digikam-0.7.2 (using KDE 3.4.2, compiled sources) Compiler: gcc version 2.95.4 [FreeBSD] OS: FreeBSD (i386) release 4.11-STABLE built 8/22/2005 Camera: Canon PowerShot G3 (in "normal" mode; also tested briefly in PPTP mode, which seems to have same problem) Observations: o Applied above debugging patch. o Took two pictures in 640x480 (ie. smallish, ~180KB). These downloaded with no problems. (IMG_3781, IMG_3782) o Closed camera dialog box, unplugged camera from USB port. o Then took 9 pictures in highest resolution, best quality mode. Plugged camera back in, attempted to download. o Thumbnails are displayed correctly. Attempt to download the first large (IMG_3783) picture results in "Failure to download" error. Green light on camera indicating CF card access continues flashing. A cursory glance at the debug output from the patch above suggests that the download actually does continue, but the GUI doesn't seem to know this? In previous tests, the green light on the camera eventually does stop flashing. o debug output from this session will be uploaded.
Debug output is largish (~10MB). Here's a link: http://www.crackpot.org/~jrm/digikam.debug0.txt.gz
from your debug output, the point at which at it failed is: canon/usb.c: canon_usb_dialogue: read 1 of 0x40 bytes failed! (Error reading from the port) libgphoto2/gphoto2-filesys.c: Download of 'IMG_3784.JPG' from '/DCIM/137CANON' (type 1) failed. Reason: 'OS error in camera communication' It clearly looks like a libgphoto2 (or underlying libusb) problem to me. I would recommend that you contact the gphoto2 developers to resolve the issue.
It seems like I would have triggered such a problem using gtkam or gphoto (I've used the former for the first 3780 photos or so with 0 problems). On the other hand, bug reports of this nature aren't exactly piling up for Linux. Or other cameras. Any ideas why digikam would trigger this problem, and gphoto/gtkam wouldn't?
Bug report submitted to the gphoto folks: https://sourceforge.net/tracker/index.php?func=detail&aid=1277866&group_id=8874&atid=108874
here's what i think might be a possible cause: gphoto2 and gtkam make use of libgphoto2 within the same thread and digikam uses a separate thread. for the former, when the communication with the camera is going on, every once in a while the process will use status updates (progress bar/other messages) from libgphoto2 to update the progress bar for eg. this pauses the communication with the camera for short intervals of time. in digikam, since the operation happens in a separate thread, there is no pause in communication. Maybe the protocol/camera is not able to handle that and needs occasional timeouts before continuing. (all of this is just wild speculation).