Feedback for the new camera-streamer based webcam stack about octopi-uptodate HOT 203 CLOSED

I realized the file /boot/camera-streamer/lib-camera.conf was not there

It's supposed to be called /boot/camera-streamer/libcamera.conf, without a dash. Was that missing as well? If so, are you sure you flashed the right image, as in, the one linked above?

Sorry, you were right... I flashed octopi-1.0.0-1.8.6-20230222095002 (instead of octopi-1.0.0-1.8.6-20230222114422), now both the video stream and snapshots work perfectly fine!

from octopi-uptodate.

1: Everything working?

Bear in mind I am a total beginner and that just got my 3D Printer couples of days ago, but this image work perfectly for me. I was even able to seemlessly restore the backup of the default version I just had finished setting up yesterday. So far so good !

2: Pi model

Raspberry Pi 3 Model B Plus 1Gb (Rev 1.3)

3: Used Camera

Using the new Pi Camera V3 and the quality is amazing, I'm not even sure if my 200$ webcam is better than that. the autofocus is very responsive. I may play more with the settings but i've pluged the following in the libcamera.conf and it worked like a charm :

PORT=8080
WIDTH=1920
HEIGHT=1080
FRAMERATE=30
OPTIONS='-camera-options="AfMode=2" -camera-options="AfRange=2"'

Now I just need to print a mount for it...

I will be back if I encounter any issues or to report back on the stability, @foosel anything I should be looking for?

from octopi-uptodate.

It really should behave just like a regular image, so by all means, update to 1.8.7 through the update dialog, like you normally would. Consider it an additional test.

from octopi-uptodate.

Has anyone else here seen issues with WiFi provisioning? 🤔

I also used RPi Imager to initially set up the WiFi credentials with no issue.

from octopi-uptodate.

Works a treat for me! Resolution reported varies a bit.

Raspy 3B
Pi Camera Module 3

/boot/camera-streamer/libcamera.conf
PORT=8080
WIDTH=1640
HEIGHT=1232
FRAMERATE=30
OPTIONS= camera-options=AfMode=2 -camera-options=AfRange=2

I guess this is meaningless:
libcamera-hello --list-cameras
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]

VLC (http://192.168.1.132/webcam/?action=stream)
Stream0
Code Motion JPEG video MJPG
Video Resolution: 1632x1216

camera-streamer --help
Configuration:
-camera-path=
-camera-type= v4l2 - 00000000
-camera-width= 1920
-camera-height= 1080
-camera-format= DEFAULT - 00000000
-camera-nbufs= 3
-camera-fps= 30
-camera-allow_dma= 1
-camera-high_res_factor= 0.007813
-camera-low_res_factor= 0.000000
-camera-auto_reconnect= 0
-camera-auto_focus= 1
-camera-vflip= 0
-camera-hflip= 0
-camera-jpeg.options= compression_quality=80
-camera-h264.options= video_bitrate_mode=0
-camera-h264.options= video_bitrate=2000000
-camera-h264.options= repeat_sequence_header=5000000
-camera-h264.options= h264_i_frame_period=30
-camera-h264.options= h264_level=11
-camera-h264.options= h264_profile=4
-camera-h264.options= h264_minimum_qp_value=16
-camera-h264.options= h264_maximum_qp_value=32
-camera-list_options= 0
-http-port= 8080
-http-maxcons= 10
-rtsp-port= 0
-log-debug= 0
-log-verbose= 0

Thanks!

from octopi-uptodate.

Everything is working with newest image. Using Raspberry Pi 4B with RPi Camera Module 3 Wide. Image is super clean using the default settings. I've printed a couple small prints without any issues. Thank you.

from octopi-uptodate.

I've just flashed octopi-1.0.0-1.8.6-20230301124943 and everything seems to be working fine using defaults.
RPi 3B+ with imx708-wide camera module v3.

I do not use wifi so my procedure was simply:

• flash (using balenaEtcher, not the RPi Imager)
• boot with newly flashed sd card
• restore backup
• reboot

and the camera was streaming! I did not modify anything.
I have not had a chance to try octolapse or the built-in timelapse yet. Some people had problems with still capture timing and the temporary Camera Module 3 support that we were previously running, although it was working ok for me by the end.

from octopi-uptodate.

So, quite embarrassing, but it turns out the timeout issue on reboot was still there because while I had made the commits to fix that and thought I'd pushed them before triggering yesterday's build, apparently that was not the case because that build built from a05e8c8.

New image, built from commit 50dafce: https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.6-20230302093328 Outdated, see #2 (comment) for link to latest

(Btw, just for the record, the generic looking number at the end of the image names is the date and time it was built at, so this one on 2023-03-02 at 09:33:28 UTC.)

Also huge thanks @b-morgan for those logs which made me look at the service file for the changed timeout, which made me discover the issue.

from octopi-uptodate.

All of these images need to be flashed to your card, as in, they completely wipe your SD card and replace it with a fresh install of the image.

If you want to preserve your OctoPrint data, you need to make a backup first, which you can then restore from.

from octopi-uptodate.

The reboot issue is fixed and aside from the RPi imager 1.7.4 changing my username (i.e. I missed it) things look good here.

from octopi-uptodate.

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

https://community.octoprint.org/t/pi-camera-v3-imx-chipset-based-cameras-not-working/49022/101

from octopi-uptodate.

Mostly looking for data on first run experience and longer term stability 😊👍 Glad to hear it's looking great so far 🥳

from octopi-uptodate.

Some thoughts I did have....

Is it worth making the webcam streaming stuff something that can be updated in-place?

Mainly because this is relatively new, and there's a fair chance that we might find bugs or camera-streamer itself gets updated to fix issues. I guess updating camera-streamer itself would require a re-compile which could be harder to do (esp. on a Pi Zero, some issues were reported there with memory). But the scripts could change easily.

I know it would add additional complexity to something that I think should stay as simple as possible (to avoid chance for issues), but I could imagine that a small script could download a set of files from GH and overwrite them, maybe only if explicitly called with camera-streamer-control update for example.

Something that popped into my head, maybe worth a consideration for the future & try and prioritize getting this out for better camera support sooner rather than later. Interested to know thoughts.

Another point is what the logs look like. I'll give it a full poke at the weekend, but one of the most helpful parts of webcamd.log is to list the available devices, when it is in 'auto' mode to know whether a user's camera is properly connected, and I was wondering if this does a similar thing in it's logs? & it would be good to make the systeminfo bundle pick up these logs like it does webcamd through the Pi support plugin.

from octopi-uptodate.

Is it worth making the webcam streaming stuff something that can be updated in-place?

Compiling this on-device for an update is definitely not going to be a good experience, it already takes quite long on CI, and even a few minutes on my beefier dev machine. I've been wondering if it might be possible to have a pre-compiled distribution available, but I'm worried about issues with dynamic linking, so this would probably have to be a static build. Actually something to look into in any case though because that would allow us to speed up the image build a TON again.

but one of the most helpful parts of webcamd.log is to list the available devices, when it is in 'auto' mode to know whether a user's camera is properly connected, and I was wondering if this does a similar thing in it's logs?

Currently not, but that's something that could be added. We have a bunch of systemd units to look out for now, camera-streamer, camera-streamer-libcamera, camera-streamer-usb@<name> and camera-streamer-usb-<name>.path. I guess adding some command camera-streamer-control status or something like that to output some information (basically libcamera & usb status, plus detected configurations), and have that become part of the systeminfo bundle might be helpful, on top of the logs?

it would be good to make the systeminfo bundle pick up these logs like it does webcamd through the Pi support plugin.

That's still on my TODO list actually, though so far without an actual issue on the tracker. Changed that: OctoPrint/OctoPrint-PiSupport#14

from octopi-uptodate.

My LulzBot TAZ 6 printer is connected to an RPi 3B with an RPi camera V2 currently running OctoPi 0.18 and OctoPrint 1.8.6. It's not clear from the comments so far that this camera is supported by the new stack. I'd be happy to test it if you think it should work.

I also have an RPi 4B with an RPi camera V3 but no printer running a pre-release build of OctoPi 1.0.0. I will try the new image on this system and report back.

from octopi-uptodate.

It should be supported, so please, test if possible.

Also edited the post up there to hopefully make that clearer.

from octopi-uptodate.

To quickly cover a discussion point raised by "thecoda" under the configuration guide (where I'll remove it soon due to that being the wrong place):

Definitely a step in the right direction, though I think we're going to need some community work on camera-streamer to happen too.

For one thing I'm going to seriously miss the ability to rotate the image 180° if that's not supported, this is enough of a blocker that it almost prevented me from trying 1.0.0 at all. It also needs systemd unit files for both the HQ and v3 pi cameras to get optimal performance from these devices, both of which I imagine will be widely used.

To address these points:

I'm going to seriously miss the ability to rotate the image 180° if that's not supported

That is supported by adding -camera-vflip=1 -camera-hflip=1 to the OPTIONS (yes, both together indeed has the same result as a rotation by 180 degrees). Now also documented more clearly. What isn't supported as far as I can see is rotating by 90 or 270 degrees, but I can't say I expect there ever was much use of that to begin with (and if push comes to shove THAT can still be done within OctoPrint itself).

It also needs systemd unit files for both the HQ and v3 pi cameras to get optimal performance from these devices, both of which I imagine will be widely used.

It doesn't need more systemd files for that, that's why there are user-configurable conf files in the mix here, that come preconfigured to work with the majority of possible hardware out there. What we need are good examples for these, and the configuration guide will be a good place for sharing these.

from octopi-uptodate.

1: Everything working?

Not able to see the video stream. Octopi works fine, I could restore a previous backup but no video stream. It says "Webcam stream loading" on the Control tab.
I realized the file /boot/camera-streamer/lib-camera.conf was not there so I created it with the following lines:

PORT=8080
WIDTH=1920
HEIGHT=1080
FRAMERATE=30

It still didn't work after restarting the raspberry.
Am I missing something? Thanks.

2: Pi model

Raspberry Pi 4 (2 GB)

3: Used Camera

Using the new Pi Camera V3 Wide NoIR.

from octopi-uptodate.

I realized the file /boot/camera-streamer/lib-camera.conf was not there

It's supposed to be called /boot/camera-streamer/libcamera.conf, without a dash. Was that missing as well? If so, are you sure you flashed the right image, as in, the one linked above?

Can you please provide the output of libcamera-hello --list-cameras and also share the output of journalctl --boot -u camera-streamer-libcamera as well as journalctl --boot -u camera-streamer?

from octopi-uptodate.

First test on my RPi 4B... I used Raspberry Pi Imager 1.7.3 with the ...4422 image (verified with MD5) and changed the hostname to rpi4b (as octopi is being used by my other system). It appears that the hostname didn't get set. WiFi didn't get setup either.

from octopi-uptodate.

How did you modify the hostname? octopi-hostname.txt as well as octopi-password.txt iirc had issues on the first boot with OctoPi 1.0.0 in general, that's not specific to this webcam stack modification, so if you did it through that, that would explain it. Noticed this during RC3 but decided to classify it as boy l not that critical since it works on any following boots.

from octopi-uptodate.

I set the hostname, password, and WiFi settings in the RPi Imager. All of those settings failed. I believe they worked with the default Raspberry Pi OS image I have on another SD card.

I attached an HDMI monitor and a USB keyboard and used raspi-config to change the hostname and pi password. I edited /boot/octopi-wpa-supplicant.txt but that isn't working for WiFi. Without a network connection, there is little else I can do.

I'll see if I can find an ethernet cable.

from octopi-uptodate.

This is pretty annoying every time I reboot: "A stop job is running for camera-streamer (20s / 1min 30s)". It finishes after the 1min 30s).

from octopi-uptodate.

With an ethernet cable I was able to connect to the OctoPrint UI and finish the first time setup. The RPi V3 camera appears to be working.

from octopi-uptodate.

This is pretty annoying every time I reboot: "A stop job is running for camera-streamer (20s / 1min 30s)". It finishes after the 1min 30s).

Ah, shoot, I thought that was caused by a bug I fixed since I could no longer reproduce it. Wasn't able to narrow it down to a specific setup either (too many variations the past two weeks), so now I know I should try to debug this against a v3 module. Thank you!

from octopi-uptodate.

Any suggestions on how to fix the WiFi setup? I'm not going to attempt to test my RPi 3B / RPi camera V2 configuration unless I solve this problem. An ethernet cable is pretty much out of the picture as well.

You mention hotplug so I guess I should ask, if I take this SD card I've built for the RPi 4B / RPi camera V3, change the hostname (so DHCP server doesn't get confused) and move it to the RPi 3B, will it detect the V2 camera and configure it (properly to be determined 😄)?

from octopi-uptodate.

Currently not, all I can say is that raspi imager worked just fine here so far with this. Actually even am now using the very same way to provision the images in my testrig (firstrun.sh) and this image wouldn't be there is that hadn't worked.

Would be interesting to know if you have the same issues with the stock 1.0.0, since this is something that definitely wasn't touched here either.

Has anyone else here seen issues with WiFi provisioning? 🤔

But to your second question, yes, it should

from octopi-uptodate.

I've just had a go with the new image, and it looks like the Raspberry Pi Camera Module 3 is working for me! I've not tried a timelapse yet, but I can see it in the preview. Autofocus and white balance all seems to be working great!

I manually configured the wifi settings in octopi-wpa-supplicant.txt

Here are the steps I took in case it's helpful for anyone...

Hardware:

• Raspberry Pi 4 Model B 8GB.
• Raspberry Pi Camera Module 3.
• MacBook Air for image writing.

Steps:

• Download image from https://github.com/OctoPrint/OctoPi-UpToDate/releases/download/1.0.0-1.8.6-20230222114422/octopi-1.0.0-1.8.6-20230222114422.zip
• Unzip image.
• Load Raspberry Pi Imager, selected custom image and write that to your SD card.
• Once the image has been written, mount the drive locally and set up wifi configuration in /Volumes/boot/octopi-wpa-supplicant.txt using Vim or Visual Studio Code (not WordPad or TextEdit). The mount location may be different. Uncomment the WPA/WPA2 network section in octopi-wpa-supplicant.txt and add your network name and password.

## WPA/WPA2 secured
network={
  ssid="put SSID here"
  psk="put password here"
}

• Save the file, unmount the SD card, install it in your Pi and then power on the Pi.
• Access OctoPrint via http://octopi.local/ configure the necessary settings, or restore backup.
• Finally, test the webcam is working at http://octopi.local/#control

from octopi-uptodate.

After writing the 4422 image on the SD card, I checked/copied the firstrun.sh file in /boot. I inserted the image in my RPi 4B and powered it on. The hostname, password, and WiFi credentials were not set. I shutdown from my attached keyboard, moved the SD card back to my desktop, and firstrun.sh was still in /boot. Since the last line or so is "rm -f /boot/firstrun.sh", I am assuming that firstrun.sh didn't get executed.

Next I'll try the 5002 image which should be the official 1.0.0 version.

from octopi-uptodate.

Using the exact same steps with 5002 image was successful (i.e. firstrun.sh was executed and deleted). I'm using the same SD card for both images and I compared the firstrun.sh files from both with the only difference being the (I assume hashed) password for the user Pi.

from octopi-uptodate.

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

https://community.octoprint.org/t/arducam-autofocus-camera-not-working/50019/5

from octopi-uptodate.

@b-morgan I honestly have no clue what's going on there, because as I said that is exactly the kind of configuration approach I used for provisioning myself for probably now hundreds of times while creating the new camera stuff to begin with, and I didn't have an issue even once. And from the comments up there it looks like it works for others as well.

This is honestly baffling to me, especially since the modifications made here literally don't touch this, even OctoPi's build script doesn't touch this.

from octopi-uptodate.

Just for the hell of it I switched to a different SD card (64gb->32gb) and it worked! Previous card still has the 1.0.0 release on it and it works as well. Now to try the change hostname and boot on my RPi 3B connected to my real printer!

from octopi-uptodate.

Success of sorts. The camera works but the resolution is way different than it was before. I'll have to figure out what my old settings were and see if I can duplicate that image. I guess I should re-image the SD card and try from scratch just to verify (but I'm not moving my keyboard and monitor so it better work 😃 )

from octopi-uptodate.

Kind of works. Using a Raspberry Pi camera module 3 wide angle version. Image quality is clear, but does not seem to be picking up the full wide angle field of view. Appears to be showing a regular field of view. I initially had this issue with RC3 build, but can't remember what was the fix that allowed to get wide angle field of view. I'm still messing with settings.

Besides the the field of view issue. Everything else seems to be stable.

Using:
Raspberry Pi 4b
Raspberry Pi Camera Module 3 Wide

from octopi-uptodate.

Using a Raspberry Pi camera module 3 wide angle version [...] I initially had this issue with RC3 build

Consider me very much confused here, because raspberry pi cam v3 supposedly only works with the libcamera stack, and we purposefully disabled that on OctoPi 1.0.0rc3 because the old webcam stuff isn't compatible with that. Did you manually switch to libcamera on rc3 with a different webcam server?

In any case I guess you'll need to adjust something in the OPTIONS. I added some more explanation about how to get infos on the available options on a specific camera to the config docs yesterday linked in the first post.

from octopi-uptodate.

Kind of works. I have a 16mp autofocus imx519 camera, and I can see the video stream in the control tab, but it is out of focus. For the stream only works when the resolution is 1080p, even though the camera can support up to 4656 by 3496 pixels.

from octopi-uptodate.

Starting from scratch on the RPi 3B with an RPi camera V2 produced the same results as moving the SD card from the RPi 4B (with an RPi camera V3). The snapshot from the V2 camera on 0.18.0 is:

and the snapshot from the V2 camera on 1.0.0 is:

Suggestions as to what change to make the 1.0.0 image the same as 0.18.0 image are welcome 😂

from octopi-uptodate.

https://community.octoprint.org/t/camera-streamer-configuration-on-octopi-1-0-0/49950#available-additional-options-4

Says http://octopi.local/webcam/options but that results in an error. http://octopi.local/webcam/option works. Not sure which should be changed but I suggest adding an s to the actual page and leave the documentation alone (or make both work).

from octopi-uptodate.

Documentation error, URL comes from camera-streamer.

from octopi-uptodate.

In #2 (comment)

(sudo systemctl {start|stop|restart} camera-service) I think should be (sudo systemctl {start|stop|restart} camera-streamer)

from octopi-uptodate.

Consider me very much confused here, because raspberry pi cam v3 supposedly only works with the libcamera stack, and we purposefully disabled that on OctoPi 1.0.0rc3 because the old webcam stuff isn't compatible with that. Did you manually switch to libcamera on rc3 with a different webcam server?

Instead of going back to the rc3 build I went and used the RPi Imager build(20230222095002). Now, I've got 2 builds I am trying out. The build you have provided here(20230222114422) and the RPi Imager build(20230222095002). For the RPi Imager build I ran an additional script provided by ltlowe (https://community.octoprint.org/t/pi-camera-v3-imx-chipset-based-cameras-not-working/49022/72). I'm getting images from both, but the RPi Imager build with the added script is providing the wide lens image as you can see below.

Unfortunately, I am not a coder and the only differences I am seeing between the two builds is some file structure differences. So I'm not sure if this is just user error.

from octopi-uptodate.

@TrainorEC, It's not user error. The parameters (options) on the camera are different between the two builds. Unfortunately, the expertise necessary to figure out those differences are not readily available. Once we know what "knobs" to turn, there are plenty of knobs available.

from octopi-uptodate.

@b-morgan You could try adjusting the height, width and frame rate in /boot/camera-streamer/libcamera.conf

It defaults to 1280x720@15 fps.
I was able to get 1536x864@30 fps working with my Raspberry Pi Camera Module 3.

Steps:

1. Edit /boot/camera-streamer/libcamera.conf and change the following lines:

# The resolution to set on the camera. Defaults to 1280x720.
WIDTH=1536
HEIGHT=864

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

2. Restart the camera-streamer-libcamera service
   sudo systemctl restart camera-streamer-libcamera

Even though they are the same aspect ratio, you can see the zoom is slightly different.

1280x720

1536x864

from octopi-uptodate.

@paulmaunders, thanks for the tip. At the moment, I'm not as concerned about the camera V3 settings because I haven't put it to use yet.

I am, however, concerned about the camera V2 settings because that camera is deployed monitoring my LulzBot TAZ 6 printer and the default settings out of the box are worthless. I tried changing the resolution but that didn't help so I need to figure out what other settings need to be changed to get back to the view I had with the default mjpg-streamer settings on OctoPi 0.18.0.

On OctoPi 0.18.0 (and previous versions), the defaults of 640x480, 10fps worked so I didn't need to do anything but print a case, position the camera, and manually adjust the focus. I think the option I need is ScalerCrop but I have no idea what values to use (or their format).

from octopi-uptodate.

@TrainorEC (and anyone else who has used my script)
I have not tried the final 1.0.0 image, nor foosel's new camera support yet and may not have a chance to this weekend.
I see here that there is a single setting for resolution, but the latest camera-streamer supports setting separate resolution for camera, stream, and video. Depending on which version is used, you may be seeing different fields of view. I have read that some modes are crops rather than full sensor.

I was going to try out the latest streamer and update my scripts for it, but I think that everyone's effort is better put into helping test foosel's integration. As soon as I get time, I will be reading the latest here and trying it out for myself.

from octopi-uptodate.

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

https://community.octoprint.org/t/pi-camera-v3-imx-chipset-based-cameras-not-working/49022/106

from octopi-uptodate.

I've made some progress in attempting to resolve my camera V2 issue. First, I stopped the camera-streamer with:
sudo systemctl stop camera-streamer
then I executed the following:
libcamera-hello --list-cameras

Available cameras
-----------------
0 : imx219 [3280x2464] (/base/soc/i2c0mux/i2c@1/imx219@10)
    Modes: 'SBGGR10_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]
           'SBGGR8' : 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]

and:
libcamera-jpeg -o test.jpg --width=640 --height=480
which resulted in:

This is very close to the image displayed in the OctoPrint control tab on OctoPi 0.18.0. Next, I restarted the camera-streamer with:
sudo systemctl start camera-streamer
and the image displayed in the OctoPrint control tab on OctoPi 1.0.0 (4022) is back to the zoomed in version as posted above.

Any suggestions on how to determine why the camera-streamer is behaving this way?

from octopi-uptodate.

1: Everything working?

Bear in mind I am a total beginner and that just got my 3D Printer couples of days ago, but this image work perfectly for me. I was even able to seemlessly restore the backup of the default version I just had finished setting up yesterday. So far so good !

2: Pi model

Raspberry Pi 3 Model B Plus 1Gb (Rev 1.3)

3: Used Camera

Using the new Pi Camera V3 and the quality is amazing, I'm not even sure if my 200$ webcam is better than that. the autofocus is very responsive. I may play more with the settings but i've pluged the following in the libcamera.conf and it worked like a charm :

PORT=8080
WIDTH=1920
HEIGHT=1080
FRAMERATE=30
OPTIONS='-camera-options="AfMode=2" -camera-options="AfRange=2"'

Now I just need to print a mount for it...

I will be back if I encounter any issues or to report back on the stability, @foosel anything I should be looking for?

Mostly looking for data on first run experience and longer term stability 😊👍 Glad to hear it's looking great so far 🥳

Coming back with an update, for some reason the video feed in octopi seems to something freeze. happened twice so far:

On the left, is the URL directly (/webcam/?action=stream) , on the right octopi, I was few minutes in the printing and it was not responsive. As I was writting this post, it came back after by itself, I am not sure if it was because I access the URL directly or if it was just by waiting.

from octopi-uptodate.

The camera-streamer had a few bugs that were fixed last days - critical causing stability issues.

I would strongly advise updating to https://github.com/ayufan/camera-streamer/tree/develop. It also updates how resolutions are handled and drops usage of ?res=low. In general there are those four:

• --camera-width/height as captured by sensor
• --camera-snapshot.height= a height of output (with maintained aspect-ratio) for /snapshot (downscaled from camera sensor, by default 1080p)
• --camera-video.height= a height of output (with maintained aspect-ratio) of /webrtc|/video (downscaled from camera sensor, defaults to --camera-snapshot.height)
• --camera-stream.height a height of output (with maintained aspect-ratio) of /stream (MJPG stream, slowest and most bandwidth intensive, defaults to --camera-video.height)

My advised settings is to:

• --camera-width/height get a sensor resolution, but make it tad bigger than 1080p to have a full zoom captured by the sensor (!) - it does not give any benefit to capture larger size except require more compute
• --camera-snapshot.height=1080 - we want high quality timelapse
• --camera-video.height=720 - if you use webrtc/video it is pretty good quality at low transfer
• --camera-stream.height=480 - if you use old way (mjpg-streamer) this will consume a ton of bandwith, but 480p is still decent

You can see those params in action:

• https://github.com/ayufan/camera-streamer/blob/develop/service/camera-streamer-raspi-v3-12MP.service
• https://github.com/ayufan/camera-streamer/blob/develop/service/camera-streamer-raspi-v2-8MP.service

from octopi-uptodate.

@ayufan Thanks for chiming in @ayufan! I'm just in the process of preparing an updated image with the latest stable branch, but in that case I guess I'll rather look into pulling from develop then.

I think I also identified the issue where the camera-streamer service was blocking a reboot, at least I can no longer reproduce this after changing the service's KillMode.

from octopi-uptodate.

Looking forward to the updated image and I hope you use the develop branch as I think that may help fix my camera V2 issue.

from octopi-uptodate.

New build is running now, should be done in 20min or so, will link it here then (or possibly tomorrow, my back is telling me I need to get away from my chair) and update the OP.

Changes:

• camera-streamer built from the develop branch
• adjusted KillMode for the streamer service
• two new options VIDEO_HEIGHT and SNAPSHOT_HEIGHT in /boot/camera-streamer/libcamera.conf that translate to -camera-video.height and -camera-snapshot.height. I decided against putting that by default on the USB conf because of the big warning in @ayufan 's README about this being a bit tricky with USB cameras, possibly requiring adjustments of the gpu mem. If people want to experiment with that however, they can still through OPTIONS.

from octopi-uptodate.

@foosel Correct. For USB cams if you don't change resolution it will not do decode JPEG>rescale>encode JPEG/H264 process, it will blindly passthrough MJPEG with addition of decode>encode H264 that will not be used unless you access camera via /video or /webrtc.

from octopi-uptodate.

I'm also waiting for feedback on develop branch, once it is confirmed to be stable will merge it into master.

from octopi-uptodate.

New image here: https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.6-20230228172408 Outdated, latest always see #2 (comment)

@ayufan well, I hope we'll get some feedback out of this for you :)

from octopi-uptodate.

New image here: https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.6-20230228172408

@ayufan well, I hope we'll get some feedback out of this for you :)

Guess I will have to re-image and restore a backup to update? Curious to see if address the issue I experienced

from octopi-uptodate.

Correct, backup, flash, restore.

from octopi-uptodate.

This issue still exists: "A stop job is running for camera-streamer (20s / 1min 30s)", finishes after the 1min 30s.

I'm also having the problem of "firstrun.sh" not being executed. This time on my RPi 3B with my printer attached.

Good news is my RPi 4B with camera 3 is working (without a printer attached).

from octopi-uptodate.

@ayufan In the two replies I've linked below, I posted some images of a problem I'm seeing with my RPi 3B with an RPi camera V2 attached. In the second link, I have narrowed the issue down to camera-streamer's default settings for the V2 camera (i.e. libstreamer-jpeg gives me the image I expect, but camera-streamer's image in OctoPrint is zoomed in.

Can you help me get to the bottom of this? Do I need to specify options and if so, which ones?

Thanks!

#2 (comment)
#2 (comment)

from octopi-uptodate.

This issue still exists: "A stop job is running for camera-streamer (20s / 1min 30s)", finishes after the 1min 30s.

Confirmed. I couldn't reproduce it with my fix yesterday, repeatedly, but this morning sure as hell it's back. Need to dig deeper.

I'm also having the problem of "firstrun.sh" not being executed.

I still have not even remotely been able to reproduce this, and I still don't even see how the modifications on the camera-streamer branch could achieve this, so I need more info here. What version of the RPi Imager are you using here? Does your SSID contain a single quote ' by any chance? Is it isolated to SD card/RPi/any other particular combination of factors?

from octopi-uptodate.

New image build up, https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.6-20230301124943. Outdated, latest always see #2 (comment)

Spent half the day wrapping my head around systemd ordering which apparently was the issue with the blocking on reboot, until I finally came across --no-block which together with some cleanup in the generated path files now really seems to have solved it, at least I have not been able to trigger this again after 10+ reboots.

from octopi-uptodate.

All of my images have been written with RPi Imager 1.7.3 onto Samsung microSD cards. My SSID contains alphabetic characters including a space, passphrase alphanumerics, no space. While I was confused as to the cause in the beginning, I believe the underlying issue is that firstrun.sh is not being executed.

My first experience was on my RPi 4B. Repeatedly failed multiple times with image 4422 until I switched from a 32GB micro SD card to a 16GB micro SD card. The 32GB micro SD card that failed with 4422 worked with 5002.

My most recent experience was with my RPi 3B. The microSD card with 4422 (that worked first time) was reimaged with 2408 and it failed. I was able to attach a 7" HDMI monitor and a keyboard, logged in and did "sudo /boot/firstrun.sh". Rebooted and I'm back in business (except the RPi started complaining about low voltage). Removing the monitor and keyboard solved that problem.

I have ordered more micro SD cards including some non-Samsung brands. I have an RPi 3B+ that I can test with to add a third system to the experiment. I don't have a third RPi camera but I can steal a Logitech USB camera from another system.

from octopi-uptodate.

It's really weird. I just tried earlier to explicitly flash fully manually with the latest rpi imager, and here it just works like it should, as it has also done for the automatically created firstrun.sh files in my whole testrig setup (which basically mirrors what the rpi imager does). So currently I really have no explanation but I have high doubts this is something that's caused by the new camera stack, given that the firstrun mechanism should trigger before it even has a chance to do anything.

from octopi-uptodate.

I have 2 3Bs working with the latest image, one with a 2.1 camera and module 3. Let me know if I can help.

from octopi-uptodate.

@bmorgan99 did you set wifi credentials etc via Raspberry Pi Imager, and was that successful?

from octopi-uptodate.

I agree with your logic. I'm just reporting what is happening to me! I've looked for how firstrun.sh is called and haven't found anything yet.

BTW, @bmorgan99 and @b-morgan are different people just in case you are as confused as I was 😄

from octopi-uptodate.

@b-morgan got confused a couple days ago as well but now know I need to look twice ^^

from octopi-uptodate.

even I did a double take 😞

from octopi-uptodate.

@b-morgan regarding your RPiCamv2 issue, could you please try the following in /boot/camera-streamer/libcamera.conf:

### Options for libcamera based cameras (PiCam, Arducam, ...)

# The port on which the webcam server for the camera should listen on. 
PORT=8080

# The resolution to request on the camera sensor.
WIDTH=3280
HEIGHT=2464

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

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

# The framerate to set on the camera.
FRAMERATE=30

# Additional options.
OPTIONS='-camera-options=brightness=0.1'

Restart the Pi or alternatively just the camera-streamer via sudo systemctl restart camera-streamer after changing.

from octopi-uptodate.

@foosel I will try that libcamera.conf as soon as I reimage both systems to the latest image.

With regards to the firstrun.sh issue, firstrun.sh is executed from cmdline.txt:

console=serial0,115200 console=tty1 root=PARTUUID=b1214a26-02 rootfstype=ext4 fsck.repair=yes rootwait quiet init=/usr/lib/raspberrypi-sys-mods/firstboot systemd.run=/boot/firstrun.sh systemd.run_success_action=reboot systemd.unit=kernel-command-line.target

At the end of firstrun.sh are the lines:

rm -f /boot/firstrun.sh
sed -i 's| systemd.run.*||g' /boot/cmdline.txt

which remove all the firstrun.sh references. Is there something you are doing with systemd to setup the camera-streamer that might be causing a race condition with this cmdline.txt execution of firstrun.sh?

from octopi-uptodate.

Not that I'm aware of. The unit files want multi-user.target, same as OctoPrint, so from my (admittedly still limited!) understanding they should not even be started here.

Maybe there's something helpful in the logs, can you run journalctl -b 1 > firstboot.log.txt and share that here? That should contain everything that was logged during the very first boot (which should have been running the firstrun.sh file).

from octopi-uptodate.

Murphy strikes again! With the latest image (4943) it worked on the RPi 3B. The libcamera.conf changes also worked.

I'll test the reboot issue after I image a card for the RPi 4B (it's much easier to attach the monitor to that one).

from octopi-uptodate.

RPi 4B booted and ran firstrun.sh successfully with 4943 image. However, it still did the 1m30s stop job. I suspect the RPi 3B does the same thing because it takes longer than I expect to come back after a reboot.

from octopi-uptodate.

Please share the logs as described in the top post. I even reduced the timeout to 10s (see eb4b339), so this sounds very odd and I need some logs.

from octopi-uptodate.

I just ran journalctl -u camera-streamer\* > logs.txt and renamed the file after I moved it to my desktop with WinSCP.

rpi4bcamera-streamer.zip

Do you want the output from the RPi 3B as well?

from octopi-uptodate.

@bmorgan99 did you set wifi credentials etc via Raspberry Pi Imager, and was that successful?

@foosel In my case, with the first image I tested I was not able to set credentials using the RPI Imager, I was with able with the built-in one, but no when trying to use the one downloaded here, but maybe my process was wrong?

So just to confirm, are you suppose to download the image here and "Use custom" in the wizard?

from octopi-uptodate.

@Draknars Yes, download the (latest) image posted in this topic and "Use custom" in the RPi imager (1.7.3). You can setup the hostname, SSH, password, WiFi credentials, locale, etc. using the "gear" icon below (and before) clicking the "Write" button.

from octopi-uptodate.

Camera V3 working on Raspberry Pi 4 2GB (with HyperPixel 4.0 square touchscreen)
The new image was installed with the RPi imager 1.7.4.

I manually configured the wifi settings in octopi-wpa-supplicant.txt using SSH and uncommented the relevant sections.

I followed @paulmaunders (thank you) instructions posted above (sorry I don't know how to link comments, new to GitHub)

Hardware:
Raspberry Pi 4 Model B 2GB.
Raspberry Pi Camera Module 3.

Camera feed working in OctoPrint. I will test TimeLapse tomorrow morning and report back.

I was unable to get the camera to work or be found with the HyperPixel 4.0 square screen until I added these 2 lines to the config.txt

disable_poe_fan=1 force_eeprom_read=0

Once I added these I have are to get the libcamera-hello --list-cameras command to work:

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]

from octopi-uptodate.

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

https://community.octoprint.org/t/raspberry-pi-camera-setup-in-latest-stable-octopi-build/50231/4

from octopi-uptodate.

Hi guys, I was sent here to try this build in order to get my v1.3 raspberry pi camera working but I haven't had success yet.
I've flashed the "1.0.0-1.8.6-20230301124943" image but I'm getting the "Webcam stream not loaded" issue in octopi.

I've had a read through this thread and I tried this line libcamera-hello --list-cameras but all it returns is no cameras available. The camera is definitely connected the right way and I do get a couple of blinks from the cameras status light as the pi boots up.

Any suggestions of where to go from here? I haven't been able to find any logs that I can share, so if you need those you'll have to point me in the right direction for them. Cheers!

from octopi-uptodate.

I've had a read through this thread and I tried this line libcamera-hello --list-cameras but all it returns is no cameras available. The camera is definitely connected the right way and I do get a couple of blinks from the cameras status light as the pi boots up.

@dmcke5 Given that from that thread I gather that your camera also didn't work with the old camera stac, I'm leaning towards something being wrong with that camera tbh. If libcamera-hello --list-cameras doesn't see it, it certainly sounds off, if that's a genuine rpi camera I'd expect it to be detected.

What does echo /sys/bus/i2c/devices/*/video4linux output?

from octopi-uptodate.

@foosel Hi I'm new to the Pi and coding. Regarding your new image https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.6-20230302093328
Do I need to reinstall EVERYTHING from scratch or can I install the latest version over top of the previous version?
Thank you
Ruhel

from octopi-uptodate.

I assume that the next UpToDate image will include 1.8.7, correct?

from octopi-uptodate.

Yes. Didn't want to build yet another one only for that and spam y'all even more with images ;)

from octopi-uptodate.

Except I'm in the middle of updating to 3328 😂🥰. I'll survive, when I logged in to shutdown 4943 it prompted me to update to 1.8.7. Here's hoping there will only be the "official" image soon!

from octopi-uptodate.

Except I'm in the middle of updating to 3328 😂🥰. I'll survive, when I logged in to shutdown 4943 it prompted me to update to 1.8.7. Here's hoping there will only be the "official" image soon!

Did you update to 1.8.7. without any issues? I just got the prompt earlier and did not know if I should update it.

from octopi-uptodate.

Another data point... RPi 3B+, Logitech C525 (identified as C505) USB camera. The camera-streamer found it and OctoPrint seems happy with the video stream.

from octopi-uptodate.

I've had a read through this thread and I tried this line libcamera-hello --list-cameras but all it returns is no cameras available. The camera is definitely connected the right way and I do get a couple of blinks from the cameras status light as the pi boots up.

@dmcke5 Given that from that thread I gather that your camera also didn't work with the old camera stac, I'm leaning towards something being wrong with that camera tbh. If libcamera-hello --list-cameras doesn't see it, it certainly sounds off, if that's a genuine rpi camera I'd expect it to be detected.

What does echo /sys/bus/i2c/devices/*/video4linux output?

Yeah, I think you might be right. I decided to grab a cheap USB webcam this afternoon and it worked first try, no configuration changes necessary. Not sure what to do with the Pi camera, it was brand new and I bought it specficially for this project. Oh well, at least it was cheap I guess!

from octopi-uptodate.

@dmcke5 What type of camera you have? Can you attach dmesg and v4l2-ctl --list-devices?

from octopi-uptodate.

You mean the new camera? Its a cheap no-name thing from a local retailer. Here's a link anyway for reference https://www.kmart.com.au/product/webcam-ring-light-43104994/? Probably not much use to anyone outside of Australia.

I assume you only want the relevant line from what dmesg returns since its so long? I think this is the only line that references the camera:
input: USB PHY 2.0: USB CAMERA as /devices/platform/soc/3f980000. usb/usb1/1-1/1-1.2/1-1.2:1.0/input/input0

v4l2-ctl --list-devices returns:

bcm2835-codec-decode (platform:bcm2835-codec):
/dev/video10
/dev/video11
/dev/video12
/dev/video18
/dev/video31
/dev/media2

bcm2835-isp (platform:bcm2835-isp):
/dev/video13
/dev/video14
/dev/video15
/dev/video16
/dev/video20
/dev/video21
/dev/video22
/dev/video23
/dev/media0
/dev/media1

USB PHY 2.0: USB CAMERA (usb-3f980000.usb-1.2):
/dev/video0
/dev/video1
/dev/media3

from octopi-uptodate.

@dmcke5

The camera is definitely connected the right way and I do get a couple of blinks from the cameras status light as the pi boots up.

I talk about CSI camera connected. USB will universally work, always.

from octopi-uptodate.

@dmcke5

The camera is definitely connected the right way and I do get a couple of blinks from the cameras status light as the pi boots up.

I talk about CSI camera connected. USB will universally work, always.

Its all unplugged now and for the time being I'd rather leave it alone since its working the way it is, sorry! The camera is a Raspberry pi camera V1.3. If I get time over the weekend I have a spare pi 4 here that I will try the camera on and see if I can get it working and I'll run those commands and report back.

from octopi-uptodate.

@dmcke5 Please do. This will help to understand why it does not work - it should!

from octopi-uptodate.

If I remember right, @foosel has an RPi camera V1 and an RPi camera V3 on her test rigs.

from octopi-uptodate.

Latest version not working for me on the following Configuration :

Image : https://github.com/OctoPrint/OctoPi-UpToDate/releases/tag/1.0.0-1.8.6-20230302093328.
Imager: Raspberry Pi Imager 1.74

Hardware: Raspberry Pi 4B 4GB
Storage: Samsung PRO Endurance 32GB Micro SDHC

I download the Image from GitHub, extract the .img from the zip file, Launch Raspberry Pi image and choose "Use Custom", setup Advance Settings, select the SD Card and then Image.

Once completed, I modify the octopi-wpa-supplicant.txt to add my Wi-Fi Settings. Finally I plug the SD Card and the Pi and turn it on.

Tried 3 times, and same result each time, it almost like OctoPi is never setup, based on the fact that there is no log directory

from octopi-uptodate.

Does it work without changing the user name? Does rebooting help after changing the user name? Could be something up with the user-fix service, unrelated to the changes here.

from octopi-uptodate.

Does it work without changing the user name? Does rebooting help after changing the user name? Could be something up with the user-fix service, unrelated to the changes here.

Rebooting and updating didn't do anything, let me format again, without changing the username

from octopi-uptodate.

Hi, I was able to get OctoPi working with one rpi camera and 1 usb camera on a RPI4 with OctoPi 1.0.0 and OctoPrint 1.8.7.
I've uploaded a document with the steps I took to get it working for anyone interested.
https://discord.com/channels/704958479194128507/708230099811434497/1081559132622028850

from octopi-uptodate.

Im new to pi and octoprint and cannot for some reason get the camera working, i did everything you said reflashed the sd card, checked the settings in libcam was correct and everything but it doesnt work, and when i do libcamera-hello it returns with Preview window unavailable [0:01:02.321712327] [1144] INFO Camera camera_manager.cpp:299 libcamera v0.0.3+40-9b860a66 [0:01:02.368431275] [1145] INFO RPI raspberrypi.cpp:1425 Registered camera /base/soc/i2c0mux/i2c@1/imx708@1a to Unicam device /dev/media4 and ISP device /dev/media1 [0:01:02.368693384] [1144] INFO Camera camera.cpp:841 Pipeline handler in use by another process ERROR: *** failed to acquire camera /base/soc/i2c0mux/i2c@1/imx708@1a ***

I have the official pi cam 3, using a pi 4 model b with 4gb ram

from octopi-uptodate.