OctoPi 1.0.0 RC1 Status

[guysoft]

First release candidate for OctoPi 1.0.0

There are both 32bit and 64bit images available. Which give support to new Raspberry Pi 4B hardware pis that have been shipping out there. The 64bit image is based on Ubuntu 20.04.4, since it seemed more stable than RaspberryPi OS when testing 64bit, it might improve later on.

Raspsberrypi 3 and up can try the 64bit version. No performance gain in normal OctoPi is expected. It might help future plugins.

Please try the release candidate so we know it works.

32bit armf: Download it at: https://unofficialpi.org/Distros/OctoPi/nightly/2022-02-27_2022-01-28-octopi-bullseye-armhf-lite-1.0.0.zip

Md5: 672cc74db5c863e8378d994b8ef25504.

64bit arm64/aarch64: Download it at: https://unofficialpi.org/Distros/OctoPi/nightly-arm64/2022-02-27_octopi-20.04.4-preinstalled-server-arm64+raspi-1.0.0.zip

Md5: a78e25bda751e0253981020d2ddf4298.

Changes in the image

• OctoPrint 1.7.3
• Version is 1.0.0, it seem like its about time https://github.com/guysoft/OctoPi/commit/b6b7f3623aa59021513693596537543b725aff04
• Raspbery PI OS uses bullseye
• rpi.gpio-common has been added
• Fix webcamd daemon loop & handling of non-usb v4l2 devices #741 (@foosel)
• Add a network monitoring for wifi connections #729 (thanks @hawkeyexp)
• Delete octopi-network.txt
• picam-bullseye-fix #763 (Thanks @PowerWiesel)

[ChrisHeerschap]

Installed 32 bit on a Pi 2 (trying to find a Pi 4, hah) with no problems. Did a little of my own customizing afterwards and am setting up Octoprint plugins and all. So far no issues seen.

[matonb]

I needed to:

• add the 'video' group to the user pi to fix the 'Cannot check for throttling' error
• install g++ package to install OptoLapse plugin

I haven't been able to resolve a serial port permissions is yet though. I'm using the GPIO serial pins instead of a USB connection.

Odd permissions on dev/ttyS0

ls -la /dev/ttyS0
crw--w---- 1 root tty 4, 64 Mar  7 10:41 /dev/ttyS0

If I allow the tty group read access chmod g+r /dev/ttyS0, the problem goes away temporarily but something is reverting the permissions...

For reference, on octopi 0.18:

ls -la /dev/ttyS0
crw-rw---- 1 root dialout 4, 64 Mar  7 07:17 /dev/ttyS0

[guysoft]

@matonb 32 bit right?

[matonb]

@guysoft , Ah I missed a critical bit of info there...

No, I was testing the 64bit version

[SiliconExarch]

Downgraded to 0.18.0 again as the webcam stream was freezing every minute or so requiring me to refresh OctoPrint and timelapse snapshots were also failing intermittently with my PlayStation Eye webcam using the suggested arguments for mjpg-streamer.

This is using the 64bit version on a Pi 3B+. Also I had to install raspi-config myself as it wasn't in the image.

[foosel]

For the record, both octopi-password.txt and octopi-hostname.txt do not work on the 64bit build, probably because the services in question do not run as they are still implemented as init scripts and systemd on the ubuntu build used here simply ignores them. At least the password one is also something we recommend people do if they've managed to forget the system password (requires physical access to the Pi to solve, but at least can be solved without having to fire up a unix system and a chroot environment).

I noticed this while running an automated update test for the imminent release of OctoPrint 1.8.0rc1 against the 64bit image - or tried to run it that is, since the provisioning of the image didn't work as expected and thus the rest of the run couldn't complete.

See here for the services I'm talking about - they need a conversion to systemd for 64bit to achieve feature parity in this regard.

Personally btw I'm not planning on pushing the 64bit build on people on the download page - I don't see any advantages from it for the general public, and the completely different base systems will be a nightmare in end-user support 😐

[guysoft]

The network settings should work in the ubuntu build. I tested them a few months ago. That is something I should fix.

[foosel]

Yeah, network does work, but neither password nor hostname

[guysoft]

I am considering adding a setting to my fork of rpi imager, which would let us disable username changes. OctoPi and many other images are a single-user operating system in effect, and there is really no need to be able to change the username. The password makes sense though to have an option. I could look in to that.

[eblieb]

Still having camera issues where the camera freezes in the control panel

[guysoft]

@eblieb What camera? details please. I got both a pi camera and a webcam working here, so I need information to differentiate

[eblieb]

@guysoft I am getting this error a lot in DMESG

[224158.023005] uvcvideo: Failed to resubmit video URB (-1).
[225621.991796] uvcvideo: Failed to resubmit video URB (-1).
[226994.479849] uvcvideo: Failed to resubmit video URB (-1).
[227726.474051] uvcvideo: Failed to resubmit video URB (-1).
[227817.973307] uvcvideo: Failed to resubmit video URB (-1).
[229830.969270] uvcvideo: Failed to resubmit video URB (-1).
[230013.970997] uvcvideo: Failed to resubmit video URB (-1).
[231111.962102] uvcvideo: Failed to resubmit video URB (-1).
[232850.452275] uvcvideo: Failed to resubmit video URB (-1).
[232850.452303] uvcvideo: Failed to resubmit video URB (-1).
[234131.455648] uvcvideo: Failed to resubmit video URB (-1).
[235595.448098] uvcvideo: Failed to resubmit video URB (-1).
[236327.446014] uvcvideo: Failed to resubmit video URB (-1).
[237242.447494] uvcvideo: Failed to resubmit video URB (-1).
[237333.948067] uvcvideo: Failed to resubmit video URB (-1).
[243464.413076] uvcvideo: Failed to resubmit video URB (-1).
[247307.410226] uvcvideo: Failed to resubmit video URB (-1).

and
[37042.653540] usb 1-1.3: New USB device strings: Mfr=2, Product=1, SerialNumber                                                                                                                           =3
[37042.653557] usb 1-1.3: Product: HDA Webcam USB
[37042.653572] usb 1-1.3: Manufacturer: HDA Webcam USB
[37042.653587] usb 1-1.3: SerialNumber: HDA Webcam USB
[37042.659485] uvcvideo: Found UVC 1.00 device HDA Webcam USB (0c45:6366)
[37042.681116] input: HDA Webcam USB: HDA Webcam USB as /devices/platform/soc/3f                                                                                                                           980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/input/input7
[37042.718769] usb 1-1.3: 3:1: cannot get freq at ep 0x84
[37048.443644] dwc_otg_handle_wakeup_detected_intr lxstate = 2
[37048.996063] usb 1-1.2: new full-speed USB device number 17 using dwc_otg
[37049.106057] usb 1-1.2: device descriptor read/64, error -71
[37049.336041] usb 1-1.2: device descriptor read/64, error -71
[37049.566041] usb 1-1.2: new full-speed USB device number 18 using dwc_otg
[37049.676090] usb 1-1.2: device descriptor read/64, error -71
[37049.906016] usb 1-1.2: device descriptor read/64, error -71
[37050.026227] usb 1-1-port2: attempt power cycle
[37050.705964] usb 1-1.2: new full-speed USB device number 19 using dwc_otg
[37051.145991] usb 1-1.2: device not accepting address 19, error -71
[37051.255986] usb 1-1.2: new full-speed USB device number 20 using dwc_otg
[37051.695971] usb 1-1.2: device not accepting address 20, error -71
[37051.696249] usb 1-1-port2: unable to enumerate USB device
[37068.575396] usb 1-1.2: new full-speed USB device number 21 using dwc_otg
[37068.685448] usb 1-1.2: device descriptor read/64, error -71
[37068.915415] usb 1-1.2: device descriptor read/64, error -71
[37069.145433] usb 1-1.2: new full-speed USB device number 22 using dwc_otg
[37069.255434] usb 1-1.2: device descriptor read/64, error -71
[37069.485435] usb 1-1.2: device descriptor read/64, error -71
[37069.605707] usb 1-1-port2: attempt power cycle
[37070.285383] usb 1-1.2: new full-speed USB device number 23 using dwc_otg
[37070.735390] usb 1-1.2: device not accepting address 23, error -71
[37070.845403] usb 1-1.2: new full-speed USB device number 24 using dwc_otg
[37071.285381] usb 1-1.2: device not accepting address 24, error -71
[37071.285558] usb 1-1-port2: unable to enumerate USB device

[guysoft]

@eblieb

1. has the camera ever worked?
2. this looks like a power supply issue, make sure you are using a good power supply and a GOOD USB cable.
3. You are using a rpi zero from the looks of the log because its an OTG usb port. They are known to have wifi issues that could explain why your ui is getting stuck. Its noted here quite clearly: https://octoprint.org/download/

[eblieb]

@guysoft yes the camera works it just randomly freezes in the web viewer. It works fine with OctoApp and never freezes in that.

[antony]

Doesn't seem to be able to connect to my wifi network on a pi 3. Wired works without issue, and have configured /etc/wpa_supplicant/wpa_supplicant.conf to provide my ssid and password, but it never connects. iwlist shows the interface as ready, but it never gets an IP address.

The pi was previously running a very old build of octopi from 2020 and I just swapped out the SD card.

Not sure what other information I can provide but happy to provide whatever helps.

[rexit1982]

Late to the party but it seems like input_raspicam.so is not present on 0.18 so webcamd is failing to start up/work with camera="raspi". Was that intentional and I'm jsut not finding it?

[ChrisHeerschap]

Running on a raspi 4 with a Logitech C920 USB webcam and getting the same video stream freezing issue. Seems to be related to webcamd thinking that mjpg_streamer hasn't successfully started (it has) and so kills and restarts it over and over again.

Can document here or create an issue, have been collecting logs and troubleshooting - which works better for you?

[cp2004]

Has anyone tested HLS streaming on these images? Only interested in 32 bit at the moment, who knows what is different with the 64 bit one since it's ubuntu not RPi OS. It's mainly to test the changes from Buster -> Bullseye.

[cp2004]

Has anyone tested HLS streaming on these images? Only interested in 32 bit at the moment, who knows what is different with the 64 bit one since it's ubuntu not RPi OS. It's mainly to test the changes from Buster -> Bullseye.

I have only tested this in a nightly image which is based on a different version of the underlying OS (end of Apr release, the selected nightly above is Jan).

Since the h264_omx encoder has been removed in Bullseye, generally replaced with h264_v4l2m2m, HLS streaming fails to work. I tried to directly swap the encoder used, and while the encoding then works the HLS output part of the ffmpeg command fails to work.

I doubt I will be able to figure it out as I am relatively new to using ffmpeg. If I do, of course I will post a PR - but if anyone else knows what to do that would be wonderful to know.

[guysoft]

Hey, Updating that the userless install seems to be in on route solving itself, and 1.8.0+ is out, so we can get ready for a new RC.

Also Looks like 64bit on rpi is officially supported: https://github.com/RPi-Distro/pi-gen/issues/481#issuecomment-1160074790 So since we have the mechanics to have the Ubuntu work too. We can decide what we prefer. I am not 100% sure I want to go with either of them, since they both have pros and cons.

[foosel]

Personally I'd prefer to stick with Raspbian for this release, instead of switching targets now mid RC phase, and there's also this:

Personally btw I'm not planning on pushing the 64bit build on people on the download page - I don't see any advantages from it for the general public, and the completely different base systems will be a nightmare in end-user support 😐

[guysoft]

This RC1 has an ubuntu build for 64bit. It would be "switching to raspbian 64 bit". My gut feeling is that if we release ubuntu we will get a lot of complaints. But its also a rare chance to test switching an official build to ubuntu and seeing how people react to it. It might also have advantages. Mainly a steady release cycle and long term support if we pick LTS

[cp2004]

Currently, the Raspberry Pi cam support won't be working with the RPi OS 64 bit builds. That's one of the reasons they switched to libcamera, to get that working. As far as I know, enabling the legacy camera stack only works on the 32 bit images.

Arducam actually forked mjpg-streamer & added support for libcamera to it, but last I checked there was no motion on mjpg streamer to patch it directly. https://github.com/jacksonliam/mjpg-streamer/issues/336

Regular USB cameras still work the same as before, but HLS streaming doesn't work in the bullseye images on either 32/64.

[wlayher]

As far as I know, enabling the legacy camera stack only works on the 32 bit images.

I have a Pi running 64 bit Raspbian bullseye running motioneye with the legacy camera enabled. Works.

[cp2004]

As far as I know, enabling the legacy camera stack only works on the 32 bit images.

I have a Pi running 64 bit Raspbian bullseye running motioneye with the legacy camera enabled. Works.

That's good news - I don't actually have an RPi camera so just going on what I read/would remember. My Pi cam broke so I haven't been able to test that kind of thing ☹️

[bnorick]

As others have noted, the Pi Cam freezes constantly in this RC. I am using the 32bit variant on a Zero 2.

[guysoft]

Hey, I think we are ready for an RC 2 finally. Things got stable. Will set it in motion

[foosel]

You mean RC2, right? ;)

[robness]

Hey, I think we are ready for an RC 1 finally. Things got stable. Will set it in motion

I agree, I have been using it for a while now and the last issue I had was related to the PI Cam issues that was fixed and has been working ever since.

[guysoft]

You mean RC2, right? ;)

I do, fixed 😅

[guysoft]

Use RC2 https://github.com/guysoft/OctoPi/issues/788