Feedback for the latest camera-streamer based webcam stack build (20230328122604)

[foosel]

👉 Latest image & feedback ticket can be found here 👈

---

This is a ticket to collect feedback on the latest build of the new camera stack (some background on that here) for OctoPi-UpToDate, 20230328122604. Find the image here: https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.7-20230328122604

Changes compared to the previous version:

• camera-streamer is now built in another repository, packaged as a deb and then published on https://apt.octoprint.org. The image build now installs from that apt repo and thus makes it possible to update camera-streamer to a later version as necessary, e.g. for bug fixes or if new backwards incompatible libcamera versions are being released.
• latest version of camera-streamer, arguments switched from - to -- accordingly
• workaround for a kernel bug in the latest raspberrypi-kernel package

(Compare view)

Some first config docs are available here: https://faq.octoprint.org/camera-streamer-config

The source tree used for the build is here: https://github.com/OctoPrint/OctoPi-UpToDate/tree/camera-streamer

❗ Please note

This image needs to be flashed to your SD card, wiping it in the process. So if you want to keep anything on there, make a backup first! You can also create an OctoPrint backup, download that, flash, restore from backup. There's no way to update to the contents of this image without a full reflash.

Please provide feedback on your experience with this image in this ticket, whether things work for you or not. Make sure to at least include the following:

• Everything working?
• Pi model
• used cameras
• in case of issues: related logs (journalctl -u camera-streamer\* | pb and share the generated paste.octoprint.org URL)

Known issues:

• --camera-{v,h}flip are currently broken in camera-streamer v0.1-16-gcdb62ef (cdb62ef), see --camera-{v,h}flip throw an error now when they used to work with the same camera ayufan/camera-streamer#51

Common pitfalls:

• RPiV3 camera not auto-focusing? Make sure any kind of case you've added to it is not interfering with the lens & sensor

[b-morgan]

RPi 4B with camera module V3 (no printer). Image booted without incident. OctoPrint backup said it was for a new image so I created a new backup on my RPi 3B (with OctoPi 0.18.0, OctoPrint 1.8.7, camera module V2.1, and LulzBot TAZ 6). New OctoPrint backup installed and camera is working.

[Robinson91]

Everything seems to work (including the PiCam V3) except for one very important thing: OctoDash not working despite working fine before the update. Error message on screen (official 7"): "error: XDG_RUNTIME_DIR not set in the environment". Anyone know how to fix this?

RPi 4B 8gb
PiCam V3 Wide

[fosterthree]

Everything working on my end (RPi Zero W / v3 Camera). Thank you so much for your amazing work on this and everything else, @foosel!

[foosel]

OctoPrint backup said it was for a new image

You were already on 1.9.0rc3 I take it? In that case, yeah, backup restoration is stopped because things might have changed between 1.8.x and 1.9.x. I think I should maybe allow a manual override here if the user thinks that's a good idea (here it would have worked). Going to add a TODO for that to OctoPrint proper ;)

[foosel]

Error message on screen (official 7"): "error: XDG_RUNTIME_DIR not set in the environment". Anyone know how to fix this?

Can't say that I have any idea what could be going on here. BUT, this image includes a newer kernel (latest from apt) for which I already had to fix one bug, so possibly this is related somehow?

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/setting-up-multiple-webcams-in-octopi-the-right-way/32669/172

[onlywatanabe]

Anyway to setup multiple cameras on this new stack? I was told the guide above wouldn't apply to this new firmware. I'm not able to access port 8081 on the new firmware using that guide.

[cp2004]

The documentation for the new camera stack linked above has a section at the end for setting up multiple cameras.

[onlywatanabe]

Thanks so much. That was so much easier than the previous method.

[Elitesoulman]

I've got a Pi3+ and I'm working with the v3 camera module, everything seems to be working great. The options I've tried (resolution and framerate) seem to be working as intended. Thanks again @foosel for your hard work.

I'm chasing one issue with Octolapse (timelapse only stable with a larger delay >1000ms) but everything with the actual build is great.

[emelbardis]

What would be the syntax for AF off and focal point (LensPosition) at the middle range? I'm assuming lens position is from 0 to 32 so middle would be 16. AF on my machine is not really usable since it seems to try to focus constantly due to vibration.

- available option: AfMode (0000001c, type=3): [0..2]
- available option: LensPosition (00000023, type=5): [0.000000..32.000000]

[cp2004]

You can definitely turn off autofocus by using

OPTIONS='--camera-options="AfMode=0"

The closest explanation I could find of the values was the Raspberry Pi documentation - which doesn't use the same values. It does list some AF modes, but with no numbers attached. Source.

I believe it is:

• 0: 'manual' focus - allows to use LensPosition
• 1: 'auto' focus - auto focus once when the camera starts up
• 2: 'continuous' AF - what the default is in this image - continuously adjusts the focus to try and keep the image sharp.

I then played around with LensPosition in the same way as autofocus, eg.

OPTIONS='--camera-options="AfMode=0" --camera-options="LensPosition=1"

and could set the different values between 0 and 32 and it changed the focal point a lot. Focus scales aren't really linear, so you might not need 16, so I suspect trial and error might help. Alternatively, use AFMode=1 to autofocus once.

[emelbardis]

Thanks. This is really helpful.
AFMode=1 probably runs at boot and subsequent boots but it might be helpful to boot with an object in the center of the plate, setting ideal AF and then trying to retrieve that LensPosition value to set permanently.

edit: got it focused nicely with lensposition 6 but this thing is a jittery mess when anything is moving (like the printer). I don't think this cam will work for this application. Is there anyone who's having a good experience with these?

[cp2004]

Ideally, I guess this page should be reworked to describe the debugging procedure for camera-streamer. I'll see if I can get a PR together to update the page:

Edit: PR #4

[Ruhel786]

Everything working?
This install was much more difficult to get HyperPixel 4 touchscreen and OctoDash working. No idea why. I had to comment out dtoverlay=vc4-kms-dpi-hyperpixel4sq and then the touchscreen started working. Is this anything to do with the OctoPi image?
Also OctoLapse no longer takes stabilised images. Thanks to @Elitesoulman comment above I added a >1000ms delay and its working a bit better.

Pi model:
Pi 4 2gb

Camera:
PiCam v3

in case of issues: related logs (journalctl -u camera-streamer* | pb and share the generated paste.octoprint.org URL)
https://paste.octoprint.org/9yy638kJaJ

[FormerLurker]

I've been running some tests today, and here are the things I have observed:

Everything working: The camera streamer is working as expected
Pi model: Pi 3B
Used Cameras: Logitech C920

I had a minor issue that isn't a big deal, but I figure I'd mention it: my settings backup failed to restore because it was from a 'newer version of OctoPrint'. I know it's due to the version numbering of this pre-release, and that's fine, but in case some people are surprised.

However, I did discover a change of behavior between mjpg-streamer and camera-streamer that I thought you all should be aware of: the /snapshot endpoint is delivering a frame from the past, and not the 'next' frame, like mjpg-streamer used to do. This issue seems to affect the raspicam much more than a usb camera (I need to do more testing on the raspi camera, which is why I didn't mention it in the 'used cameras' yet), but it is definitely noticeable when using my C920. Here I will only discuss the USB camera behavior I have tested enough to understand (I think). This was discovered (of course) while testing Octolapse. There is a default delay of 125MS added before requesting a snapshot from the endpoint, and this is no longer enough to get a stable timelapse. This number used to be quite conservative (I typically use delays of < 50MS for my own timelapses, and sometimes much lower).

The FPS plays a key role, apparently, in determining how much delay needs to be added. At 15FPS, you get a frame every 66.67MS approx. That means we can be only 1 frame behind for the default 125MS delay to work (66 .67 * 2 = 133.34MS = No bueno). At 30FPS (up from the default of 15), the default delay appears to be sufficient (more testing needed on my part to verify), but only just so. Increasing the default delay will increase oozing and artifacts, unfortunately, so I'd really like to keep it to a minimum.

I have added an issue to the camera-streamer repo (feature request, linked above) for an endpoint that is capable of returning the next available frame, and asked if there are any workarounds or alternatives. I took a look at the code, and it would definitely take me quite a bit of time to understand, so hopefully if this feature request is denied, I can at least get some pointers/info so that I can fork and PR. If not, setting the default FPS to 30 (no problem for my RPI 3b) would help quite a bit, though I know that would be problematic.

If you feel this comment is polluting the intent of this thread, please feel free to remove it as it isn't exactly a problem for OctoPrint. I will report my findings with the raspicam v2 ASAP.

[foosel]

Is this anything to do with the OctoPi image?

It could be related to this being based on OctoPi 1.0, which in turn is now based on a newer Debian version (Bullseye instead of Buster). Which raises the question, much more difficult compared to what?

If you feel this comment is polluting the intent of this thread, please feel free to remove it as it isn't exactly a problem for OctoPrint. I will report my findings with the raspicam v2 ASAP.

Absolutely not, that is valuable feedback! :) Also glad to have you back!

[FormerLurker]

Also glad to have you back!

Took me long enough, lol!

FYI, there has been some movement on my feature request. I'm always blown away by the open source community. This new webcam stack will be a huge upgrade!

[Ruhel786]

It could be related to this being based on OctoPi 1.0, which in turn is now based on a newer Debian version (Bullseye instead of Buster). Which raises the question, much more difficult compared to what?

@foosel Sorry I didn't clarify in my original post. I have been using the 1.0.0-1.8.6-20230222114422 which seemed to be extremely stable for me. I have tested this again on a separate memory card and installing this version and getting it working with HyperPixel and OctoDash was as simple as using the one-line installers for both the screen and OctoDash.

I never updated to the stable release.

When I installed OctoPi 1.0.0 with OctoPrint 1.8.7-20230328122604 I just found that using the one line installers for both the HyperPixel screen and OctoDash would not work the first time and I had to manually install OctoDash to get it working. I also know that some of the issues could be inexperience on my part but going back to the previous pre-release image, the installation and configuring of the screen and plugin was seamless and quick.
I've only installed the most recent pre-release image OctoPi 1.0.0 with OctoPrint 1.8.7-20230328122604 once, Im happy to go and try it all again as I have spare memory cards for testing images/builds.

[cp2004]

I guess it could be the difference in kernel versions? If I'm remembering right this image coincided with a kernel upgrade that might have impacted it.

[foosel]

Could be. There seem to be some kernel shenanigans in general these days, just learned the other day that the firmware updater will now push 64bit kernels on 32bit userspace systems: raspberrypi/linux#5402 🤡

See also this discussion on the OctoDash repo: UnchartedBull/OctoDash#3559

That will need to be addressed for OctoPi-UpToDate in general, even outside of this current camera stack work. Speaking of which... I'm holding back on this currently because of the known issue/regression with vflip/hflip no longer working under current libcamera versions, see known issues above. And the discoveries by @FormerLurker regarding snapshot behaviour also gave me pause, so I'd like to see where this is going first as well.

So I guess my original goal of "get this finalized within or very much right after Q1" is out of the window now. Will still see that I get a new build posted with a pin of the 32bit kernel, next week most likely, and it would then be lovely if you could give this a test in your setup @Ruhel786

[Ruhel786]

Will still see that I get a new build posted with a pin of the 32bit kernel, next week most likely, and it would then be lovely if you could give this a test in your setup @Ruhel786

Hi @foosel. I'm on my phone so the GitHub layout is a bit weird. I'm happy to try the versions on my setup. Can you just clarify which one/s you want me to try? Ill be doing the 1.9.0 RC4 this weekend and have a few memory cards so can try a few more.

[foosel]

@Ruhel786 Nothing to try yet. What I meant was, I'll create a new build of the OctoPi image with camera-streamer stack and current stable OctoPrint (1.8.7) some time next week, that will then make sure the kernel is pinned to 32bit, and then you can check if things are still more difficult or not with regards to OctoDash and Hyperpixel things.

[Ruhel786]

Ok. I'll keep an eye out for it. I might have another go with this current version and screenshot the errors in case they are relevant to you.

[FormerLurker]

FYI, I'm installing development build of camera-streamer in preparation for testing. See this issue.

[FormerLurker]

Installed the new version and tested with a short print @30fps with my USB camera, and it works BEAUTIFULLY! In fact, it's a huge upgrade over the old streamer, shaving off between 100-200MS (I need to re-test with the old streamer to verify the FPS setting I used, which plays a big role) for snapshot acquisition time, and another 125MS by setting the camera delay to 0MS. This should provide a substantial quality boost by eliminating at least 225MS of oozing per frame (maybe up to 325MS!). This is the single biggest per/snapshot performance boost for Octolapse ever, I believe. If not, it's pretty close. I have yet to test the pi camera.

Note: the snapshot url needs to change for this test to be valid:

http://{IP_OF_PI}:8080/snapshot?max_delay=0

Also be sure to verify the index page of the streamer (http://{IP_OF_PI}:8080/) shows the new parameter:

[Ruhel786]

@Ruhel786 kernel is pinned to 32bit, and then you can check if things are still more difficult or not with regards to OctoDash and Hyperpixel things.

Had another go last night and after actually reading the changes that have been made it made sense about the error with OctoDash.
OctoPi image above was installed perfectly and ran on Raspberry Pi 4 4GB with Rectangle HyperPixel 4 screen.
HyperPixel 4 screen driver installation was simple via one line legacy installer.
curl -sSL get.pimoroni.com/hyperpixel4-legacy | bash
In /boot/config.txt add
dtoverlay=vc4-kms-dpi-hyperpixel4
dtparam=touchscreen-inverted-x
display_lcd_rotate=3
The screen and touchscreen work perfectly.
I missed the part about the 32bit kernel which explains why the OctoDash online installer fails. It always seems to try to install the 64bit version of the deb file. Manually installing the 32bit deb allows for a straightforward installation.
Below is the error if you try to run the OctoDash one line installer and run the program.

OctoPrint working fine with OctoDash after manual install of 32bit deb.

[Elitesoulman]

@Ruhel786 the issue with >1000ms delay for Pi Cam v3 is fixed in the current develop branch of camera streamer. I've had great results so far.

[Ruhel786]

@Ruhel786 the issue with >1000ms delay for Pi Cam v3 is fixed in the current develop branch of camera streamer. I've had great results so far.

Did you do a full OctoPi install? Thank you

[Elitesoulman]

Using this RC, yes. OctoPi-UpToDate, 20230328122604. The other changes are documented on the camera-streamer discussion ayufan/camera-streamer/issues/53. I've also added an issue in Octolapse to document logs and other testing FormerLurker/Octolapse/issues/895.

[banthungprong]

Using the HQ Cam (IMX477R) on a Pi3 B+ (didn't work with the old mjpeg and high resolutions).
Streaming with 1920x1080 and 30fps without any problems while printing.
Very nice: with the option to activate the RTSP server I can integrate the cam in my frigate NVR.

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/webcam-repeatedly-fails-every-3-minutes/51415/3

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/add-support-for-raspberry-pi-camera-v3/49052/9

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/new-pi-v2-camera-on-pi-4b-not-working/51456/3

[matthewfischer]

After struggling with the official build - this one finally solved the camera issues. Worked great out of the box.

Raspberry Pi 4B
Pi Cam 3
Prusa Mk3s+

When will this get into the mainline?

[Ruhel786]

@matthewfischer

After struggling with the official build - this one finally solved the camera issues. Worked great out of the box.

Raspberry Pi 4B Pi Cam 3 Prusa Mk3s+

When will this get into the mainline?

Did you only install this image and nothing else? I have the same setup as you and cant get the camera to work on this image. Had to go back to a previous build.

[matthewfischer]

All we did was a flash of this image and it just worked. We didn't restore from backup because we never finished the old install - so maybe that's difference.

[GitIssueBot]

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/raspberry-pi-camera-3-problem/51570/2

[BigBlock65]

RPi Zero 2 W with Raspberry Pi Camera Module 3 (Prusa MK3S Printer). Image booted and ran initial setup script as expected.. Camera came online without any additional configuration. I also have a Logitech C270 connected to the USB port which was working on the current release build. I will be attempting to set that up as a second camera next.

[BigBlock65]

RPi Zero 2 W with Raspberry Pi Camera Module 3 (Prusa MK3S Printer). Image booted and ran initial setup script as expected.. Camera came online without any additional configuration. I also have a Logitech C270 connected to the USB port which was working on the current release build. I will be attempting to set that up as a second camera next.

I successfully added the USB camera following these steps: https://community.octoprint.org/t/camera-streamer-configuration-on-octopi-1-0-0/49950

I will be checking timelaps configurations tomorrow. Thanks to everyone who contributed and made this all work so nicely!

[foosel]

After some upstream bug fixing on the part of @ayufan (THANKS!) I've prepared an updated test image. It includes a new build of camera-streamer which fixes the flipping options no longer working, and also pins the kernel to 32bit (so that latest RPi shenanigans don't move it to 64bit while keeping a 32bit user space, which causes issues with things like OctoDash). New image here: #5

[Teslafly]

I tried setting up octodash with the "new camera stack 1.9.0" raspberry sd image on a pi 3B+
I used raspberry pi flasher to configure wifi and ssh at card flashing.

I have the official 7" display connected with just the ribbon cable and power.

octodash installed fine, but when it booted, the touch screen didn't work. as far as I could tell the touch controller was not being detected.
However It did work with an off the shelf desktop rasbian image with the same hardware setup.

I looked in the config.txt on the boot partition, and uncommented the 2x i2c config lines to enable those ports since I think the touchscreen is attached there?

# Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
dtparam=i2s=on
# dtparam=spi=on

with that change the touchscreen started working.

So possibly octodash setup script needs to enable the i2c port for the touchscreen controller, or the setup should include a note about doing it manually.