New RPi boards needing a newer image

[cp2004]

3 reports of this on the forums this week:

https://community.octoprint.org/t/unsupported-board-type-error-raspberry-pi-4-model-b/40874?u=charlie_powell

https://community.octoprint.org/t/no-network-vanilla-raspbian-works-but-octopi-does-not-pi-4b-4gb/40778?u=charlie_powell

I think it may be time to think about publishing a release candidate build so we don't get this question too much - the same happened with the OctoPi 0.17 to 0.18 upgrade, it was a long time and the questions started to build. The bullseye build seems to work well enough. It's over a year since the last release, so out of the box users are faced with an outdated list of packages by quite a long way.

Are there any outstanding items that need fixing before release that we could try and work out? I'm happy to help testing and recruiting testers from across the community.

I also have a question on the versioning. It seems the next version has switched to be 1.0.0. I would argue this will be confusing for people who don't know the difference between OctoPi and OctoPrint (which happens regularly). Especially if the next release becomes 1.1.0 and so on. I can see keeping it 0.xx may not be desired, so I was wondering maybe keeping the number increasing and calling the next one 19.0? Or something similar to keep a form of consistency. SemVer shouldn't really apply here since breaking changes etc. are created by the image used to build OctoPi, so OctoPi's versioning doesn't signal anything about compatibility.

[guysoft]

Thanks for the report and links.
@foosel and I initially decided to wait and see how the new Debain Bullseye behaves for people before we move the official release to support it.
I guess we didn't expect a shadow hardware change for the new Pis.
If anyone can figure out what the difference in the Pis is it might help with understating what we should do. I have a suspicion its some change to the EEPROM, but just because it was introduced to Rpi4.

Regarding version change, as I mentioned in the version increment commit b6b7f36 , I do think its time to change it to be non 0.x . Not because to differentiate from OctoPrint, but because I think stuff shouldn't be beta forever.
Its a good point you raise with the version being too close to OctoPrints' one. Though I have a feeling some will always confuse it, since I still get issue reports with the version so OctoPi as the one of OctoPrint. So I am not sure its worth keeping the version for number for that.

I will start looking in to a new RC and if anything else should go in to it too.

[cp2004]

Bullseye image did work OK for me initially, and I guess no news could be good news? I know a couple people who have installed it but not reported any problems.

I do think its time to change it to be non 0.x . Not because to differentiate from OctoPrint, but because I think stuff shouldn't be beta forever.

Agreed, there's no need to keep it 0.x anymore. Since it doesn't have to be a dependency/have an API you get to make up the rules for versioning.

[guysoft]

BTW I by chacne bought a new pi after two of the ones I had here burned out. I trued flashing it with 0.18.0 and it did work. So no way to reproduce here ATM.
Will update here too once we have an RC.

[foosel]

I've asked for some affected people to help test a temporary solution (an adjusted image that has updated kernel and bootloader packages, see here). If this works it should reduce the severity of this issue a bit.

edit For the record, this has been rolled out as the new "stable" image now when you download via the Raspberry Pi Imager or through the download page as of January 19th. See https://github.com/OctoPrint/OctoPi-UpToDate/releases for what is being published in RPi Imager and on octoprint.org/download.

[cp2004]

Some work might be needed to get the Pi cam to work, as the new libcamera stack is not working with mjpg streamer by the looks of it.

https://community.octoprint.org/t/pi-camera-on-raspberry-pi-4-works-in-terminal-but-not-in-octoprint/41078/12

[foosel]

Maybe time to switch to HLS by default or something like that (unless that's broken too of course)?

[cp2004]

HLS has a long delay that makes it annoying to use (at least for me, I wouldn't like it). I think it needs more work to come out of 'experimental' stage. The resolution/FPS is hardcoded at the moment in the service, for example. Possible to make these changes, for sure.

The WebRTC streaming would be ideal, but there's no reliable implementation of the streaming side yet. If it can be figured out it might be good to make it optional before the default anyway?

I suspect ustreamer will see a relevant patch before mjpg_streamer will do, as it's actively maintained and the author was working on it I think.

[foosel]

Sounds reasonable. The alternative is switching bullseye back to the legacy stack (which apparently is in fact an option) and hope that there will be a viable alternative that actually works out of the box before legacy goes the way of the dodo for good.

[guysoft]

Thanks for checking all of this and updating, it really helps decide how to proceed. Merging the picam bullseye fix for now. I Really hope the new stack works soon and we can use it. People do want it, HLS related alternative #750 #701 and #649

[lnorton89]

I'm noticing some strange behavior related to mjpeg_streamer on what I assumed was the latest buster image. I have two of the exact same USB camera's and the second one will work intermittently and now not at all. Tried lots of fixes in the configs, switching between USB2/3 ports and no success.

I eventually noticed my webcamd is different that the one in the repo that was updated quite a while ago. I'm thinking the raspberrypi imager utility used an outdated image. The newest daemon shows mjpeg_streamer being in /opt. I went ahead and updated my daemon to latest version and recompiled latest mjpeg_streamer_experimental and changed the binary path to my users bin but no change. EDIT: I guess I was looking at the devel branches daemon which explains the 'outdated' image.

Inspecting webcamd.log shows some odd behavior. The checks for Pi 4 don't seem to be working on my pi 4 unless its only looking for that specific root hub chip on specific pi 4's because it says "It seems that you don't have VL805 (Raspberry Pi 4)". (Re: pull #623.

I can start a new issue but from reading here it seems like it may be related?

[cp2004]

You've managed to mash several topics (and probably created your own problems) here. Not at all related to the topics being discussed here, which is about work needing to be done to create a new image, based on bullseye.

The bullseye image has not yet been released. OctoPi 0.18 is the lastest stable image that you can download through the Raspberry Pi imager.

Yes it would be expected that the webcamd would be different, since the repo here is the current development progress towards the next release, not the current stable one. The VL805 check actually just looks like a misleading log message, it was a workaround for a specific firmware problem, not generic RPi 4.

If you need help with OctoPi, OctoPrint, plugins, webcams and other configuration please use the community forums or the OctoPrint discord server.

[lnorton89]

Most repo's have the master as the default branch, that was my mistake. I'm not having problems with OctoPrint, this is specifically related to the linux image provided in this repo.

[guysoft]

Suggestion.
We could release 0.18.1 perhaps from the https://github.com/OctoPrint/OctoPi-UpToDate build.

The reason we should not release 1.0.0 (aka 0.19.0) for now is because AFAIK the video stack is with problems since the move to bullseye.

[foosel]

That's an option. However just to clarify, the patch from @PowerWiesel that you merged fixed the video stack issue (also confirmed that myself on Thursday after finally finding my RPiCam again).