camera-streamer: "Cannot open device" on first attempt with libcamera (IMX708)

[Werner1303]

Description

camera-streamer consistently fails to open the libcamera device on the first connection attempt when started by crowsnest. The --camera-auto_reconnect=1 flag causes it to retry and succeed, so the stream works — but the initial error always appears in the systemd journal.

When camera-streamer is started manually (outside of crowsnest), it opens the device successfully on the first try every time.

Environment

• SBC: Raspberry Pi 4 Model B Rev 1.4
• OS: Raspbian GNU/Linux 11 (bullseye)
• Kernel: Linux 6.1.21-v8+ aarch64
• Camera: IMX708 (Raspberry Pi Camera Module 3) via CSI
• crowsnest: v4.1.17-1-g9cc3d4a
• camera-streamer: f1627aa
• libcamera: v0.0.5+83-bde9b04f

Configuration

[cam 1]
mode: camera-streamer
enable_rtsp: false
port: 8080
device: /base/soc/i2c0mux/i2c@1/imx708@1a
resolution: 1920x1080
max_fps: 10
custom_flags: --camera-options=AfMode=Manual --camera-options=LensPosition=5.26

Symptoms

Every time crowsnest starts or restarts, the systemd journal shows:

Cannot open device /base/soc/i2c0mux/i2c@1/imx708@1a, exiting.

After auto_reconnect, the device opens successfully and the stream works:

device/libcamera/device.cc: CAMERA: Device path=/base/soc/i2c0mux/i2c@1/imx708@1a opened

Reproduction

1. sudo systemctl restart crowsnest
2. journalctl -u crowsnest -n 15 → "Cannot open device" always appears
3. curl -s -o /dev/null -w "%{http_code}" http://localhost:8080/snapshot → 200 (stream works)

Investigation

Extensive testing was performed:

• Manual start of camera-streamer with identical parameters: always succeeds on first try
• Adding delays (3s, 5s) between detection phase and camera-streamer start: no effect
• Disabling list_picam_controls and list_picam_resolution (which briefly open the camera during detection): no effect
• Replacing echo | xargs with direct execution: no effect
• Replacing pipe to log_output with file redirect: error still appears in journal (not in log file), suggesting camera-streamer internally forks and the child process writes to stderr before inheriting the redirect
• Checking /dev/video* with fuser: no stale processes holding the device
• Checking libcamera-hello --list-cameras impact: does not lock the camera

The error appears to be specific to camera-streamer being started as a child process of the crowsnest bash script. It does not occur when camera-streamer is started directly from the command line, even with the exact same parameters, working directory, and pipe chain.

Expected behavior

camera-streamer should open the libcamera device on the first attempt without error, or the initial probe failure should not be logged as an error when auto_reconnect is enabled.

Workaround

The stream works reliably thanks to --camera-auto_reconnect=1. The error message is cosmetic only.

[mryel00]

Does the error message only appear in journalctl or can you see it in the log too? I at least never saw something like that in the log and maybe this indeed only appears on journalctl?

[mryel00]

I "reproduced" it, but it's different than you think.
The logs are pretty clear about the order of the events:

• line 4: Cannot open device /base/soc/i2c0mux/i2c@1/imx219@10, exiting.
• line 5: Starting camera-streamer with Device /base/soc/i2c0mux/i2c@1/imx219@10 ...
• line 9: [0:29:40.035422632] [3212] INFO Camera camera_manager.cpp:340 libcamera v0.7.0+rpt20260205
• last line: device/libcamera/device.cc: CAMERA: Device path=/base/soc/i2c0mux/i2c@1/imx219@10 opened

As you can see it first logs the error about not being able to open the camera. Then it starts the service. Now let's assume the starting service message is a bit delayed.
Then we still got line 9 with the first message of camera-streamer loading the libcamera library.

There are also no indications on camera-streamer failing to start the camera and using --camera-auto_reconnect=1 to reconnect to the camera. If you look closely, I even set it to --camera-auto_reconnect=0 in the crowsnest code.

Feb 12 01:37:42 raspberrypi crowsnest[2878]: Try to start configured Cams / Services...
Feb 12 01:37:44 raspberrypi crowsnest[2878]: INFO: Configuration of Section [cam 1] looks good. Continue ...
Feb 12 01:37:46 raspberrypi crowsnest[2878]:  ... Done!
Feb 12 01:37:48 raspberrypi crowsnest[3190]: Cannot open device /base/soc/i2c0mux/i2c@1/imx219@10, exiting.
Feb 12 01:37:48 raspberrypi crowsnest[3148]: Starting camera-streamer with Device /base/soc/i2c0mux/i2c@1/imx219@10 ...
Feb 12 01:37:48 raspberrypi crowsnest[3206]: DEBUG: camera-streamer [cam 1]: Parameters: --http-port=8080 --camera-path=/base/soc/i2c0mux/i2c@1/imx219@10 --camera-type=libcamera --camera-format=YUYV --camera-snapshot.height=1080 --camera-width=640 --camera-height=480 --camera-fps=15 --camera-auto_reconnect=0
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: util/http/http.c: ?: HTTP listening on 127.0.0.1:8080.
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: /home/mryel/crowsnest/bin/camera-streamer/camera-streamer Version:  (d4a8ea9)
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: [0:29:40.035422632] [3212]  INFO Camera camera_manager.cpp:340 libcamera v0.7.0+rpt20260205
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: [0:29:40.265362568] [3227]  INFO IPAProxy ipa_proxy.cpp:180 Using tuning file /usr/share/libcamera/ipa/rpi/vc4/imx219.json
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: [0:29:40.280536196] [3227]  INFO Camera camera_manager.cpp:223 Adding camera '/base/soc/i2c0mux/i2c@1/imx219@10' for pipeline handler rpi/vc4
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: [0:29:40.280631248] [3227]  INFO RPI vc4.cpp:445 Registered camera /base/soc/i2c0mux/i2c@1/imx219@10 to Unicam device /dev/media0 and ISP device /dev/media1
Feb 12 01:37:48 raspberrypi crowsnest[3211]: DEBUG: camera-streamer [cam 1]: device/libcamera/device.cc: CAMERA: Device path=/base/soc/i2c0mux/i2c@1/imx219@10 opened

[mryel00]

So you are right, there is something wrong here, that throws some error, but your reasoning is wrong. Also I don't see any issue with this. It doesn't lead to any problems, besides maybe delaying your camera start presumably by 1 second.

I will keep this issue open for now, but I will not invest time to fix this. If you want, you are welcome to diagnose it further and find the real culprit, and then report it here.

I will test #270 at some point, but even if it occurs there, I don't see a problem with that atm.