Cameras inconsistently get stuck on "Capturing frame #..." when tethered and triggerred using sigkill #688
Comments
|
Some additional info. It's easy to reproduce this strange behaviour. If people are trying to reproduce this behaviour, please make sure to use a non-Canon prime lens (35mm or 50mm) first. The strange behaviour with the Capturing Frame # will show up within the first 10 captures 80% of the time. Then use a Canon lens and see if it happens the same. I don't have any Canon lenses as the Sigma ART prime lens picture quality is far better than Canon's expensive prime lenses. Picture quality is the most important thing for me. |
|
i currently just have canon kit lenses for my EOS. perhaps someone else has? would be nice to have a debuglogfile, not sure if it will help though |
If you can try to duplicate with the Canon lens, it would be appreciated. I'll get you my debuglogfile from my experiments with the Sigma lens. Will send later today. Thanks. |
|
More info. I borrowed some old Canon zoom lenses and ran experiments today. Using the best long (15ft) USB3 cables (with boosters) that money can buy, I was able to get the same strange "Capturing frame #" stalling behavior on the two Canon 5DS R camera bodies. Same as with the Sigma ART lenses. Make sure you focus the lenses and run the camera and the lenses both on manual mode once you have the lenses in focus. We're using a mirror lockup setting of 1/8secs on the capture. And we're running the camera without SD cards, so we capture, rename and download the renamed image RAW file, the delete the current image RAW capture file from the camera memory, then wait for the next SIGKILL command. Same behaviour....... Within the first ten captures, it's intermittent, but both camera bodies stalled/paused on the "Capturing Frame #". Then a minute (random amount of time) later it releases, and then you may be good for another 10 or so captures, but eventually the "Capturing Frame #" stall comes back.
This never happened before the last two days, with this exact same equipment (though before I had seen the stalls with Sigma 50mm prime lenses, and that's why I was forced to only use Sigma 35mm prime lens which were stable up til two days ago). Something seems to impact the camera body on the SIGKILL as I notice sometimes the mirror will stay up. I hear the mirror come back down several seconds after you expect it to. Maybe it's the mirror staying up too long that causes this intermittent behaviour. Tomorrow we'll run these same experiments with both the SIGMA and Canon lenses with the ghoto2 debug logfile on and send the logs. But I wanted to share this Canon experiment results. Very frustrating as I was sure it was the Sigma lens vs Canon camera body issue happening, which causes other failures, but I know how to get around that issue. This failure with gphoto2 and the capture image and download tether, the intermittent behaviour is tough to understand..... It should be a very stable, repeatable process that can run for hours without a hiccup. I have seen it run in a stable repeatable manner with no problems up until two days ago. That's why I wanted to use a tether as I thought it would be easier on the Canon camera body in terms of the processing requirements. But now that I see it behave exactly the same with the intermittent stalling behaviour the same regardless of whether using the Sigma vs Canon lenses, it's back to seeing if we have an efficiency situation or code logic issue with gphoto. I noticed that others have had similar issues with the --capture image and download parameter? For example gphoto/gphoto2#143 that no one seemed to resolve. And this speed issue #367 that was raised regarding capture image and download also might be onto something, though we are using a very powerful Mac computer to run gphoto. Computing power is not an issue in our setup, other than the Canon 5DS Rs themselves, the fact we're dealing with RAW files, and the cable length (15 to 30 feet using high performance USB3 cables with boosters. Transmission power and speed via the USB3 cables does not appear to an issue.... other processes over these USB3 cables over work near instantaneously.) Note: When I time the camera shutter click/trigger to the time the RAW file is fully downloaded to the storage disk on the Mac, it's less than 2 to 2.5 seconds. That trigger shutter, capture image and download to computer process, provided it's working as it should, is extremely quick. |
|
Hi: Here's a debug logfiile that we put together. Let us know if we should put anything else together to see if we can figure out why this is happening on both of the Canon 5DS Rs with the capture and download tether and SIGKILL method. I've seen this setup work flawlessly previously for hours before, so it's got to be a specific variable that is applicable to both of these 5DS R cameras causing the "capturing frame" instability and freezing. (Debug session 1) https://drive.google.com/file/d/1NqF6jHxtFZJMNii3biEGt_F6hEusBi9G/view?usp=sharing (Debug session 2) https://drive.google.com/file/d/1aAiSlwYdkgWRt3USzBQ-vlDx8isK8Qef/view?usp=sharing Thanks for the help. Appreciated. |
|
Still no change on this. gphoto and the cameras continue to behave the some way with the tether and we get the "Capturing Frame" failure intermittently every few captures. Thanks for any suggestions on this. |
|
I figured out that using the gphoto2 --capture-image-and-download -interval 1 causes the freezing behavior on the cameras. I can recreate this anytime on our Canon EOS RDS R cameras. It seems to have something to do with the deleting of the files and needing to be awakened by the -SIGUSR1 command. --capture-tethered works perfectly. But the issue is I have to walk over to the cameras to trigger them with this --capture-tethered way of doing things.... As stable as it is, it's of no practical use to us (maybe I'm missing how to trigger the capture via a command when using --capture-tethered). What is an alternative way to set up a stable tether similar to --capture-tethered and be able to trigger the camera, then download the captured image right away to the attached computer from a gphoto or Unix/Linux command using command line like the -SIGUSR1 process? Capture-image-and-download is not available to us as it freezes all our Canon EOS RDS R cameras. Seems others have had issues with the --capture-image-and-download as well not being able to capture images in a stable manner (freezing the Canon camera in some way so that it can't function). Thanks for your help and time. Note: We are very familiar with the -capture-tethered parameter and know how stable it is. We used it for years with the EOS RDS R camera via a remote trigger/capture cable running to the cameras and programmatically controlled by relay switches. I had thought the --capture image and download parameter had finally enabled us to do away with the dedicated remote trigger cables controlled by the relay switches. I had no idea that the cameras were having issues with the --capture-image-and-download process in gphoto. Hopefully there is a way to use the proven, stable --capture-tethered parameter process and programmatically trigger a remote capture and image download via gphoto (from the computer using gphoto, similar to the remote trigger purpose the SIGUSR1 signal serves if the --capture-image-and-download was working without freezing the cameras) |
|
Would it make sense to go back to the previous version of gphoto2 ( libgphoto2 2.5.26 and gphoto2 2.5.26) to solve/fix this issue with the --capture-image-and-download ?? It was working before using capture-image-and-download, so I'm hoping going back to the previous version will solve the issue? |
|
One thing to try: Can you go to library.c and add for your EOS R line The additional flag PTPBUG_DELETE_SENDS_EVENT, like this: (if you have R5 or R6, adjust that line) |
|
Thanks. We will edit the it on the test environment and see how that helps. We have Canon 5DS R camera bodies. Not the mirrorless cameras (R5, R6). How do we write the syntax that line of code in library.c for the 5DS R camera body? Thanks for your help and time. |
|
just append this flag to the respective line of your camera |
|
I see. Thanks. Is this additional code targeted at fixing the freezing we are seeing when using --capture-image-and-download parameter? Were you able to test this new code for the 5DS R on your test setup already with the --capture-image-and-download interval -1 parameter? If just want to understand if we're testing this code setup for --capture-image-and-download internval -1 parameter for the first time on a 5DS R or not. Also, I just want to be clear on what code and what process you are asking us to edit and do (so we don't completely mess things up).
Thanks for your help and time. |
|
Before I mess with they gphoto code... I've noticed that Terminal and MacOS 11.XX may not be stable (even scrolling through the previous gphoto2 commands in Terminal there is this strange delay within Terminal all of a sudden, like it's looking for something. Usually scrolling through previous commands is lightning quick). Especially for gphoto related commands and bash scripts that utilize gphoto commands, which we use bash scripts extensively for our gphoto related apps (these apps using the bash scripts used to work perfectly, now they are almost unusable). Has anyone else noticed that Terminal behaves in an unstable manner on MacOS 11.XX? I have also seen some people complaining about about Terminal not working on MacOS 11.XX. Maybe Apple did not fix Terminal on MacOS 11 (Big Sur). I would not be surprised if this is the case. Apple has some issues these days. |
|
Something is not right (maybe it's something we've done wrong) with either Terminal on the MacOS platform, or it's gphoto2 and Terminal on the MacOS platform. To see if the issue was isolated to the iMac and MacOS 11 or not, I got out the Mac laptop that has MacOS 10.15.7 running on it. I know this Mac laptop runs perfectly. Installed gphoto2 using Homebrew which is at gphoto2 version 2.5.27 Manually set up a I'm at a loss. Gphoto was working just fine on the Macs up until about a month ago when everything associated with gphoto2 based on --capture-image-and-download on the Macs became unstable. You can see here just a couple shots in, and the whole "capture image and download" session fails.
Note: A tip I saw from someone else experiencing the same issue with --capture-image-and-download a while back said run --capture-image-and-download using sudo - which I tested out. Using sudo is more or less the same.... after a few captures, the Terminal prompt becomes brutally slow, and it's clear the camera and the Mac are not communicating... eventually the "Could not capture image" message shows up in the Terminal window. I'm wondering is gPhoto2 on MacOS is stable or not? On Linux gphoto2 behaves very differently (very stable @ v2.5.16 on Linux) with these same Canon EOS 5DS R cameras vs what I see on MacOS right now. Up until a month ago, the Linux gphoto2 performance and the MacOS gphoto2 performance were essentially equal. |
|
I got out another of the Macs with MacOS 11.5 on it. Installed everything from scratch. Made the edits to the code for the 5DS R camera, and executed the build from source procedure for libgphoto2 which seems to install as it should, but it's hard to check if it installed properly. Got to the gphoto2 build from source, but that generates the following errors. Not sure what to do at this point with the errors for "make" during the build of gphoto2 command line interface. Any suggestions to fix this are welcome. Thanks for your help and time. |
|
this is readline-devel not the right version... or something is too new? hmm. |
|
i do not have such an EOS camera, i have some "lower end" EOS ones... It is something I would like to try out, as we saw it earlier that Canon cameras got stuck due to interrupt delivery issues and this flag helped. as for stability on MacOS, so far it seems on-par with Linux... Have not heard complaints lately. |
I'm not sure what you mean on the "readline-devel" not the right version?? Sorry for not understanding. But there is obviously something wrong related to the readline program which was installed by the brew package manager on this new Mac. As you know, readline is needed to as a dependency for gphoto2. I followed these instructions here for building gphoto2
There is no popt-devel, etc for the brew package manager on MacOS (just install for popt library on brew package manager). But from reading the messages during the gphoto2 build process, popt seems OK. How do you tell if libgphoto2 is install OK? Here's what I'm getting from the ./configure output Here's what I'm getting from the "make check". There is one error that people have seen before when building gphoto2. Something to do with the readline. If we can fix this error about the "implicit declaration of function "rl_copy_text" is invalid in C99" then I believe we can get gphoto2 to build properly, and get this new code in libgphoto2 linked to gphoto2. Then it's a quick test to see if this new code in libgphoto2 fixes the issue with - Here's the config.log Thanks for your help and time. Question: Do you think it will just be easier to go back to an old version of gphoto2 managed on the Macs via the brew package manager such as gphoto2 2.5.16, etc? Building gphoto2 and libghoto2 from the source code in GitHub (GitHub clone method) is time consuming with the issues and lack of up-to-date documentation on how build and compile successfully. |
I have used Triggering the shutter remotely via capture-image-and-download using the -SIGUSR1 to trigger the cameras via USB3 was working just fine. I was actually very surprised and impressed how stable it was. I don't know whether or not the MacOS brew package manager last month updated the version to the current 2.5.27 (from a previous version of gphoto2) which is/was the cause of the issues we're now seeing with Good to hear that you are seeing the same overall gphoto2 stability on MacOS as with Linux. I would expect that to be the case with Unix based open source programs. I'm thinking somehow, something changed on gphoto2 that is impacting specifically capture-image-and-download on the Macs. But I'm at a loss what changed. And when I saw the same erratic behaviour when using |
|
Update.... The situation with the 1 gphoto2 build error related to the readline program is the same. This issue looks like it's been around for a while, but none of the suggested previous work arounds are working for me. Any useful (hopefully someone that has actually built gphoto2 from GitHub source successfully recently for their project) up-to-date info is welcome on how to get around this build error for gphoto2 related to the readline dependency. Once I get by the gphoto2 build error, I can test the suggested bug fix for libgphoto2 for the Also, I want to make clear that gphoto2 started acting strange on both our older 5D Mark 2 and our new 5DS Rs about a month ago on the Macs. We have multiple Macs that gphoto2 (libgphoto2) if I install 2.5.27 from the brew package manager on the Mac, and just connect the Mac to a Canon EOS camera via USB3 and use --capture-image-and-download --interval -1 with -SIGUSR -1, the capture process will fail almost immediately with this same strange "capturing frame" freezing behaviour. See above. Thanks for your help and time. |
|
I used a third Mac to do this test. To make sure to rule out any individual Mac being the issue. I was able to install the previous version of gphoto2 2.5.26 using homebrew, but, from what I can tell it's using the libghoto2 2.5.27 that I built from source (I am not sure how to verify that). Note that I had to do this using Homebrew with gphoto2 to get around the build error issue I was experiencing with building gphoto2 from source. See the results of a capture session I just did. I don't see much different in behaviour since we started having issues with the --capture-image-and-download function Note: I was able to duplicate this on two different Canon 5DS R cameras, just to rule out any individual camera. If it's using libgphoto2 2.5.27 built from source, then then the addition of the PTPBUG_DELETE_SENDS_EVENT did not help. The freezing on "capturing frame" still occurs intermittently. A month ago this was as stable as could be. I was surprised how stable it was. I am noticing that it may be something that is going on that is asking the camera to do something that is failing intermittently just before or during the "capturing frame #" event. If we figure that out and why it happens on the Mac and not on Linux, then we can get things back as stable as it was before. Anything you need me to try, please let me know. Now that I know how to get around the build error issues on gphoto2 using Homebrew, at least that part of things is not an obstacle anymore. I think I am able to edit the source code for libgphoto2 and build libghoto2 that successfully from what I've noticed. But it's hard to know if libgphoto2 is built and installed properly. Sorry for so many notes. Also, we did a close observation today of the behaviour of the cameras themselves when receving the virtual shutter signal from Gphoto..... and it seems We use the Canon 5DS Rs on manual mode (for the camera body) and manual mode on the lens. We don't need --capture-image-and-download to do anything other than virtually trigger the shutter. The lens is already in focus. |
|
I figured out what is causing the instability with --capture-image-and-download on these Canon 5DS Rs. Please correct me if I'm wrong. The issue has to do with for some reason on the Mac's See below. I switched the camera body to Automatic and the lens to automatic and this capture session is the result. No capture frame # freezes and no "could not capture image" events. I duplicated this on two different Macs. But capturing in automatic mode is really of no use to us. For some reason the coders had the cameras in automatic mode on their development and test bench environments, though I warned not to get to used to automatic mode as in the production system, we never capture in automatic mode, always manual for both the camera body and the lens operation. I'm not sure why any professional photography application would not use manual mode. I never anticipated anything in gPhoto requiring automatic mode, so I never made much of a fuss about the coders using it for development bench work. How do we get It's obvious having the EOS 5DS R camera body in Manual (M) and the lens in manual (M) does not work with If someone can suggest what mode to have the camera body in (preferably M) so I can set the aperture, ISO, and shutter speed to the standard 1/200 and lock those settings while using gphoto. I want to set the aperture to say f13, IS0 to 100, and shutter speed is always 1/200s for Canon. The odd time I change the aperture. But IS0 is always 100 and shutter speed is always 1/200s. Then I usually focus the lens at the start of a capture session once using Canon's Utility program and Liveview. I put the lens on AF (auto focus), focus the lens within Liveview on EOS Utility, and then move the lens to MF (manual focus) to lock the lens focus so it does not change. Then I remove the Canon Utility and don't have to touch the lens focusing again. Then I connect the camera to the Mac computer via USB3. With --capture-tethered this works just fine, but I need two cables, the USB3 to download the images from the camera to the computer, and a remote trigger cable controlled by relay switches via the N3 connector on the camera, which is silly in this day and age. I want to programmatically use --capture-image-and-download --interval -1 (or some other way to achieve a capture and download the RAW image file immediately to the Mac computer), and use the kill -SIGUSR1 as a virtual remote shutter press via USB3. But I want the autofocus part of --capture-image-and-download disabled, and I need to be able to take a capture and download very quickly, every 2 to 3 seconds (I do not need the lens to focus with every capture as it's already focused. The mirror can also stay up as it never made sense to have the mirror constantly going up and down with each capture at such a short interval). I notice people here discussing something similar about disabling the autofocus on --capture-image-and-download, but it's not the same as what we need to do. Please let me know if any further testing is needed to get this working with the cameras and lens in manual mode. Happy to test anything. |
If you are not using the interactive gphoto2 shell ( Unfortunately, I do not have (access to) a Mac to run builds on MacOS.
The specific package names differ from system to system, whether that is
Try compiling after |
Some good news. I ran the regular then I ran the suggested We are just using command line. Never even knew there was a gphoto2 --shell. Here's the result of the "make check". A lot of warnings and it's a bit confusing as some of the warnings get reported as errors. I did this on the test Mac. I have two versions of gphoto on it now. One 2.5.26 managed by Homebrew and then this version 2.5.27.1 that I built from the source code on GitHub. The key as mentioned is to run Now, I don't see any difference in performance between this version using the libphoto2 2.5.27.1 where we edited the 5DS R code with the I did some more testing with the camera and lens on manual vs auto mode this weekend. I'll have some more notes to share with everyone on that in a couple days once I'm sure of the behaviours. |
|
Hi: There is a key setting to using I can get If anyone knows of a way to prevent the lens from focusing on each signal (SIGUSR1) trigger using --capture-image-and-download --interval -1 it would be appreciated. If I we could configure gphoto (after we have focused the lens) to work like I can enable using Canon's EOS Utility where I can set the lens to "Remote Manual" capture (see below). Just a touch of the mouse triggers a full press of the shutter without attempting to re-focus the lens. And once I move the setting to "manual" in the Canon EOS Utility to achieve "Remote Manual" state, the shutter operates this way (full press, no auto refocus) until we take it off "Remote Manual". I can trigger the shutter remotely with just a slight touch of the mouse about every 2.5 seconds without causing any instability or waiting for the shutter to release and be available to press remotely again via EOS utility. The below picture shows the "Remote Manual" state via Liveview
Thanks for your help and time. |
|
Do you think this is the alternative way to achieve remote I notice the PID for this process stops after full execution of this command. We'll also need to manually increment the sequence ID of the downloaded filename, or you get the "overwrite existing" question each time. Also, no separate kill -SIGUSR1 PID needed with the below. Which makes things even simpler. I can't tell if the autofocus step is executing every time or not when using the below, but this triggers the full press of the shutter remotely and downloads the RAW image to the computer immediately. Takes about 3 to 4 seconds for the entire process through to "CAPTURECOMPLETE". As long as it's under 5 seconds, it works for us.
Here's the messaging that outputs from the above gphoto2 command: Again, I don't understand enough about how this command or the output messaging work to tell if the Autofocus step is bypassed or disabled during this remote trigger and download process. It just seems to take a very long time to execute vs when I do a remote trigger and download using the Canon EOS utility..... But maybe I'm not understanding how to do the direct full release using the gphoto2 eosremoterelease command. This is not freezing the camera or the lens (lens switch is set to AF), which is great. We just write a batch script to issue this command every 5 seconds. Though we still have to test if this command is going to be fast enough to execute consistently with 5 second intervals, while also incrementing the names of the RAW files and downloading them to the disk on the computer. Can someone that understands what is happening here, please give some expert input if the autofocus is still happening on each capture or not? Also, if there is a way to do this command I noticed others we experiencing a similar slow image file capture and download. They tried |
|
Update: When we run our remote trigger using gphoto bash script at a 7 second shutter trigger interval using the Any suggestions to be able to decrease the entire remote shutter trigger and download processing time down to 2 or 3 seconds? I may be wrong, but from what I'm seeing it looks like we need to get the remote shutter trigger capture and download processing time down below 3 seconds to operate our 5 second interval script successfully. Thanks for your help and time. |
|
Hello, I have exactly the same error with a Sony Alpha 6000. gphoto 2.5.27, camera plugged via a USB cable. The camera is in "S" program (speed). The first few shots work, then the camera gets stuck: If I turn the camera off/on, the issue is still there, which shows this is purely gphoto related. A tip on the issue: My conclusion is that the issue is indeed related to gphoto2 only (the camera works fine by itself), and when a focusing error/timeout occurs, gphoto2 can not grab anymore pictures. |
Describe the bug
We have 2 cameras that are tethered and we're using KILL SIGUSR PID# to trigger the of capture image and download the image.
We have recently noticed that either one or both cameras get stuck on "Capturing frame #.." for period of time after which the camera begins accepting trigger signals again but eventually get stuck again.
We had this working before without any issues but now we are consistently seeing the issue and easily reproducible.
Name the camera
x2 Canon EOS 5DS R
libgphoto2 and gphoto2 version
This version of gphoto2 is using the following software versions and options:
gphoto2 2.5.27
libgphoto2 2.5.27
libgphoto2_port 0.12.0
Using MacOS 11.5
To Reproduce
Steps to reproduce the behavior:
Setup tethering to both cameras and retrieve the PIDs of each of the cameras.
Every few seconds send a sigkill signal to both of the cameras.
see below for after
Capturing frame #47...The text was updated successfully, but these errors were encountered: