Pi Camera on Raspberry PI 4 works in terminal but not in octoprint

What is the problem?

I've just acquired a raspberry pi 4 2GB. To get it to boot properly, I installed the latest nightly (2022-01-18_2021-10-30-octopi-bullseye-armhf-lite-1.0.0). The camera is not detected by octoprint, but works with libcamera-jpeg at the command line.

What did you already try to solve it?

I logged in via a terminal and made sure that both the camera and the I2C interface were enabled with raspi-config. I then tried running raspistill, but that command was not found, so I installed it and the command then said:

ERROR: the system should be configured for the legacy camera stack

vcgencmd get_camera says:

supported=1 detected=0

After a bit of searching, I found that I should be using libcamera-jpeg, so I tried that and it worked, producing a good jpg photo which I could scp to another machine and view.

The control tab of octoprint says that the webcam stream can't be loaded. If I visit http://octopi/webcam/?action=stream, I get this message:

Given that I can take photos with the camera using libcamera-jpeg, I know that the camera is connected correctly and working.

I've tried changing the camera setting in /boot/octopi.txt from "auto" to "raspi", but that hasn't helped. I haven't changed any other settings in that file.

In case it's relevant, I've changed a few things in /boot/config.txt (beyond the settings like start_x=1 and gpu_mem=128 that raspi-config presumably adds): I've added two lines at the end:

dtoverlay=pi3-miniuart-bt
enable_uart=1

I don't think these should affect the camera, but I don't know.

Have you tried running in safe mode?

I don't know how to do that or what that means.

Systeminfo Bundle

You can download this in OctoPrint's System Information dialog ... no bundle, no support!)

octoprint-systeminfo-20220122153640.zip (28.7 KB)

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

Raspberry Pi 4 2 GB
Octopi version as per description above - latest nightly
Browser (on Windows 10) is Vivaldi
Printer will be a Prusa i3 MK3S+, but I haven't got as far as connecting it yet: the only things plugged into the raspberry pi are the camera and the (official raspberry pi) power supply. I wanted to check the camera worked properly before wiring it into the printer.

The only things I've done since first booting the raspberry pi with the octopi nightly are:

  • Changed the user password
  • Installed Vim
  • Installed python3-picamera and libraspberrypi-bin (to get raspistill for testing)
  • Installed my public keys and disabled password auth on ssh
  • Followed the octoprint wizard to do initial set up
  • Ran various command line camera tools like raspistill, vcgencmd get_camera, libcamera-jpeg etc

did you also check the picture? just to be sure that it isn't just showing static.

Yes:

In case it's helpful, I just ran libcamera-jpeg again and captured the output

pi@octopi:~ $ libcamera-jpeg -o pic.jpg
Preview window unavailable
[0:36:52.094239762] [1346]  INFO Camera camera_manager.cpp:293 libcamera v0.0.0+3156-f4070274
[0:36:52.167400666] [1346]  INFO Camera camera.cpp:937 configuring streams: (0) 1640x1232-YUV420
[0:36:52.167537868] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 3280x2464 fmt RG10 Score: 2218 (best 2218)
[0:36:52.167607756] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1920x1080 fmt RG10 Score: 2041.48 (best 2041.48)
[0:36:52.167643404] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1640x1232 fmt RG10 Score: 1500 (best 1500)
[0:36:52.167674237] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 640x480 fmt RG10 Score: 5004.81 (best 1500)
[0:36:52.167706292] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 3280x2464 fmt pRAA Score: 1718 (best 1500)
[0:36:52.167734791] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1920x1080 fmt pRAA Score: 1541.48 (best 1500)
[0:36:52.167764198] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1640x1232 fmt pRAA Score: 1000 (best 1000)
[0:36:52.167792957] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 640x480 fmt pRAA Score: 4504.81 (best 1000)
[0:36:52.167825753] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 3280x2464 fmt RGGB Score: 3218 (best 1000)
[0:36:52.167855568] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1920x1080 fmt RGGB Score: 3041.48 (best 1000)
[0:36:52.167885938] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1640x1232 fmt RGGB Score: 2500 (best 1000)
[0:36:52.167915419] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 640x480 fmt RGGB Score: 6004.81 (best 1000)
[0:36:52.168055954] [1348]  INFO RPI raspberrypi.cpp:620 Sensor: /base/soc/i2c0mux/i2c@1/imx219@10 - Selected mode: 1640x1232-pRAA
[0:36:52.193350684] [1348]  INFO RPISTREAM rpi_stream.cpp:122 No buffers available for ISP Output0
[0:36:52.193390146] [1348]  INFO RPISTREAM rpi_stream.cpp:122 No buffers available for ISP Output0
[0:36:52.193412850] [1348]  INFO RPISTREAM rpi_stream.cpp:122 No buffers available for ISP Output0
[0:36:52.270414339] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (6 left)
[0:36:52.303251130] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (5 left)
[0:36:52.337585238] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (4 left)
[0:36:52.369969071] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (3 left)
[0:36:52.403315801] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (2 left)
[0:36:52.436702678] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (1 left)
[0:36:52.471331060] [1348]  INFO RPI raspberrypi.cpp:1636 Dropping frame at the request of the IPA (0 left)
[0:36:57.312070176] [1346]  INFO Camera camera.cpp:937 configuring streams: (0) 3280x2464-YUV420
[0:36:57.312330451] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 3280x2464 fmt BG10 Score: 1500 (best 1500)
[0:36:57.312722576] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1920x1080 fmt BG10 Score: 7155.48 (best 1500)
[0:36:57.313134645] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1640x1232 fmt BG10 Score: 7244 (best 1500)
[0:36:57.313471530] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 640x480 fmt BG10 Score: 10748.8 (best 1500)
[0:36:57.313600770] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 3280x2464 fmt BA81 Score: 2500 (best 1500)
[0:36:57.313988469] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1920x1080 fmt BA81 Score: 8155.48 (best 1500)
[0:36:57.314321224] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1640x1232 fmt BA81 Score: 8244 (best 1500)
[0:36:57.314442593] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 640x480 fmt BA81 Score: 11748.8 (best 1500)
[0:36:57.314694757] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 3280x2464 fmt pBAA Score: 1000 (best 1000)
[0:36:57.314812274] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1920x1080 fmt pBAA Score: 6655.48 (best 1000)
[0:36:57.314930921] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 1640x1232 fmt pBAA Score: 6744 (best 1000)
[0:36:57.315052846] [1348]  INFO RPI raspberrypi.cpp:122 Mode: 640x480 fmt pBAA Score: 10248.8 (best 1000)
[0:36:57.316345738] [1348]  INFO RPI raspberrypi.cpp:620 Sensor: /base/soc/i2c0mux/i2c@1/imx219@10 - Selected mode: 3280x2464-pBAA
Still capture image received

/var/log/webcamd:

Starting up webcamDaemon...

--- Configuration: ----------------------------
cfg_file:      /boot/octopi.txt
camera:        raspi
usb options:   -r 640x480 -f 10
raspi options: -fps 10
http options:  -w ./www-octopi -n --listen 127.0.0.1

Explicitly set USB device:
-----------------------------------------------

Found video devices:
/dev/video0
/dev/video1
/dev/video10
/dev/video11
/dev/video12
/dev/video13
/dev/video14
/dev/video15
/dev/video16
/dev/video18
Scanning again in two minutes
Terminated

Goodbye...

lsusb

Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

It sounds like this command will only show detected if the legacy stack is enabled.

Since you know it's working, check out the output of v4l2-ctl --list-devices. It should be listed there. If so, you'll need to change octopi.txt to use a 'USB' camera, which is really misnamed, and is actually UVC or V4L camera, which is how the 'new' stack seems to be presenting the camera now.

It sounds like this command will only show detected if the legacy stack is enabled.

Since you know it's working, check out the output of v4l2-ctl --list-devices . It should be listed there. If so, you'll need to change octopi.txt to use a 'USB' camera, which is really misnamed, and is actually UVC or V4L camera, which is how the 'new' stack seems to be presenting the camera now.

I'm not sure whether it's listed there or not to be honest; does this mean anything to you?

pi@octopi:~ $ v4l2-ctl --list-devices
bcm2835-codec-decode (platform:bcm2835-codec):
        /dev/video10
        /dev/video11
        /dev/video12
        /dev/video18
        /dev/media1

bcm2835-isp (platform:bcm2835-isp):
        /dev/video13
        /dev/video14
        /dev/video15
        /dev/video16
        /dev/media0

unicam (platform:fe801000.csi):
        /dev/video0
        /dev/video1
        /dev/media2

This would be it. So setup octopi.txt as if you were using a 'USB' camera on /dev/video0.

Thanks for that. I thought I'd be more explicit than choosing /dev/video0 so I went with the one from /dev/v4l/by-path:

[snip]
lrwxrwxrwx 1 root root 12 Jan 22 17:35 platform-fe801000.csi-video-index0 -> ../../video0
[snip]

octopi.txt now has this:

### Configure which camera to use
#
# Available options are:
# - auto: tries first usb webcam, if that's not available tries raspi cam
# - usb: only tries usb webcam
# - raspi: only tries raspi cam
#
# Defaults to auto
#
camera="usb"

### Additional options to supply to MJPG Streamer for the USB camera
#
# See https://faq.octoprint.org/mjpg-streamer-config for available options
#
# Defaults to a resolution of 640x480 px and a framerate of 10 fps
#
camera_usb_options="-r 640x480 -f 10 -d /dev/v4l/by-path/platform-fe801000.csi-video-index0"

The http://octopi/webcam/?action=stream still looks the same, but /var/log/webcamd.log looks a bit different:

Starting up webcamDaemon...

--- Configuration: ----------------------------
cfg_file:      /boot/octopi.txt
camera:        usb
usb options:   -r 640x480 -f 10 -d /dev/v4l/by-path/platform-fe801000.csi-video-index0
raspi options: -fps 10
http options:  -w ./www-octopi -n --listen 127.0.0.1

Explicitly set USB device: /dev/v4l/by-path/platform-fe801000.csi-video-index0
-----------------------------------------------

Found video devices:
/dev/video0
/dev/video1
/dev/video10
/dev/video11
/dev/video12
/dev/video13
/dev/video14
/dev/video15
/dev/video16
/dev/video18
config file='/boot/octopi.txt':USB device was set in options and found in devices, starting MJPG-streamer with the configured USB video device: /dev/video0
<13>Jan 22 17:39:15 root: Starting USB webcam
Checking for VL805 (Raspberry Pi 4)...
  - It seems that you don't have VL805 (Raspberry Pi 4).
    There should be no problems with USB (a.k.a. select() timeout)
Running ./mjpg_streamer -o output_http.so -w ./www-octopi -n --listen 127.0.0.1 -i input_uvc.so -r 640x480 -f 10 -d /dev/video0
MJPG Streamer Version.: 2.0
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: 10
 i: Format............: JPEG
 i: TV-Norm...........: DEFAULT
 i: Could not obtain the requested pixelformat: MJPG , driver gave us: pRAA
    ... will try to handle this by checking against supported formats.
Init v4L2 failed !! exit fatal
 i: init_VideoIn failed
Done bringing up all configured video devices
Scanning again in two minutes

Do you have any ideas how to fix this? It feels like we're getting very close!

Thanks again

I also tried adding "-y", but that didn't help either:

Running ./mjpg_streamer -o output_http.so -w ./www-octopi -n --listen 127.0.0.1 -i input_uvc.so -r 640x480 -f 10 -y -d /dev/video0
MJPG Streamer Version.: 2.0
 i: Using V4L2 device.: /dev/video0
 i: Desired Resolution: 640 x 480
 i: Frames Per Second.: 10
 i: Format............: YUYV
 i: JPEG Quality......: 80
 i: TV-Norm...........: DEFAULT
 i: Could not obtain the requested pixelformat: YUYV , driver gave us: pRAA
    ... will try to handle this by checking against supported formats.
Init v4L2 failed !! exit fatal
 i: init_VideoIn failed

hmm. well that's something. what does v4l2-ctl -d /dev/video0 --list-formats-ext look like? and for -d /dev/video1 too?

For /dev/video0:

ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'pBAA' (10-bit Bayer BGBG/GRGR Packed)
                Size: Discrete 3280x2464
                Size: Discrete 1920x1080
                Size: Discrete 1640x1232
                Size: Discrete 640x480
        [1]: 'BG10' (10-bit Bayer BGBG/GRGR)
                Size: Discrete 3280x2464
                Size: Discrete 1920x1080
                Size: Discrete 1640x1232
                Size: Discrete 640x480
        [2]: 'BA81' (8-bit Bayer BGBG/GRGR)
                Size: Discrete 3280x2464
                Size: Discrete 1920x1080
                Size: Discrete 1640x1232
                Size: Discrete 640x480

For /dev/video1:

ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

image

That is strange. So, I guess the new stack doesn't support mjpg or even h264 through the vl42 interface.

It sounds like you can run libcamera-vid and have it serve the stream up similar to what mjpg-streamer would be doing, but it makes me wonder if it's doing the hardware encoding that the 'legacy' stack was or not.

edit: doing some googling and much of the info I'm seeing is that the new libcamera based stack isn't complete yet. At this point your options seem to be using libcamera-vid as the streamer program instead of mjpg-streamer or using the legacy stack until mjpg-streamer or ustreamer are updated to support libcamera.

I did a bit more googling this morning around the libcamera-vid vs raspistill thing and it sounds like it's related to operating system version or something (I must admit that I don't entirely understand what I'm reading a lot of the time!)

I'd gone with the nightly as the latest stable build didn't work on the raspberry pi 4 and the download page said to try a nightly if that was the case. As a last ditch attempt this morning, I went with an earlier nightly: the last one that said "buster" instead of "bullseye":

2021-11-08_2021-05-07-octopi-buster-armhf-lite-1.0.0.zip

I'm very happy to say that it worked straight away with no special configuration required. I think I need to make a mental note not to upgrade debian...

It's important information as we were looking to release a new version of OctoPi based on Bullseye.

When did you try the 'stable' build? A couple of days ago an update to that was pushed, available through the RPi imager or octoprint.org, that should have fixed the incompatibilities with the newer RPi boards to get them booting.

Yes, it's definitely related to Bullseye. I had thought that you were using that on purpose, sorry.

I knew the old mmal interface had been deprecated with Bullseye, but I'm surprised to see that the 'new' v4l interface doesn't support the same formats. I did some more research and it sounds like the move to libcamera is intended to move away from any closed source/proprietary usage where possible and that includes the GPU processing.

One article I read stated that the new stack simply 'pushes raw pixels through the GPU' where libcamera can process them once they come out. To me that sounds like encoding to MJPG/x264/etc. would all then be on the CPU. It's great to get the camera moved to an open source solution, but it sounds like it's coming at the sacrifice of CPU performance, possibly a large one.

Hi Charlie,

According to my browser log I downloaded raspberry pi imager on 18/1/2022. I can't be absolutely certain, but I imagine I downloaded the stable build the same day.

Al

That does make sense why it didn't work - the update was released on the 19/20th, after you tried it.

My Pi cam with Pi-4 stopped working after an octoprint update last week.
1.7.3 i think?

1 Like

Hi Charlie,

The problem with the one that didn't work was that it wouldn't boot at all: nothing to do with the camera: something about start4x.elf not being compatible if memory serves me correctly.

Al