@ltlowe i ran your script and can't get the pi cam 3 working 
Forgot to add details sorry,
i have a Prusa MK3S+ using SimplyPrint which is octoprint based running on a raspberry pi 4 model b 3gb ram.
It shouldn't matter that i'm running SimplyPrint since the webcam doesn't show up in octoprint when connected to the octoprint UI.
the script requires OctoPi 1.0.0 as a base OS because it needs to be bullseye for camera-streamer to work. The SimplyPi image is currently still based on the buster image.
Copy and pasting this worked for me without any further issues on my Pi 3B+ with Camera module V3. Thank you so much gambiting! Trying to solve this as a new Pi and Octoprint user taught me a lot but it was becoming frustrating. I'm so glad Octoprint is fully functional now.
I am new here and reading through this thread, I'm getting lost. Let me know if I should make a new thread, but can someone please point me in the right direction as far as how to get my raspberry pi camera module 3 to work with my raspberry pi.
My current set up is a raspberry pi 3A+ with OctoPrint version 1.8.7 and OctoPi version 1.0.0. I have raspberry pi camera module 3 attached, but cannot get it to work with OctoPrint. I have read through this thread, but I don't know where I should start. Am I suppose to install a whole other operating system on the raspberry Pi? Can someone tell me where I am suppose to start, please? Thank you!
@Scrambler2612, Official support (from Raspberry Pi) for the camera V3 is available in Debian 11 (Bullseye) based operating systems. Since you have OctoPi 1.0.0 you have satisfied that requirement. You may need to be up-to-date by using sudo apt update && sudo apt upgrade.
OctoPrint, however, needs some additional software to use the camera V3 and that support is currently in testing. To use it will require a new OS image.
I suspect that "a new image" may actually mean "multiple new images". You probably could get away with "two new images" but installing the latest available now and then waiting until the testing phase is over and installing the final image but this assumes that the currently available image works for you.
You can follow the progress of the testing phase in https://github.com/OctoPrint/OctoPi-UpToDate/issues/2.
I have a USB SD card adapter which I can move from my desktop (where I download and flash new images) to my RPi (where I can move files from the previous image to the new one). If you don't have any files other than those related to OctoPrint, then making an OctoPrint backup on the old image, downloading it, and then restoring it to the new image should be sufficient. You can also use something like WinSCP to backup and restore files instead.
Thank you so much for taking the time to respond to my question. I just flashed the new image to my SD card and the camera works! The image quality is quite good too. Thank you so much!
Having now read through this thread and over on the feedback thread for the new camera streamer stack I'm a little puzzled for what to do.
I previously posted a call for help over on the Raspberry Pi forums, before checking here and realizing the issues probably isn't related to a vanilla installation. Here's my post for reference.
In summary, I've got a fresh configuration of OctoPrint install flashed using the Raspberry Pi flashing tool on the Bullseye version. I've updated and upgraded everything and things are working great including OctoDash.
So am I correct in the assessment that the only way to fix this is to flash this new, beta image? Or can I run the script from @ltlowe?
Obviously, I'd love for the fix to come as part of an incremental update rather than a complete re-deployment or making any ad hoc changes that might later complicate an update.
I think @b-morgan's post just above sets out the issue reasonably well:
The script might still work but it has been dropped in favour of the new OS image.
Unfortunately it won't ever come from an incremental update as the webcam streaming stack is not set up for this. Perhaps in the future it might be set up to be updatable, who knows - but we definitely can't change the past so you will have to flash a newer image (ie. the testing image linked) than what is available right now.
Well, kind of a bummer I guess. Probably the biggest hassle is that it's not just OctoPrint that I setup on this device. So usually a new image means setting up several other things each time which is a hassle, but I get that's the way it works right now.
Well, the new image does seem to work so that's great. I just now know I'll have to re-image here once that goes to general release.
@b-morgan - would you mind explaining how you put a new image on the Pi without taking the SD card out (if I understand correctly what you do)? My Pi is in an enclosure and permanently attached to my Prusa. Opening the enclosure is quite a hassle. Pointing at an explanation works fine for me. Thanks for your help. Hubert
@hubert.smits, I'm sorry if I gave you that impression but I don't put new images on the Pi without taking the card out. I use a USB microSD card adapter and two microSD cards.
I use the USB adapter on my desktop to write the new image. After booting the new image on the Pi. I use an OctoPrint backup to restore plugins and files related to OctoPrint. I move the adapter back to the Pi so I can copy any non-OctoPrint files from the old image to the new image.
After I'm satisfied with the new image, I use rpi-clone to make a copy of the current microSD card.
Could you use something like this to extend the microSD slot to a more convenient location?
Thanks, I understand what you are doing. And I have the SD extension arriving today - great minds think alike 
I'm still operating fine with the RC build of OctoPi 1.0 and the script prepared by @ltlowe
Other than presumably, full 1080p, I'm hesitant to update to the official support just yet as Github still has people complaining.
Anyone else make the switch/upgrade and is happy that they did?
I'm not sure where you got the impression that there aren't people happy with the image from the OctoPi-UpToDate GitHub. I can count the vast majority of comments in the GitHub issue being positive 'it works', with maybe a couple of issues that are unsolved. A lot of problems have been solved in that thread.
It's completely up to you whether to switch, at the end of the day you are unlikely to gain much, I was just wondering why the GitHub issue made you hesitant to do so.
I'm sorry, are you honestly talking about this? Feedback for the new camera-streamer based webcam stack · Issue #2 · OctoPrint/OctoPi-UpToDate · GitHub
In what world are the posts there a "vast majority" of "it works"?
I have to hunt around and read full comments just to find 1 or 2. If it works, great, I'm happy to switch, but your post is weirdly condescending.
I can see how that thread could be daunting and misconstrued as having all kinds of issues, but since the last build release mentioned toward the end there have been several confirmed successes.
So I went ahead and jumped in. Oddly though, the OctoApp reports the resolution as 1056p which is the same resolution the scripting above reported.
What's the best way to discern what resolution is being shown? I changed the contents of libcamera.conf to the below and rebooted:
# The resolution to request on the camera sensor. Defaults to 1280x720.
WIDTH=1920
HEIGHT=1080
# The height to use for the video stream. Defaults to 720.
VIDEO_HEIGHT=1080
# The height to use for the snapshots. Defaults to 1080.
SNAPSHOT_HEIGHT=1080
# The framerate to set on the camera. Defaults to 15fps.
FRAMERATE=30
# Additional options. By default enables continuous auto focus (if possible).
OPTIONS='-camera-options="AfMode=2" -camera-options="AfRange=2"'
I'd just like some sort of confirmation I guess. 1056p in OctoApp is puzzling to me.
1056 is the height of the stream that you're seeing I would suspect. I have just poked at mine (Pi Cam V3, and with the same configuration I'm seeing a stream of 1920x1056, not 1080. Saving an image from the snapshot URL show the same thing.
camera-streamer seems to indicate the camera won't give it 1920x1080, at least for the snapshot:
Mar 24 21:58:33 rpiblue sh[675]: device/v4l2/buffer_list.c: SNAPSHOT:output:mplane: Requested resolution=1920x1080 is unavailable. Got 1920x1088.
Mar 24 21:58:33 rpiblue sh[675]: device/buffer_list.c: SNAPSHOT:output:mplane: Using: 1920x1056/YUYV, bytesperline=3840, sizeimage=3.9MiB
So it does then decide to use 1920x1056 instead. I can't explain why at the moment, but can confirm it's not something specific to your setup.