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?
### 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"
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!
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":
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.
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.
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.
OctoPrint doesn't even know that your webcam exists (it only knows about two URLs, one to embed in the UI, one to fetch stills from, that's all it has to do with cameras), an update of OctoPrint cannot influence the webcam server. So this is very likely unrelated and coincidence.
So, am I reading this thread right so far that picams won't work with mjpg-streamer on bullseye? If so, that is a major show stopper for a new OctoPi release for now.
Hi there, I installed Octoprint on a Pi4 with Pi camera Rev 1.3 about four weeks ago and it runs with 1.7.2 without any problems. That's just for info.
browser.user_agent: Mozilla/5.0 (iPad; CPU OS 15_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.1 Mobile/15E148 Safari/604.1
connectivity.connection_check: 1.1.1.1:53
connectivity.connection_ok: true
connectivity.enabled: true
connectivity.online: true
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: true
env.hardware.cores: 4
env.hardware.freq: 1500
env.hardware.ram: 1903988736
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.4
env.plugins.pi_support.octopi_version: 0.18.0
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 20.3.3
env.python.version: 3.7.3
env.python.virtualenv: true
octoprint.safe_mode: false
octoprint.version: 1.7.2
systeminfo.generator: systemapi
You are using OctoPi 0.18, which is the stable release, rather than the nightly builds being tested here. They are based on different OS versions, the camera stack has changed.
That's development work for the next version of OctoPi, based on Debian Bullseye.
OctoPrint and OctoPi are two different things. You have a completely separate problem to this thread if you don't know what that fix is for or what bullseye means.
