New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
intermittent picamera.exc.PiCameraRuntimeError: Timed out waiting for capture to end #242
Comments
I should also note that this raspberry pi 2 is in a fairly temperature controlled evironoment. The camera is taped to a window though, but the season at the moment is fall, so the window temperature is between 15C-25C. I've tried this in two completely different physical locations (about 10km apart), and I don't think there is any kind of electromagnetic interferance messing with the camera. |
I added some try, except statements to my code. I make it retry every 5 seconds for 50 seconds after the problem happens. The problem happens all 10 times. If I restart the interpreter, the problem is resolved for another several days. It doesn't seem like a reboot is really necessary. |
I suspect this is something to do with blocked writes to the background ffmpeg/avconv process. Briefly, what goes on during capture is something like this:
Now, in the past I've come across a few conditions which caused the capture to fail to complete. That meant the Given that there's no "real" encoder being used in your case, I think there's only one of two realistic explanations:
You might want to try extending the capture timeout just to see if that makes a difference (I doubt it'll fix it outright, but it might delay the error occurring; if that's the case it would point to the second scenario). You can do so like this: import picamera
camera = picamera.PiCamera()
camera.CAPTURE_TIMEOUT = 60 # seconds
camera.capture(...) I'm not sure how you're launching the background avconv/ffmpeg process but if it's via |
I ran into these symptoms too: PiCameraRuntimeError: Timed out waiting for capture to end after a while. I'm also using PWM, and in my case this was the fix: http://raspberrypi.stackexchange.com/questions/40126/can-the-gpio-interfere-with-the-picamera-and-cause-an-error . Calling PWM's start() and stop() repeatedly was using up the per-process thread limit, which eventually blocked the camera, so switching to pwm.ChangeDutyCycle(0.0) to effectively stop PWM fixed my issue. |
I never had time to create a simple, isolated test case to prove that the ffmpeg/avconv piping is not part of the problem. I really don't think it is at all, but I'll need to write to /dev/null instead to truely prove it to you. Anyway, I did setup a second camera. That new system is also having the problem described above, but it is also having an even worse problem. Above I mentioned that I included some try/except statements and a calling bash script to catch the error and restart the interpreter when the problem happens. This lost some footage, but was at least working. With this new system, that does not always work. A complete reboot is sometimes required. Even a simple script just hangs indefinitely once the system is in this messed up state.
Control-C does not work, you have to manually kill the python process to get that console to respond again after picamera.PiCamera() is called. I'm not sure if these two problems are related or unrelated. The only difference between my new system and old are the fact that the new system uses a Raspbian Jessie image rather than a Raspbian Wheezy image. The new system also has a slightly longer camera ribbon cable installed. I'm not sure why a longer ribbon cable would cause a system screwup though. |
Hmmm ... if it's taking a reboot to fix that does vaguely imply the firmware might've gotten stuck (if it is a firmware issue there's very little I can do about that; picamera is merely a relatively thin wrapper over MMAL which in turn wraps the firmware). If it's not firmware, then you're hitting the timeout because the output doesn't have enough buffering or isn't clearing its queue fast enough (30-seconds should be more than sufficient for any YUV capture, even a full resolution one). There really isn't much else going on: in the case of unencoded captures all picamera does is setup the camera for capture, then call write() on an output in response to callbacks from the camera. The Event wait is simply there to make the capture() method synchronous. You could also try rejigging your code a bit to avoid capture() (and its Event wait) altogether by using a YUV-based video recording with a custom output that redirects frames to the ffmpeg process. I can post an example of that if you're interested? |
You're talking about using the video port? Just a little background, I'm not using the hardware video encoder because it can't handle the camera's highest spatial resolution, even at 1 frame per second (it just gives errors). Another reason I'm using ffmpeg is because I don't want h264, and I also want more control on the encoding parameters. Although h264 is better compression, it is really slow to seek videos with most players at this high spatial resolution, and with long time-lapse videos, this is needed to find the time of interest. In this case, disk space is cheap enough that I'd rather be able to seek faster. Another reason why I'm not using the video port is because the image quality was substantially lower when in video port mode. If you know of a way to do it without these limitations, I'd love to see an example. If not, I guess I'll wait a week or so until it happens again and try to use a non-picamera camera tool and see what that does before I reboot, and then report back. |
Fair enough. I'm afraid you're stuck with events then - if it's a still port capture you've got to wait for the capture to terminate, then start the next one (no continual capture on the still port, even in burst mode) hence an event (or some form of synchronization primitive) is required to wait on the callbacks to indicate the frame's ended. I still think it's probably worth exploring if the ffmpeg/avconv pipe is the issue though... |
One other change I forgot to mention about my new camera system is that I now have the no-IR camera. I don't see why that would make a difference though. I will try eliminating ffmpeg after I at least wait one more time to get it into the state where it needs a full reboot and try non-picamera camera tool first. This will take several weeks though. If it is a firmware issue, do you know who to contact, and is it something that can be updated or is it baked into a chip and would need to wait for the next pi model? |
After some time, I was able to get both (slightly different) systems described above to get into the state where a reboot is required to restore the camera's functionality. When in this state, after killing the python process that was running picamera, but before rebooting, I've tried running
and this command also hangs forever. After rebooting, both picamera and raspistill seem to work fine again. So, it seems like the problem described above that requires a reboot may be unrelated to picamera and as was suggested above, possibly a firmware issue. It's still unclear whether the other problem described above that just requires the python interpreter to be restarted is related to picamera, the potential firmware problem, or both. Is there any contact at the raspberry pi foundation that may care about this issue with the camera? Right now, the only real work around is to do a precautionary reboot (say once a week), although I really don't like this approach. I may try to reduce the capture rate on one of my systems (without implementing the precautionary reboot) and see if that has any impact on the time until the problem occurs again. |
Yup, that won't make any difference - I don't think the firmware even knows whether it's a visual / noir camera attached since it's just a filter removed.
Unfortunately, no - all work on the camera module from firmware all the way to picamera is done by volunteers. The best place to report firmware issues is generally the https://github.com/raspberrypi/firmware repo but you will need to have a minimal reproducible test case if you want them to look at it. It may also be worth including the last lines of the output of |
Thanks for the reply. I am setting up a raspberry pi 3 with a version 2 camera very soon exclusively for debugging this problem (maybe the problem will happen to be gone with the new hardware). I will test on that new hardware and also follow the advice you have just given to do more troubleshooting and submit a useful report to the firmware volunteers. |
I just got the problem to happen again on one of my systems where the reboot is required. There isn't much interesting from vcdbg log msg . Here is what I am getting from vcdbg reloc . I don't have anything plugged into the HDMI port.
|
Here is what I get after a fresh boot:
|
With picamera working:
|
I then hit Control-C to kill picamera and the python interpreter. After python is shut down I get:
|
I then changed gpu_mem to 256 in /boot/config.txt and ran picamera. The output doesn't seem to be much different than with gpu_mem=128.
|
I then changed the resolution picamera was using to be 1296x972 (was 2592x1944). The output changed a bit. The memory free increased slightly and the memory used by many of the items was reduced. I'm not sure what "blocks" are, but maybe they have a certain maximum per block and it is too close to that limit with the highest resolution that sometimes it doesn't have enough? I am going to run with this resolution for several weeks and see if it reduces the frequency of the problem.
|
I should note that these results are not from a raspberry pi 3 or the v2 camera. The v2 camera is very out of focus, so I did not use it. I did run rpi-update a few weeks ago. |
I unfortunately have still not yet been able to follow all of the troubleshooting suggestions indicated above. One thing I was able to do was reduce the spatial resolution from 2592x1944 down to 1296x972. After doing so I have had 40 days so far of continuous run time without the need for a python interpreter restart or reboot. |
"'PiCamera' object attribute 'CAPTURE_TIMEOUT' is read-only" Who did that? I was able to do long exposures with the V2. Why was this made read-only? |
@Amrosik sorry, that's my fault for adding import picamera
camera = picamera.PiCamera()
picamera.PiCamera.CAPTURE_TIMEOUT = 60
... |
I'm going to tentatively mark this upstream given there's an open firmware issue for now... |
Was there a fix for this? I have done multiple updates/upgrades but my Pi Camera v1 on a Raspberry Pi 3A+ doesn't want to capture anything. The Red light comes on and then it times out with the capture timeout error. This is my code
And this is what I get
December 2020 build of Raspbian Lite. Is there a way to force firmware overwrite? If I had to swap what do I swap, the Pi or the Camera? Update 1:
|
I'm getting the following error message intermittently: "picamera.exc.PiCameraRuntimeError: Timed out waiting for capture to end", from the command: "camera.capture(image_data, 'yuv',use_video_port=False)", where the image_data object was created with "BytesIO()".
I record an image every 1 second at the camera's maximum resolution of 2592x1944 using the command above. I have some timers and sleep statements to ensure this image capture rate. The error may happen after 18 hours, it may happen after 7 days, it may happen after 36 hours of running.
I'm using a raspberry pi 2. The image_data object is actually written to ffmpeg/avconv as standard input. So, disk write speeds are usually less than 1MB/second after the image data is compressed to a video format. I've tested write speeds of about 26MB/second with my disk on the raspberry pi 2, so I'm sure it is not a disk IO issue. I'm also sure that I have 3.6TB of free disk space. System loads are typically about 2.7 with this script and ffmpeg/avconv running, which for this quad core CPU, I don't think is very high. From what I recall, in order to maintain the capture rate of 1 image per second, I think the python script is usually delaying about 180ms. It apparently takes about 820ms for the camera to capture an image at the maximum resolution without using the video port. I haven't checked to see if using the video port to capture images resolves this intermittent issue, but I don't want to because the image quality is terrible when using the video port.
Restarting the script seems to fix the problem, although I normally just reboot the raspberry pi just so the script is relaunched again in the same way, using the /etc/rc.local file. I haven't tried any try/except statements to catch the error and retry, so I'm not sure if restarting the python interpreter is required to temporarily overcome the issue.
Any ideas on why this error may be happening?
The text was updated successfully, but these errors were encountered: