Feedback for the latest camera-streamer based webcam stack builds (builds 2023.07.20.144556, 2023.10.09.154319) about octopi-uptodate HOT 58 OPEN

Sems like the camera-streamer is missing in my case.

https://paste.octoprint.org/Scyq0nVuqz

from octopi-uptodate.

Everything working?
No my raspi camera module 3 doesn’t work
Webcam stream not loaded

Pi model
RPi 4 Model B

used cameras
RPi Camera V3

in case of issues: related logs
https://paste.octoprint.org/f4ayWyIDqf (sorry I don’t know how to do that)

I tried :
libcamera --list-cams Result: command not found
It seems camera streamer is missing
So
Sudo apt install camera-streamer-raspi
But unable to locate package

libcamera-hello --list-cameras
no cameras available !

Next, new fresh install with OctoPi 1.0.0 with OctoPrint 1.8.6 instead of the last one (1.9.2)
=> now the camera is working !
Now trying to update to 1.9.2 and pi support ---> Still working

I tried many releases, to resume which one is working with my raspi camera V3:
OK octopi-1.0.0-1.8.7-20230504122418
OK octopi-1.0.0-1.9.0-20230523124648
Failed octopi-1.0.0-1.9.2-20230718111854
OK octopi-1.0.0-1.9.2-20230720144556

from octopi-uptodate.

And it's already rolling out.

from octopi-uptodate.

Just out of curiosity (while I download and install the new image), I thought there was a package being created for camera-streamer that could be installed/updated with apt so that libcamera updates didn't require a new image. What happened to that project?

from octopi-uptodate.

There is. This new image was needed because there was an issue in the basic image I built two days ago. The update-able package is alive and well (and used here), but since this is the first image to ship with the 0.2.5 version out of the box, I figured this merits a new feedback ticket.

from octopi-uptodate.

Hi Gina,

Thanks for the blazing fast response. I have good and possibly bad news.

• Good News: camera service is still there after doing a full upgrade
• Bad news: cameras services are now bound to localhost

All I did was change ports of libcamera and usb camera to 8081 and 8082 respectively and rebooted. Journal shows no errors and services listening in respective ports. However, netstat shows the following which explains why i cannot connect from another computer but only from rpi itself.

pi@octopi2:~ $ netstat -a --numeric-ports | grep LIST
tcp        0      0 localhost:8082          0.0.0.0:*               LISTEN
tcp        0      0 localhost:8081          0.0.0.0:*               LISTEN
tcp        0      0 localhost:5000          0.0.0.0:*               LISTEN

Snippets from journal below:

-- Boot 3e0689d38a4f4aef9df1285433eaa6c3 --
Jul 20 20:14:02 octopi2 systemd[1]: Starting camera-streamer default...
Jul 20 20:14:02 octopi2 systemd[1]: Started camera-streamer default.
Jul 20 20:14:06 octopi2 sh[686]: util/http/http.c: ?: HTTP listening on 127.0.0.1:8082.
Jul 20 20:14:06 octopi2 sh[686]: device/v4l2/device.c: CAMERA: Device path=/dev/v4l/by-id/usb-SHENZHEN_AONI_ELECTRONIC_CO.__LTD_Full_HD_webcam_20200729001-video-index0 fd=5 opened
Jul 20 20:14:06 octopi2 sh[686]: device/v4l2/device_options.c: CAMERA: The 'horizontal_flip=0' was failed to find.

-- Boot 3e0689d38a4f4aef9df1285433eaa6c3 --
Jul 20 20:13:57 octopi2 systemd[1]: Starting camera-streamer libcamera...
Jul 20 20:14:01 octopi2 sh[604]: /base/soc/i2c0mux/i2c@1/imx708@1a
Jul 20 20:14:02 octopi2 systemd[1]: Started camera-streamer libcamera.
Jul 20 20:14:06 octopi2 sh[669]: util/http/http.c: ?: HTTP listening on 127.0.0.1:8081.
Jul 20 20:14:06 octopi2 sh[669]: /usr/bin/camera-streamer Version: 0.2.5 (41d8dfd)
Jul 20 20:14:06 octopi2 sh[669]: [0:00:18.170190026] [669]  INFO Camera camera_manager.cpp:297 libcamera v0.0.5+82-2783c8d8
Jul 20 20:14:06 octopi2 sh[669]: [0:00:18.363628174] [855]  INFO RPI vc4.cpp:437 Registered camera /base/soc/i2c0mux/i2c@1/imx708@1a to Unicam device /dev/media3 and ISP device /dev/me>

I will keep looking around to see if I missed something ....

Danke,
Gaston

from octopi-uptodate.

I modified the systemd configuration file to add '--http-listen=0.0.0.0 ' and restarted the service. Cameras are now accessible from other computers since service bound to all interfaces. Not sure if this is the proper fix but I'm now unblocked. :D

Thanks,
Gaston

from octopi-uptodate.

I put a heads-up into the changes list up in the very first post for that exact reason ;)

from octopi-uptodate.

LOL. RTFM for me then! :D Impatience got the "best" of me.

All seems to be working fine. Will keep testing and report if I came across anything else. I doubt it but you never know.

Thanks,
Gaston

from octopi-uptodate.

Danke Gina for the very swift update. The update works for me on my RPi4B with Camera Module 3 noIR

from octopi-uptodate.

All the versions never worked for me with a Raspberry Pi Zero 2 W but I just tried same backup with a Pi 4B+ and it worked

from octopi-uptodate.

Can I update my way out of the this or do I have to reinstall octopi from the beginning?

The following packages have unmet dependencies:
 camera-streamer-raspi : Depends: libcamera0 (= 0~git20230707+2783c8d8-1) but 0~git20230720+bde9b04f-1 is to be installed
E: Unable to correct problems, you have held broken packages.

from octopi-uptodate.

A new camera-streamer-raspi package should be available, try installing that.

Side note, hard pinning the libcamera0 version like this is sadly necessary as libcamera0 (currently?) happily changes its ABI on version updates, pulling the rug from underneath camera-streamer's feet and making a recompilation of the latter necessary to still work. It just has happened again with this update.

from octopi-uptodate.

All the versions never worked for me with a Raspberry Pi Zero 2 W

Define "never worked". As it is, that comment sadly is utterly unhelpful.

from octopi-uptodate.

A new camera-streamer-raspi package should be available, try installing that.

I don't see it:

prusamk3mmu ~ # apt update
Hit:1 https://apt.octoprint.org/debian bullseye InRelease
Hit:2 http://raspbian.raspberrypi.org/raspbian bullseye InRelease
Hit:3 http://archive.raspberrypi.org/debian bullseye InRelease
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
prusamk3mmu ~ # apt remove camera-streamer*
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Note, selecting 'camera-streamer' for glob 'camera-streamer*'
Note, selecting 'camera-streamer-raspi' for glob 'camera-streamer*'
Note, selecting 'camera-streamer-stack' for glob 'camera-streamer*'
Package 'camera-streamer-raspi' is not installed, so not removed
Package 'camera-streamer-stack' is not installed, so not removed
Package 'camera-streamer' is not installed, so not removed
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
prusamk3mmu ~ # apt install camera-streamer-raspi
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 camera-streamer-raspi : Depends: libcamera0 (= 0~git20230707+2783c8d8-1) but 0~git20230720+bde9b04f-1 is to be installed
E: Unable to correct problems, you have held broken packages.

from octopi-uptodate.

Ooooh, libcamera apparently pulled the rug from beneath our feet YET AGAIN. FFS... on it.

from octopi-uptodate.

New camera-streamer-raspi package now built and pushed, and also another day spent on improving automating things so that stuff like this in the future happens semi-automatically (final PR for package addition ton the repo needs to be merged manually) on every libcamera0 update detected on the RPi repo.

from octopi-uptodate.

Thank you very much for your effort!
A simple apt install camera-streamer-raspi was enough to get it working again. Now I can again watch live how the MK4 runs out of filament and breaks my prints. 😒😂

from octopi-uptodate.

me with a Raspberry Pi Zero 2 W
Define "never worked". As

sorry I forgot to say that the camera stream never loaded on the PiZero2W, I had a lot of random reboot too

When using libcamera-hello, there was an error about the ressource already used

from octopi-uptodate.

I test against RPi3b, which is pretty much the same CPU, albeit in a different form factor. Not sure what you are running into there, everything green over here and I can also see at least 81 instances on an RPiZero2 running one of the images with the new camera build in the anonymous usage tracking data.

Random reboot sounds like insufficient power or some other hardware issue. libcamera-hello not being able to access the camera when the stream is already running is to be expected.

from octopi-uptodate.

Hi,
no luck with fresh install ( Version 1.9.2 ) an AZDeliver Raspberry Cam v1.3.

libcamera --list-cams

Available cameras
-----------------
0 : ov5647 [2592x1944] (/base/soc/i2c0mux/i2c@1/ov5647@36)
    Modes: 'SGBRG10_CSI2P' : 640x480 [58.92 fps - (16, 0)/2560x1920 crop]
                             1296x972 [43.25 fps - (0, 0)/2592x1944 crop]
                             1920x1080 [30.62 fps - (348, 434)/1928x1080 crop]
                             2592x1944 [15.63 fps - (0, 0)/2592x1944 crop]

system log

Jul 26 14:57:37 octi sh[1406]: [0:22:10.182179708] [1424] #033[1;33m WARN #033[1;37mV4L2 #033[1;34mv4l2_videodevice.cpp:2007 #033[0;32m/dev/video0[23:cap]: #033[0mDequeue timer of 1000000.00us has expired!$
Jul 26 14:57:37 octi sh[1406]: [0:22:10.182389549] [1424] #033[1;31mERROR #033[1;37mRPI #033[1;34mpipeline_base.cpp:1333 #033[0mCamera frontend has timed out!$
Jul 26 14:57:37 octi sh[1406]: [0:22:10.182459132] [1424] #033[1;31mERROR #033[1;37mRPI #033[1;34mpipeline_base.cpp:1334 #033[0mPlease check that your camera sensor connector is attached securely.$
Jul 26 14:57:37 octi sh[1406]: [0:22:10.182524964] [1424] #033[1;31mERROR #033[1;37mRPI #033[1;34mpipeline_base.cpp:1335 #033[0mAlternatively, try another cable and/or sensor.

libcamera-hello

Made DRM preview window
[0:52:21.555484026] [1445]  INFO Camera camera_manager.cpp:297 libcamera v0.0.5+83-bde9b04f
[0:52:21.597288004] [1446]  INFO RPI vc4.cpp:437 Registered camera /base/soc/i2c0mux/i2c@1/ov5647@36 to Unicam device /dev/media0 and ISP device /dev/media2
[0:52:21.597395555] [1446]  INFO RPI pipeline_base.cpp:1101 Using configuration file '/usr/share/libcamera/pipeline/rpi/vc4/rpi_apps.yaml'
[0:52:21.598568671] [1445]  INFO Camera camera.cpp:1033 configuring streams: (0) 1296x972-YUV420
[0:52:21.599241269] [1446]  INFO RPI vc4.cpp:565 Sensor: /base/soc/i2c0mux/i2c@1/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - Selected unicam format: 1296x972-pGAA
[0:52:21.801866263] [1446]  INFO V4L2 v4l2_videodevice.cpp:1820 /dev/video0[13:cap]: Zero sequence expected for first frame (got 2)
[0:52:22.802831335] [1446]  WARN V4L2 v4l2_videodevice.cpp:2007 /dev/video0[13:cap]: Dequeue timer of 1000000.00us has expired!
[0:52:22.803041802] [1446] ERROR RPI pipeline_base.cpp:1333 Camera frontend has timed out!
[0:52:22.803118833] [1446] ERROR RPI pipeline_base.cpp:1334 Please check that your camera sensor connector is attached securely.
[0:52:22.803199613] [1446] ERROR RPI pipeline_base.cpp:1335 Alternatively, try another cable and/or sensor.

But the Camera works with stable Octopi release.

Any hints?

from octopi-uptodate.

I noticed a small problem with camera-streamer.
When I boot up my pi and access octoprint web interface at least once (so it loads the camera-streamer stream) everything works perfectly fine. (And keeps working, no matter for how long I'm not accessing the camera-streamer stream)

But when I boot up and not open the web interface for some time (it's reproduceable 100% of the time when I wait at least 60min.) and then load the web interface, I don't get any stream from camera-streamer.
Opening "/webcam/stream" shows the text "Server Error".
Opening "/webcam/" works, "/webcam/status" shows the expected json and "/webcam/control" shows the control interface.

"systemctl status camera-streamer" reports the service as active.

Logs: https://paste.octoprint.org/OYXd3AsGW5 (The entries after "Jul 28 23:56:32" are the ones when it fails)
Cam: 'ov5647' on port 0
System: Raspberry Pi 4 Model B Rev 1.1 - 11 (bullseye) - Linux octopi 6.1.21-v7l+ #1642 SMP Mon Apr 3 17:22:30 BST 2023 armv7l GNU/Linux

This also happened before the recent libcamera0 & camera-streamer-raspi updates.

Restarting the camera-streamer service fixes the problem. ("systemctl restart camera-streamer")

from octopi-uptodate.

@sarusani since that looks like it's rather an internal issue with camera-streamer than something related to the image including it, could you please report this on the camera-streamer repo?

https://github.com/ayufan/camera-streamer

from octopi-uptodate.

Sure, I'll do. 👍
Wasn't sure if it's camera streamer or a problem with the service.

ayufan/camera-streamer#90

from octopi-uptodate.

I noticed a small problem with camera-streamer. When I boot up my pi and access octoprint web interface at least once (so it loads the camera-streamer stream) everything works perfectly fine. (And keeps working, no matter for how long I'm not accessing the camera-streamer stream)

But when I boot up and not open the web interface for some time (it's reproduceable 100% of the time when I wait at least 60min.) and then load the web interface, I don't get any stream from camera-streamer. Opening "/webcam/stream" shows the text "Server Error". Opening "/webcam/" works, "/webcam/status" shows the expected json and "/webcam/control" shows the control interface.

"systemctl status camera-streamer" reports the service as active.

Logs: paste.octoprint.org/OYXd3AsGW5 (The entries after "Jul 28 23:56:32" are the ones when it fails) Cam: 'ov5647' on port 0 System: Raspberry Pi 4 Model B Rev 1.1 - 11 (bullseye) - Linux octopi 6.1.21-v7l+ #1642 SMP Mon Apr 3 17:22:30 BST 2023 armv7l GNU/Linux

This also happened before the recent libcamera0 & camera-streamer-raspi updates.

Restarting the camera-streamer service fixes the problem. ("systemctl restart camera-streamer")

Perhaps it's related to my issue at ayufan/camera-streamer#88?

from octopi-uptodate.

did you consider switching to the actual video stream?
Camera-streamer has both /video and /stream: /video is an h.264-stream, so much more efficient that the /stream, which is MJPEG (like the old stack). Octopi currently continues to use the mjpeg-stream, while it could have the much more efficient h.264 stream for nearly free.
something has to be changed in the html for that, it's not quite as simple as replacing the action=stream with video in the url.

from octopi-uptodate.

did you consider switching to the actual video stream? Camera-streamer has both /video and /stream: /video is an h.264-stream, so much more efficient that the /stream, which is MJPEG (like the old stack). Octopi currently continues to use the mjpeg-stream, while it could have the much more efficient h.264 stream for nearly free. something has to be changed in the html for that, it's not quite as simple as replacing the action=stream with video in the url.

That's the whole point of this new stack. It's no longer using the MJPEG stream (only as a fallback). It's using the way more efficient WebRTC stream. 😃 (You can look at WebRTC as a browser friendly way to transport the h264)

from octopi-uptodate.

This image doesn't view the h264 stream out of the box, it will still use the mjpg stream. I created https://github.com/cp2004/OctoPrint-CameraStreamer-Control to view those streams. It's incomplete, but it works and has a reasonable number of users despite not being published yet...

from octopi-uptodate.

@sarusani, The command "systemctl restart camera-streamer" needs privilege so it should be "sudo systemctl restart camera-streamer". Unfortunately, that doesn't work very well if added to the OctoPrint UI (through config.yaml). Using "sudo service camera-streamer restart" works better (thanks @jneilliii).

from octopi-uptodate.

@sarusani, The command "systemctl restart camera-streamer" needs privilege so it should be "sudo systemctl restart camera-streamer". Unfortunately, that doesn't work very well if added to the OctoPrint UI (through config.yaml). Using "sudo service camera-streamer restart" works better (thanks @jneilliii).

The service command is very old and it would be better (and more future proof!) to use systemctl (aka systemd). I fixed this very easy for myself by adding the following sudo config which allows the user pi to run explicatively those two commands:

# cat /etc/sudoers.d/camera-streamer-control
pi ALL=NOPASSWD: /bin/systemctl start camera-streamer.service
pi ALL=NOPASSWD: /bin/systemctl stop camera-streamer.service

To ensure that you don't break the sudo config if you are not sure about it, you can verify your config like this:

# /usr/sbin/visudo -cf /etc/sudoers.d/camera-streamer-control
/etc/sudoers.d/camera-streamer-control: parsed OK

from octopi-uptodate.

I'm actually using this in config.yaml and it works perfectly fine (pi user is in the passwordless sudo list):

system:
  actions:
  - action: restartwebcam
    command: sudo systemctl restart camera-streamer
    confirm: false
    name: Restart Webcam

But it still would be better if the service wouldn't break in the first place 😉

from octopi-uptodate.

I'm actually using this in config.yaml and it works perfectly fine (pi user is in the passwordless sudo list):

system:
  actions:
  - action: restartwebcam
    command: sudo systemctl restart camera-streamer
    confirm: false
    name: Restart Webcam

But it still would be better if the service wouldn't break in the first place 😉

Absolutely! I have another use case. Since I sometimes print orders, I stream the feed (trough a mjpeg-proxy container!) to the internet. But I only want the feed running during prints, since uploading two 720p video streams (I use two printers) 24/7 is REALLY BAD for my upload. 😂 So my config for this use case looks like this:

events:
  enabled: true
  subscriptions:
  - command: sleep 30; sudo /bin/systemctl stop camera-streamer.service
    debug: false
    enabled: true
    event: PrintCancelled
    name: sleep 30; sudo /bin/systemctl stop camera-streamer.service
    type: system
  - command: sleep 30; sudo /bin/systemctl stop camera-streamer.service
    debug: false
    enabled: true
    event: PrintDone
    name: sleep 30; sudo /bin/systemctl stop camera-streamer.service
    type: system
  - command: sleep 30; sudo /bin/systemctl stop camera-streamer.service
    debug: false
    enabled: true
    event: PrintFailed
    name: sleep 30; sudo /bin/systemctl stop camera-streamer.service
    type: system
  - command: sudo /bin/systemctl start camera-streamer.service
    debug: false
    enabled: true
    event: PrintStarted
    name: sudo /bin/systemctl start camera-streamer.service
    type: system

But all this has nothing to do with this issue. 😉

from octopi-uptodate.

Everything working?
Most everything working, but RPi Camera v2 errors after some time

Pi model
RPi 4 Model B

used cameras
RPi Camera V2,1
Logitech Webcam C525

in case of issues: related logs
https://paste.octoprint.org/f4ayWyIDqf

If I'm missing anything, please let me know. My issue seems to be in the same vain as @sarusani's, so if I need to post over in libcamera, I can certainly do that. However, it seems to have the opposite behavior for me. As long as I don't access the octoprint web interface (or view the stream on OctoApp), everything works fine. However, if I do open it, I will get a video feed from my RPi camera, but then it will stop. How long it takes before it quits working varies. However, once it does stop, trying to access the stream gives "server error."
systemctl status camera-streamer reports it as active and restarting the service fixes the problem (until it errors out again).

Throughout all of this, my other camera works just fine.

from octopi-uptodate.

Edit 08/25 I just ran an apt-get update and apt-get full-upgrade and there was a set of new camera-related packages that seem to have mostly solved the problem. I can get the stream to work now, but I have to reset it every couple of minutes.

Everything working?
I'm unable to get the camera stream to load. As mentioned in a previous issue, I can access /webcam/ but none of the streams or snapshots work. My camera also times out when running libcamera-hello, but it is detected using libcamera-hello --list-cameras. I don't know if that is related. I always had issues with my camera on 0.18, but I got the camera working briefly the other day. After it stopped working again, I flashed the newest version of OctoPi to see if that would help.

Available cameras
-----------------
0 : imx219 [3280x2464] (/base/soc/i2c0mux/i2c@1/imx219@10)
    Modes: 'SRGGB10_CSI2P' : 640x480 [30.00 fps - (0, 0)/0x0 crop]
                             1640x1232 [30.00 fps - (0, 0)/0x0 crop]
                             1920x1080 [30.00 fps - (0, 0)/0x0 crop]
                             3280x2464 [30.00 fps - (0, 0)/0x0 crop]
           'SRGGB8' : 640x480 [30.00 fps - (0, 0)/0x0 crop]
                      1640x1232 [30.00 fps - (0, 0)/0x0 crop]
                      1920x1080 [30.00 fps - (0, 0)/0x0 crop]
                      3280x2464 [30.00 fps - (0, 0)/0x0 crop]

Pi model
RPi 4 Model B

used cameras
RPi Camera V2

in case of issues: related logs
https://paste.octoprint.org/KZr26ROesO

from octopi-uptodate.

Why two versions 1.0.0/1.9.2 ?
octopi-1.0.0-1.9.2-20230720144556
octopi-1.0.0-1.9.2-20230718111854
What are the differences ?

The one labeled latest (854 on 18 jul) is not working for me, the other one (556) on 20 jul is working

from octopi-uptodate.

Why two versions 1.0.0/1.9.2 ?

The first is the OctoPi version (operating system on the Raspberry Pi) and the second is the OctoPrint version (Python application that can be installed on many different operating systems). The number at the end is the date and time the image was created.

The first post contains the release notes which document the changes made in the "...556" version and as you have discovered, one of those changes directly affects you.

from octopi-uptodate.

Why two versions 1.0.0/1.9.2 ?
The first post contains the release notes which document the changes made in the "...556" version and as you have discovered, one of those changes directly affects you.

Thank you ! Now I understand why I lost a lot of time :-)
But why 556 is note the latest release on the code page ? Sure, I wouldn't have wasted my time with a buggy version

from octopi-uptodate.

Everything working?
Yes, with some additional configurations

Pi model
Raspberry Pi 4 Model B 8GB RAM

Used Camera
Arducam 16MP Autofocus IMX-519 Camera

Connecting the camera and using the provided image in the thread worked with the camera (feed shows up on the dashboard) but it was not able to autofocus. Checking the logs and testing with libcamera-still -t 0 --autofocus-mode continuous revealed that it was not able to set the autofocus setting. Turns out to use the autofocus function on this Arducam camera, you need to install the specific version of libcamera that is provided by Arducam, which when installing will remove another essential binary for camera-streamer to work.

In the end, I managed to work around it by doing the following:

1. Install the provided image in this thread normally
2. Copy the bin file for camera-streamer to somewhere else eg. sudo cp -r /bin/camera-streamer /bin/csbackup
3. Follow the instructions on Arducam website to install their version of libcamera here
4. After installation camera-streamer will be removed so copy it back using sudo cp -r /bin/csbackup /bin/camera-streamer

Hope this helps whoever else that may be having errors with autofocus Arducams!

Sems like the camera-streamer is missing in my case.

https://paste.octoprint.org/Scyq0nVuqz

@MrUpStry This might help you as the error message I got when debugging with that camera-streamer was missing as well.

from octopi-uptodate.

Howdy,

I installed the New Camera Stack image yesterday and my camera was autodetected and working pretty much out of the box. The power surged today during a storm, and since then I get a "webcam is not configured" error only through the UI. Obico still sees the stream, and I can view the stream directly at /webcam/?action=stream.

Everything working?
No, camera is not detected on the web UI though it is accessible from eg ip address. It was working fine through this morning, can't think of anything that changed, but a storm caused everything in my house to power cycle.

Pi Model
Raspberry Pi 3B+

Used Camera
RPi V3 module (I see from reading through previous posts that this camera seems to cause issues, but have not been able to isolate what exactly is going on in my case)

Troubleshooting Outputs/Configs
journalctl -u camera-streamer* | pb gives a "request entity too large"
`

 journalctl -u camera-streamer\* | pb
https://paste.octoprint.org/<!doctype html>
<html lang=en>
<title>413 Request Entity Too Large</title>
<h1>Request Entity Too Large</h1>
<p>The data value transmitted exceeds the capacity limit.</p>

However journalctl -u camera-streamer doesn't show any issues, restarting the camera-streamer service has no effect

Sep 22 12:53:53 3dprint systemd[1]: Starting camera-streamer...
Sep 22 12:53:53 3dprint camera-streamer-control[545]: Running start for camera-streamer-libcamera.service...
Sep 22 12:53:53 3dprint camera-streamer-control[545]: ... done.
Sep 22 12:53:53 3dprint camera-streamer-control[545]: Adding path unit for autolaunch of camera-streamer-usb@default
Sep 22 12:53:54 3dprint camera-streamer-control[545]: Running start for camera-streamer-usb-default.path...
Sep 22 12:53:55 3dprint camera-streamer-control[545]: ... done.
Sep 22 12:53:55 3dprint systemd[1]: Finished camera-streamer.
Sep 22 13:10:30 3dprint systemd[1]: Stopping camera-streamer...
Sep 22 13:10:30 3dprint camera-streamer-control[1482]: Running stop for camera-streamer-libcamera.service...

libcamera-hello --list shows the camera

libcamera-hello --list
Available cameras
-----------------
0 : imx708 [4608x2592] (/base/soc/i2c0mux/i2c@1/imx708@1a)
    Modes: 'SBGGR10_CSI2P' : 1536x864 [30.00 fps - (0, 0)/0x0 crop]
                             2304x1296 [30.00 fps - (0, 0)/0x0 crop]
                             4608x2592 [30.00 fps - (0, 0)/0x0 crop]

Here is the libcamera.conf file, I tried differed width/height resolutions, changing fps, and adding the --camera-nbufs=3 based on a previous issue on this thread.

I also tried adding a dtoverlay=imx708 to the config.txt file to no avail.

PORT=8080

WIDTH=1920
HEIGHT=1080

# The height to use for the video stream. Defaults to 720.
VIDEO_HEIGHT=720

# The height to use for the snapshots. Defaults to 1080.
SNAPSHOT_HEIGHT=1080

# The framerate to set on the camera. Defaults to 15fps.
FRAMERATE=15

# Additional options. By default enables continuous auto focus (if possible).
OPTIONS='--camera-options="AfMode=2" --camera-options="AfRange=2" --camera-nbufs=3'

I'm trying to think of what else could be useful... I disabled obico to see if that was an issue, no dice there. I didn't see anything relevant in the octoprint logs. I'm at a loss, not sure why the stream isn't being picked up when it's clearly there when I use the IP address. Perhaps it's something obvious I'm missing but I'm a few hours in to troubleshooting and not sure what else to try.

Thanks for any help! When the Rpi cam 3 was working it was fantastic, night and day better than the usb webcam I had been using.

Edit - really not sure what's happening now but the webcam is working again. Somehow it's working through the classic webcam plugin which I thought the point of the new camera stack was that it didn't work through the classic camera mode? Perhaps I misinterpreted that. I tried disabling/clearing the data on any camera related apps but my system kept re-enabling the plugins each time I rebooted the system so it was impossible to get it back to a "neutral" plugin-less state. I suspect that some of the plugins are conflicting with each other which doesn't surprise me if they're not actually being disabled/uninstalled properly.
But all's well that ends well I suppose, so here's hoping the camera feed keeps up!
Cheers,
D

from octopi-uptodate.

FYI, for now I've considered the crashes with "stale stream" in the log that many of you have observed a blocker for the general roll-out of this stack. Upstream ticket is here: ayufan/camera-streamer#94, we'll have to wait for action there.

from octopi-uptodate.

Please, please find a way to identify the camera-streamer version as OctoPi 1.0.1 (or something) because people keep posting that they are running OctoPi 1.0.0 without adding the build identifier and it requires another back and forth exchange to figure out how to help them.

from octopi-uptodate.

I cannot in good conscience change the version number as that would interfere with potential versioning of the base image and cause even a more ton of confusion considering the other image without the new cam stack.

What I can do is put a suffix "cam" on the version identifier in the web interface (e.g. "OctoPi* 1.0.0cam (build 2023.10.09.154319)") and also make sure the bundle viewer makes it more visible.

from octopi-uptodate.

I believe this is an acceptable solution, thanks!

from octopi-uptodate.

A simple apt install camera-streamer-raspi was enough to get it working again.

Does this mean it is possible to install the camera streamer on a different machine to OctoPrint? Should be possible as the interface seems to be entirely through URL. Could I, for example, install the streamer and camera on an up-to-date Pi OS 64-bit and run the standard Docker Image of OctoPrint on top of this? If this would work, would it be possible to add some documentation for this scenario (which would be the same as running the two components on different hardware platforms).

from octopi-uptodate.

You can install camera-streamer on a variety of platforms, wherever you like. The 'camera stack' that the OctoPi image comes with (the control scripts and using /boot/camera-streamer/*.conf files), alongside the precompiled binaries may only work on the OctoPi image - they are technically maintained as a separate package to make it updatable, but not necessarily cross platform.

You can use the docker version of OctoPrint (not OctoPi, this is specifically an OS image) and install camera-streamer yourself, or try and trace the steps used in the OctoPi image if you wanted an exact clone, using the scripts & apt.octoprint.org binaries.

from octopi-uptodate.

You can use the docker version of Octo_Print_ (not OctoPi, this is specifically an OS image) and install camera-streamer yourself.

Made some corrections. So 'camera-streamer-raspi' is the OctoPi 'camera stack' maintained by the OctoPrint project? I guess this will only work on Bullseye, so I cannot use it to update Buster based OctoPi or OctoPrint Docker images to work with Camera Module 3?

from octopi-uptodate.

camera-streamer-raspi is actually the binary of camera-streamer, compiled for the Pi - you can install this yourself by picking the right binary direct from that project's releases, but it will only work through apt if you have apt.octoprint.org, which is on the OctoPi image. camera-streamer-stack is the set of scripts directly maintained in the OctoPrint project.

Buster based images are too old to support the Pi Cam V3 (and camera-streamer), Bullseye is the minimum.

from octopi-uptodate.

Everything working?
After some headache and tinkering yes.

Pi model
RPi 4 Model B

used cameras
3DO Nozzle Camera Kit - Sony 4K

My first problem was with the wifi setup. On my first attempt I couldn't manage to connect my Pi to my Wifi. Connection via ethernet worked but I didn't want to run an extra cable to the pi. I also found that my wifi infromation from Raspberry Pi Imager was nowhere to be seen in /boot/octopi-wpa-supplicant.txt file and I couldn't figure out how to make it connect to the wifi. So I started over and reflashed the SD chard again.
As it turned out I initially made a typo in my wifi password in Raspberry Pi Imager that I discovered on my second attempt to flash. After correcting the typo the Pi connected to the wifi. But still /boot/octopi-wpa-supplicant.txt did not contain any wifi information and all "network=" sections in the file were still commented out. So I did a lot of digging and googling to figure out what went wrong.
As it turns out the wifi credentials were filled in correctly into /etc/wpa_supplicant/wpa_supplicant.conf so wifi eventually worked. The problem was that /etc/wpa_supplicant/wpa_supplicant.conf was an actual file while it should have been a link to /boot/octopi-wpa-supplicant.txt. So I manually copied over the data to /boot/octopi-wpa-supplicant.txt, removed /etc/wpa_supplicant/wpa_supplicant.conf and recreated it as a link to /boot/octopi-wpa-supplicant.txt.

I can't really say how all this happened. I eventually found some info that setting the wifi country in raspi-config can cause such problems and I definitively set the wifi country in raspi-config on my first unsuccessful attempt to set up wifi. But after re-flashing the SD again with the correct wifi password I can't recollect doing that.
So my suspicion is that OctoPi-UpToDate creates the file /etc/wpa_supplicant/wpa_supplicant.conf and fills in the credentials from Raspberry Pi Imager rather than filling it into /boot/octopi-wpa-supplicant.txt and linking that file to /etc/wpa_supplicant.

My second headache was getting the camera to work. It was properly listed in lsusb but i constantly got a 'server error' when trying to access it. I can't fully recollec what I did but I remember chasing after that remark to set '--http-listen=0.0.0.0' as well but that didn't help either. At least in my currently working configuration I can't find that option anymore.
As it turned out my camera did not support the default 'FORMAT=YUYV' so after changing that to 'FORMAT=JPEG' I finally got the webcam working.
I'm still not that deep into linux and couldn't find anyhting obvious in '/var/log' either. Eventually I found out that running journalctl -u camera-streamer should give me more information, but eve that didn't give me any obvious indication that my webcam failed due to the not supported 'FORMAT=YUYV'. I'm not sure if there's anyhting you could do about that to improve but maybe a hint in the documentation might help others facing the same problem.

But now everything works so far and I'm happy with the new camera-streamer stack for OctoPrint.

from octopi-uptodate.

@ryantang30 - Hello! Thanks for your post about autofocus on the Arducam IMX-519; I have been wondering about that feature. I followed your instructions and can see the camera feed in OctoPrint, but I get errors with libcamera-still: "Unable to set controls: Device or resource busy" and "Pipeline handler in use by another process." Do you have any idea what's wrong?

from octopi-uptodate.

Sound like the streamer is still running, the camera can't be used by more than one process. So you have to stop the streamer before you can use libcamera-still.

from octopi-uptodate.

@cp2004 - That makes sense. Thanks! Dumb question: How do I stop the streamer?

from octopi-uptodate.

sudo service camera-streamer stop

from octopi-uptodate.

Thank you, @jneilliii

from octopi-uptodate.

Just one stupid question: the Raspberry Pi Cam v1 & v2 should still be supported by this stack, isn't it?

from octopi-uptodate.

@ascheucher
Yes. I'm currently using a v2 and it works fine.

from octopi-uptodate.

@ascheucher Yes. I'm currently using a v2 and it works fine.

Thanks. Did a reinstall on two RPis (4&3b) with v1 clone cameras. They both can’t detect the cam anymore. Worked for years before with the classic cam stack. Also tried to switch to shorter ribbon cables and another original v1 cam.

On one I applied a backup from octopi 0.17 /octoprint 1.9.3. then it detected the camera with libcamera-hello —list-cameras, but didn’t start the streamer. I assumed the applied backup destroyed something. Hence, I deleted the SD and tried with a newly flashed cam stack version, but then it didn’t detect the cam anymore at all. As only the v3 is mentioned in all the posts, blog posts and questions, I started to question the support of older cams

Running out of ideas.

from octopi-uptodate.

I noticed that camera-streamer doesn't stop streaming the video when I close chrome or the chrome tab, but it stops properly if I change tabs within OctoPrint.

How to reproduce:
check CPU usage with top

1. switch from control tab to any other tab that isn't showing the cam (ex. temp)
   -> camera-streamer CPU usage falls bellow 1%
2. switch back to control tab
   -> camer-streamer usage goes back up (depending on the settings, usually somewhere between 5% - 20%)
3. close chrome tab or browser
   -> camera-streamer CPU usage stays up. Only way to bring it down is to restart the camera-streamer service.

I assume that whatever code is run between switching the OctoPrint tabs should also been executed on "visibilitychange".

Not sure if that's something in OctoPrint or if I should report this on the Camera Streamer Control plugin...

Edit:
I figured it out. It's a problem with the plugin.
It's using a 5 seconds timeout before it stops the stream. So if the tab/browser is closed it's never executed.

from octopi-uptodate.

FYI, the key used for signing the packages on apt.octoprint.org will expire on Friday. I've spent some time the past months trying to figure out a way to create a new signing sub key that will be recognized by apt with the current public key for apt.octoprint.org, but sadly there seems to be no way apart from re-importing the new public key.

I've already published the new public key that can validate both the old soon-to-expire signing key and the new one that won't expire until 2034, and you can re-import it on the command line like this:

curl -s --compressed "https://apt.octoprint.org/octoprint.gpg.key" | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/octoprint.gpg > /dev/null
sudo apt update

That's also documented on https://apt.octoprint.org and in #14.

For now you'll still be able to apt update and apt install from apt.octoprint.org without this, but I'll rotate the signing key on Thursday and from then on you'll get an error when apt reads the packages list off apt.octoprint.org unless the above steps have been done.

from octopi-uptodate.