RPi HD Camera "hangs up" following upgrade from libcamera 0.3y to 0.5y -- Please Help!

[ldb20151]

RPi Camera Lockup with libcamera 0.5.pdf

I'm a newby; I need expert help to figure out how to diagnose/fix this problem. I've tried to resolve this on my own but am not making progress. I'm stuck!

I've been working on an Indi-AllSky camera system for over a year. As I was nearly complete, I hit this camera hangup issue and have been unable to get past it. I'm reaching out here in the hope someone will recognize the issue or at least be able to steer me closer to the answer I need. I'm pretty far over my head in this area, but I'm slowly learning. If I say something stupid, please consider the source :)

The Problem
With the latest version of licamera, my Raspberry Pi HD Camera "hangs" soon after launching the Indi-AllSky package (Git Hub, Developer Aaron Morris). The Indi-AllSky developer suggests the issue is likely with libcamera. To check, I have tried two new HD cameras and three different camera cables but these make no difference. All works great on 0.3y, but hangs up after the upgrade to 0.5y. Its very repeatable. Though the issue seems unrelated to hardware, I easily replicate the issue by can swapping between upgraded/non-upgraded software versions installed on different NMVe SSDs.

Below is an example of the error message I receive and the note on this topic I received from the Indi-AllSky developer. I'm also attaching the system support details Aaron refers to below using both libcamera 0.3y and libcamera 0.5y. I highlighted what I believe is the relevant info but am including all because I'm unsure what might be useful. I would leave the system in this configuration but I need other package upgrades in place for security and functionality the newer version brings.

v/r,
Larry B.

Message From Indi-AllSky developer Aaron Morris on GitHub
"aaronwmorris
on May 17
Maintainer
Have you compared the versions of libcamera between the working system and the system that hangs? There is nothing in indi-allsky that would cause the rpicam-still program to hang.
A Support Info for the old and new systems would show this detail."

[naushir]

Thank you for the report. This may or may not be related to another issue we are investigating: raspberrypi/rpicam-apps#799. Are you able to provide logs wihtout the Allsky application running to check this?

[ldb20151]

I'm willing to try, but as a newby I'd need guidance. I've only seen it happen with Indi-AllSky running. It seems related to high exposure settings, but I haven't conclusively proven that true. I'm trying different exposures now to see if there's a direct correlation.
The Indi-AllSky dev is looking at this again too.

I assume to get what you're asking I could run a test script like this with AllSky app offline:

#!/bin/bash
while true; do
TIMESTAMP=$(date +"%Y%m%d_%H%M%S")
echo "[$TIMESTAMP] Capturing image..." >> camera_test.log
libcamera-still -o test_$TIMESTAMP.jpg --timeout 5000 >> camera_test.log 2>&1
if [ $? -ne 0 ]; then
echo "[$TIMESTAMP] ERROR: Capture failed!" >> camera_test.log
fi
sleep 60
done

Then watch the system logs? I'm learning as I go here - anything too sophisticated and I may not be able to do it.

[EricClaeys]

@naushir,
my "Allsky" and Aaron's "indi allsky" are similar in terms of functionality, but server slightly different audiences.
I think since both indi allsky and Allsky users are having the same problem, it's very unlikely the hanging is due to our programs.
@MrNbaphoto and

rpicam-hello --version
rpicam-apps build: v1.6.0 https://github.com/raspberrypi/rpicam-apps/commit/025ca84648c9b9d74711477bf94b05bec349f53d 03-02-2025 (16:21:04)
rpicam-apps capabilites: egl:1 qt:1 drm:1 libav:1
libcamera build: v0.4.0+53-29156679

---

@ldb20151,
For consistency with what other people have run to show the problem, may I suggest running the following:

while true; do
    rpicam-still --thumb none --output 'test.jpg' --timeout 1 --nopreview --width 4056 --height 3040 --shutter 5ms --analoggain 1 --awb auto --quality 100 > /tmp/test.txt 2>&1
done

When rpicam-still hangs it will not return, so your check for if [ $? -ne 0] will never be run. Also, the above code will only produce one .jpg file; your code will produce hundreds or thousands, depending on how long it takes rpicam-still to hang.

Eric

[ldb20151]

I’ll give it a shot. I’m currently burning- in a new version of allsky to see if the signature changed. That’ll finish late tomorrow.
I appreciate the suggested code. I definitely don’t want thousands of test files. Thx!
However, I’ve noticed a strong correlation between hangup frequency of occurrence and exposure duration. Is there a way to drive rpicam-still to take long exposures? Might be more likely to catch something.
Larry

[naushir]

However, I’ve noticed a strong correlation between hangup frequency of occurrence and exposure duration. Is there a way to drive rpicam-still to take long exposures? Might be more likely to catch something. Larry

You can use the following command line parameters to setup a long exposure:

rpicam-still --framerate 0 --shutter 10s ...

and change the --shutter value as appropriate for a larger shutter speed.

[naushir]

@ldb20151 are you running on a Raspberry Pi 4 or 5?

[ldb20151]

Im running a pi5 8gb with pi HD camera.
I hope to run the above test this weekend.
-Larry

[EricClaeys]

@naushir,
What is the advantage of using --framerate 0? Should Allsky use it?

Eric

[naushir]

@naushir, What is the advantage of using --framerate 0? Should Allsky use it?

Actually I was questioning that myself. In rpicam-vid if you ask for an exposure time > 33ms, it will clip since the default framerate is 30. So you must disable fixed framerate limits with --framerate 0 in such cases.

I don't think it works the same for rpicam-still and is probably not needed there.

[ldb20151]

@naushir,

I successfully ran the attached camera stress test file. I ran this just 1hr at a time, 8 times. All successful. The test loop is very slightly modified from the suggested file to do just 1hr sessions as I was concerned about the size of the files. A sample test log file and the exact loop I used to test are attached. It seemed to function as expected -- hope my tweaks didn't defeat the purpose.

Normally, the hangup repeats several times within an hour, so I though that should catch the problem if its there. Sadly I guess not.

At this point I'm unsure what to think. Since the latest update to Indi-AllSky fixed an issue that the dev thought may have caused my problem, I think I've had only 1 hangup. That one was at max allowable exposure (120sec). Since I backed down a bit, no hangups. Time will tell. I am still seeing different but still puzzling & rather frequent messages as below, but I don't see any impact. I acknowledge the message and the system presses forward without issue.

v/r,
-larry

test.pdf

Stress Test Capture_Loop June 2025.pdf

[EricClaeys]

@ldb20151,
If you replace the >> with > in this line you don't need to worry about file size:

echo "[$(date)] Capturing image..." >> "$logfile" 

since it will recreate the file for every image.