Open zfedoran opened 7 years ago
Might be related to these issues:
https://github.com/gphoto/libgphoto2/issues/66 https://github.com/gphoto/libgphoto2/issues/51
bvoth are unrelated i think. your camera uses the old canon driver, the cameras in the two issues above use the ptp2 driver.
Thanks! I understand, definitely not new drivers. Do you have any recommendations for where I can look? I don't mind diving into the code but I'm not sure where the issue may be.
I can confirm the exact same behavior with a 20D with gphoto 2.5.9. Was there ever a resolution to this?
Interestingly enough, it's every other image that fails to capture. It is not related to timing. I can run gphoto --wait-event-and-download=10s and quickly fire off 5 shots... 1, 3 and 5 will be captured to the filesystem. Upon a new invocation of gphoto2, the first image will fail to capture, so the even/odd failure is not reset upon a new invocation of gphoto2.
If you set camera to record RAW + JPG, gphoto2 will capture the .CR2 and .JPG from the first photo, and nothing from second capture, then .CR2 and .JPG from the third capture, and so on.
Sometimes immediately after switching the camera to RAW+JPG after being on RAW, gphoto2 seems to record just the .CR2 files, but from every capture, leading to somewhat desired behavior, but eventually it reverts to the behavior listed in the previous paragraph.
I think i might know how this happens. Lets see if I can code something up :/
Let me know if you need any logs or have code changes to test.
Ugh...
I've replicated this issue on a Pine64 2GB board as well as a RaspberryPi. It appears to be a common issue, and likely tied to the ARM platform. I'm finding complaints regarding this defect going back as far as 2013 and sadly no one has managed to fix the problem.
what I did notice is that using "--keep" will prevent the problem from manifesting itself. unfortunately, this does not help me much because i primarily am using this camera with indilib server which is using a gphoto-based driver for canon-dslr support. I don't see an option to specify the "--keep" option, so that app is broken due to this underlying issue with gphoto. :(
I'll see if I have a non-ARM SBC I can test on and attempt to replicate the issue.
The same problem happens on an intel platform (intel edison)
I suspect that it is a problem with this particular camera model and not an issue with the ARM platform.
I am 95% confident that the issue is with the image delete. The first image is grabbed, the delete happens, second image fails because something is hung up. Since second image fails and doesn't trigger a delete, the third image succeeds, and so on.
The issue is in the driver.... It detects new images currently by taking filesystem snapshots and comparing them. If the difference is more than 1 image, only the first image is returned and the rest will be silently ignored.
I need to change this logic a bit, or add new.
Understood. This does happen when creating single images (RAW only) as well. When you say "difference is more than 1 image" does that mean that the change due to the file being deleted from the previous capture operation counts as one change and the new file from the current capture counts as a second, and thus there is an issue?
The issue is in the driver.... It detects new images currently by taking filesystem snapshots and comparing them. If the difference is more than 1 image, only the first image is returned and the rest will be silently ignored.
I need to change this logic a bit, or add new.
I may have stumbled upon similar problem and here's my proposed fix. May I kindly ask you to have a look? https://github.com/indilib/indi-3rdparty/issues/151
The bugreport was about the old Canon driver, not Sony ...
I think this is more an Indi problem.
A Capture might trigger more than 1 image, so event handling should be called to handle multiple file addition events.
I'm experiencing the same issue. Is there any workaround?
Canon 70D (firmware 1.1.2) is set to capture RAW+JPG and downloading the JPG images but every second results in file not found error.
The issue is in the driver.... It detects new images currently by taking filesystem snapshots and comparing them. If the difference is more than 1 image, only the first image is returned and the rest will be silently ignored.
Is there a way to force this snapshot to be retaken?
Thank you
Same issue here, Canon EOS 20D, Intel processor.
Running gphoto2 in verbose mode, the first time it is called works fine.
This version of gphoto2 is using the following software versions and options:
gphoto2 2.5.27 gcc, popt(m), exif, cdk, aa, jpeg, readline
libgphoto2 2.5.27 standard camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0 iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, EXIF, USB, serial without locking
Detected a 'Canon:EOS 20D (normal mode)'.
New file is in location /DCIM/496CANON/IMG_9657.CR2 on the camera
Saving file as IMG_9657.CR2
Deleting file /DCIM/496CANON/IMG_9657.CR2 on the camera
The second time that it's called, it seems it's an issue with accessing the file on the camera, as it captures the image fine, but then hangs when it tries to detect the location on the new file:
This version of gphoto2 is using the following software versions and options:
gphoto2 2.5.27 gcc, popt(m), exif, cdk, aa, jpeg, readline
libgphoto2 2.5.27 standard camlibs, gcc, ltdl, EXIF
libgphoto2_port 0.12.0 iolibs: disk ptpip serial usb1 usbdiskdirect usbscsi, gcc, ltdl, EXIF, USB, serial without locking
Detected a 'Canon:EOS 20D (normal mode)'.
gphoto2 never returns from this call, so subsequent crontab calls to gphoto2 find the resource busy.
But the error it returns is actually related to the image capture. If I run gphoto2 in verbose mode and then cancel when it hangs, this is the error which I receive.
Error capturing image
ERROR: Could not capture image.
ERROR: Could not capture.
*** Error (-114: 'OS error in camera communication') ***
In fact, running gphoto2 --capture-image-and-download
immediately followed by gphoto2 -capture-image
results in the same hanging behavior. However, gphoto2 -capture-image
can be run repeatedly with no issue. So it's an issue with triggering the capture after a file has been deleted.
I've got a hacked solution which works for me. Put the following code into a bash script and call this instead of gphoto2 --capture-image-and-download
. You'll need to know the shutter speed to give adequate time for image capture and the folder in which image is being saved on the camera.
#/bin/bash
cd /path/to/directory/on/computer
FOLDERNAME=/DCIM/1000
SHUTTERSPEED=10
# Capture image
gphoto2 --capture-image --folder=$FOLDERNAME -v&
# Wait for capture, kill hanging process
sleep $SHUTTERSPEED; pkill -f gphoto2;
# Short wait to ensure process is killed
sleep 1;
# Next two lines obtains the last collected image number.
NUMBERSTRING=$( gphoto2 --num-files --folder=$FOLDERNAME | grep --only-matching :.*[[:digit:]*] )
NUMBER=${NUMBERSTRING:2}
# Obtain the image from the camera
gphoto2 --get-file=$NUMBER --filename %Y%m%dT%H%M%S.%C --folder=$FOLDERNAM
E
# Delete the image from the camera
gphoto2 --delete-file=$NUMBER --folder=$FOLDERNAME
The following command runs without issues (as far as I can tell) the first time:
gphoto2 --debug --debug-logfile=logfile2.txt --capture-image-and-download
If I try again, I hear the camera take the photo and release the shutter, but there is no response from gphoto2.
More info This is reproducible on 2 different Canon20D cameras consistently, I've re-installed raspbian and gphoto2 (dev, and stable) still no luck. The really strange thing is that this did work in the past, using the same camera and raspberry pi, under the indilib.org gphoto driver (it stopped working during an imaging session at which point I tried directly using the gphoto cli). I'm wondering if there is some weird state set on the camera's. I've factory reset both, no luck.
Attached logs
Log 1 (first image, no apparent issues) https://gist.github.com/zfedoran/00ac5034d075464125637066923305fe
Log 2 (second image, takes image, does not download) https://gist.github.com/zfedoran/64f165f553bb9b0caf8f9089c12ee065