| Summary: | camera hang up during download | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Michael Saygak <saygak> |
| Component: | Import-Gphoto2 | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | caulier.gilles |
| Priority: | NOR | ||
| Version: | 0.7.3 | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | 8.2.0 | |
| Sentry Crash Report: | |||
| Attachments: | patch to enable gphoto2 debug logging | ||
|
Description
Michael Saygak
2005-04-22 01:10:19 UTC
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). |