search

guysoft / OctoPi

Scripts to build OctoPi, a Raspberry PI distro for controlling 3D printers over the web
GNU General Public License v3.0
2.45k stars 368 forks source link

OctoPi 0.18.0 RC1 Status #692

Closed guysoft closed 3 years ago

guysoft commented 3 years ago

First release candidate for OctoPi 0.18.0

There are both 32bit and 64bit Based on RpiOS images available. Which give support to Raspberry Pi 4B 8GB and Raspberry Pi 400

The main change that would be likely noticable to plugin developers is that OctoPi comes with Python3 now.

Please try the release candidate.

32bit armf: Download it at: http://unofficialpi.org/Distros/OctoPi/2020-11-02_2020-08-20-octopi-buster-armhf-lite-0.18.0.zip

Md5: d3cb6af431e326cb8bd27719016d3922.

64bit arm64/aarch64: Download it at: http://unofficialpi.org/Distros/OctoPi/2020-11-02_2020-08-20-octopi-buster-arm64-lite-0.18.0.zip

Md5: 643a6f4da6170607c57769a0c5bf2e7e.

Changes in the image

Build notes

carl5765 commented 3 years ago

im running multiple instances on one pi will this upgrade include upgrading them as when i install python 3 it doesn't see my second or third image

Prutsium commented 3 years ago

Will the 64bit also work in the 2GB Pi4? Have to setup a second Pi anyway as i cant get multiple instances to work (all guides are based on the 0.17 version that seems to have /etc/default/octoprint but 0.18 doesnt have that :).

guysoft commented 3 years ago

@Prutsium Should work with any device that supports 64bit instruction set. That includes all Pi4 and also 3B+

guysoft commented 3 years ago

@carl5765 I didn't understand. This is an OctoPi image, not an OctoPrint package upgrade. You need to physically flash your SD card.

derekslenk commented 3 years ago

Any way to update a current instance to this or just format/backup and restore

dxgldotorg commented 3 years ago

@guysoft should the 64-bit image be used on a minimum 4GB system?

LMS0815 commented 3 years ago

First release candidate for OctoPi 0.18.0

There are both 32bit and 64bit Based on RpiOS images available. Which give support to Raspberry Pi 4B 8GB and Raspberry Pi 400

64bit amd64/aarch64 version working like a charm on RASPBERRY PI 3B+ Raspberry Pi 3 B+, 4x 1,4 GHz, 1 GB RAM, WLAN, BT Restoring backup from old config was seamless.

Thank you!

guysoft commented 3 years ago

@derekslenk Yes, see below your comment. @dxgldotorg No, see above your comment.

dorfman2 commented 3 years ago

Had a very successful transition on a Raspberry pi 4 (1gig). Backup was seamless as well.

PistolsAtDawn commented 3 years ago

Hi! Love the software!

Just wanted to say that I cannot get my PS3 camera to work out of the box on 0.18 RC1. I didn't have time to test why this is though. It works flawlessly on 0.17.

Thanks!

sohxet commented 3 years ago

Hi, glad I can contribute a little by testing!

Sending an M997 command to reboot the printer after uploading a firmware file through marlin-bft plugin causes octoprint to become unresponsive, pi doesn't respond to ssh connections, M997 iteself doesn't execute. Raspi 4B 4GB, Ender 3 pro with SKR V1.3 mainboard running marlin 2.0.6.1 bugfix. Worked previously with octopi 0.17/octoprint 1.4.2 on a raspi 2B. octoprint.log

Will-wastelander commented 3 years ago

Back and restore from 0.17.0 to 0.18.0 RC1 went w/o a hitch on my rPi 4 4GB. I have 2 more to do. Currently running multiple plugins that were imported, and also installed OctoDash for screen use. Will be doing the same for the other 2 systems.

rbrian commented 3 years ago

Not sure what happened... but... I have an external USB SSD attached to my Pi that held my uploads, timelapses, etc. Initial setup was easy several months ago, just formatted it via SSH and it mounted automatically. Has been working fine ever since. Today I decided it was time to bite the bullet and upgrade to Python 3, and figured I'd just use the RC to do it. So I backed up via the OctoPi settings page, and copied my home directory on the Pi to the SSD so that I'd have all my other files, like my Klipper config. I flashed the RC just fine, and everything seemed to be OK. (I am having a bit of trouble with it not finding octopi.local for SSH, but it works via the IP address, so I'm not too concerned.) Then I went to go look on the SSD for my SAMBA config file... and there's nothing. Drive won't automount, and is empty when I mount manually. File recovery tools aren't helpful. This just cost me a week or so of tinkering with the Klipper configuration to get it working right & calibrated again. :( If anyone has ANY clue what might have happened, I'll be grateful to hear about it. I'm going to leave the SSD offline for the time being, just in case there is actually some form of recovery that will help.

I'll keep on with the RC, and let you know if I find anything else out of the ordinary.

sohxet commented 3 years ago

OctoPrint 1.5.0rc1 was released, does this affect testing of octopi 0.18?

guysoft commented 3 years ago

Talk to @foosel she mentioned it. Didn't seem to bother her. Just making sure. You rather not wait?

foosel commented 3 years ago

Considering that people were running into issues with current Pi4s vs the 0.17 image and the Pi400 also having gotten released (which I rightfully anticipated people would ask for support for, even though I don't understand WHY), I figured it would make more sense to push an OctoPi image RC now with the current stable OctoPrint on it, rather than wait until 1.5.0 hits stable (which depending on how this RC phase goes might still take until December). I stand by this decision.

guysoft commented 3 years ago

Ok. Also we could always make 0.18.1

foosel commented 3 years ago

Yeah... all that would change there would be the preinstalled OctoPrint version then, no need for a lengthy RC phase for that. Right now the testing of 0.18.0 is really more to iron out any kind of issues with the new base image and any changes done to OctoPi outside of OctoPrint, as far as I see it.

cp2004 commented 3 years ago

Sending an M997 command... @sohxet

Could this be related to https://github.com/OctoPrint/OctoPrint/issues/3683 since OctoPi 0.18 is likely now pulling in this upstream kernel update?

XRyu commented 3 years ago

is it possible the arm64 does not come with raspi cam support?

i am running it on a Raspberry Pi 4 4GB

Starting up webcamDaemon...

--- Configuration: ----------------------------
cfg_file:      /boot/octopi.txt
camera:        raspi
usb options:   -r 640x480 -f 10
raspi options: -fps 10
http options:  -w ./www-octopi -n --listen 127.0.0.1

Explicitly USB device:
-----------------------------------------------

Found video devices:
/dev/video0
/dev/video10
/dev/video11
/dev/video12
/dev/video13
/dev/video14
/dev/video15
/dev/video16
raspi
config file='/boot/octopi.txt':Start MJPG-streamer with video device: raspi
<13>Nov 11 17:42:15 root: Starting Raspberry Pi camera
Checking for VL805 (Raspberry Pi 4)...
  - It seems that you don't have VL805 (Raspberry Pi 4).
    There should be no problems with USB (a.k.a. select() timeout)
Running ./mjpg_streamer -o output_http.so -w ./www-octopi -n --listen 127.0.0.1 -i input_raspicam.so -fps 10
MJPG Streamer Version: git rev: 85f89a8c321e799fabb1693c5d133f3fb48ee748
ERROR: could not find input plugin
       Perhaps you want to adjust the search path with:
       # export LD_LIBRARY_PATH=/path/to/plugin/folder
       dlopen: input_raspicam.so: cannot open shared object file: No such file or directory
Done bring up all configured video device

Goodbye...
sohxet commented 3 years ago

Sending an M997 command... @sohxet

Could this be related to OctoPrint/OctoPrint#3683 since OctoPi 0.18 is likely now pulling in this upstream kernel update?

That sounds exactly like my problem. I'll try to get any useful information from the pi and open a ticket upstream.

rbrian commented 3 years ago

Are there any known backup./restore issues? i have a backup from my octoprint before the upgrade, and trying to restore it I get the "Uploading please wait" dialog for at least 12 hours. Not going to let it go any further, will be easier to just redo things from scratch.

edit: running 18rc x64 on a pi4 4gb

Will-wastelander commented 3 years ago

I have been having random drops where the system becomes inaccessible all together via SSH and WebGUI, but OctoDash is still able to access it ? When connecting via hardwire, no DHCP is pulled at all. I do not have a HDMI connected to it, but I do have a 7" screen, ask I am running OctoDash as previously mentioned.

What info can I provide to assist with trouble shooting ?

rPi 4 4GB,, OctoPi 0.18.0 RC1 armhf, OctoDash 2.1.1, 7" DSI screen. This is the 3rd time it has happened in 24 hours. However my OctoPi 0.17.0 armhf, and 0.18.0 arm64 seem to be working fine. 0.17.0 I have no issues w/ network drops at all on the same system(s).

Will-wastelander commented 3 years ago

Plugging in a Wireless USB kb/mouse appears to do nothing also. ctrl-alt-del does nothing, ctrl-c does nothing.

CRCinAU commented 3 years ago

64bit amd64/aarch64

I'm sure you mean: 64bit arm64/aarch64?

Also, nice:

$ dmesg | grep Rasp
[    0.000000] Machine model: Raspberry Pi 4 Model B Rev 1.2
pi@ender3v2:~ $ cat /proc/version 
Linux version 5.4.72-v8+ (dom@buildbot) (gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)) #1356 SMP PREEMPT Thu Oct 22 13:58:52 BST 2020

I don't have a webcam on this one - but it booted via USB etc fine - so that's a great sign.

Once my other one has finished printing, I'll do the upgrade on that too.... If you hear nothing back from me, the second one will be fine too...

One is a Pi 4 4Gb, the other a Pi 4 2Gb 4Gb as well...

guysoft commented 3 years ago

I'm sure you mean: 64bit arm64/aarch64?

Yea my bad, fixed. Its really a pain that its only one letter difference.

CRCinAU commented 3 years ago

Its really a pain that its only one letter difference.

Hahahah - tell me about it - that's why I call things aarch64 and x86_64 - even though debian loves to use amd64 :\

CRCinAU commented 3 years ago

Hmmm - here we go - trying to use the HLS webcam stuff:

Nov 12 09:02:07 ender3.local ffmpeg[2381]: [h264_omx @ 0x558d4d4870] libOMX_Core.so not found
Nov 12 09:02:07 ender3.local ffmpeg[2381]: [h264_omx @ 0x558d4d4870] libOmxCore.so not found
Nov 12 09:02:07 ender3.local ffmpeg[2381]: Error initializing output stream 1:0 -- Error while opening encoder for output stream #1:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Nov 12 09:02:07 ender3.local ffmpeg[2381]: [video4linux2,v4l2 @ 0x558d4c9de0] Some buffers are still owned by the caller on close.
Nov 12 09:02:07 ender3.local ffmpeg[2381]: Conversion failed!
Nov 12 09:02:07 ender3.local systemd[1]: ffmpeg_hls.service: Main process exited, code=exited, status=1/FAILURE
Nov 12 09:02:07 ender3.local systemd[1]: ffmpeg_hls.service: Failed with result 'exit-code'.
guysoft commented 3 years ago

@chudsaviet any insight on this? ^

rbrian commented 3 years ago

Getting a black rectangle where the Pi cam is supposed to display. Worked fine in previous versions. Not sure where a log would be that would have any info.

chudsaviet commented 3 years ago

@CRCinAU , looks like it can’t find RaspberryPi hardware encoder libraries. In RaspberryPiOS they are supposed to be installed as dependencies of ffmpeg. Are you using the 64 bit version? I have never tested on it, my patches were submitted before 64 bit version was added.

XRyu commented 3 years ago

on armhf version raspi camera works fine with mjpeg streamer. on arm64 i failed with the errors mentioned earlier :)

CRCinAU commented 3 years ago

@CRCinAU , looks like it can’t find RaspberryPi hardware encoder libraries. In RaspberryPiOS they are supposed to be installed as dependencies of ffmpeg. Are you using the 64 bit version? I have never tested on it, my patches were submitted before 64 bit version was added.

Yeah - this is on the 64 bit version.

The MJPEG streaming works fine.

Will-wastelander commented 3 years ago

Is anyone else getting random wifi drops w/ armhf ? It happens to me about every other day right now.. It's actually not dropping, it appears that this is a full hung, since eth0 doesn't pull DHCP either. @guysoft What info can I pull to provide details for this type of hang ?

foosel commented 3 years ago

I observed something that felt like a WiFi drop earlier this week during the final update tests for 1.5.0rc1, but I was under a deadline and thus couldn't investigate what it was.

Just putting it out there that yes, saw something that could qualify.

It reminded me of the times when wifi power management was broken and the devices would just shut down WiFi.

32bit image.

Will-wastelander commented 3 years ago

Gina,

This is more like a system hang. As eth0 doesn't pull dhcp when a network cable is connected during this issue. The rPi is in an enclosure, but temps are 117f max from what I have seen so far. That temp shouldn't cause any issues, that I know of. I dont have any output of an error on my DSI connected screen, running OctoDash 2.1.1 either.

On Fri, Nov 13, 2020, 22:29 Gina Häußge notifications@github.com wrote:

I observed something that felt like a WiFi drop easier this week during the final update tests for 1.5.0rc1, but I was under a deadline and this couldn't investigate what it was.

Just putting it out there that yes, saw something that could qualify.

It reminded me of the times when wifi power management was broken and the devices would just shut down WiFi.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/guysoft/OctoPi/issues/692#issuecomment-727154243, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARBZ5N36WGUYRJXLFZYVXQDSPYPVJANCNFSM4TKAJHTA .

foosel commented 3 years ago

As I said, I didn't have time to investigate. No chance to test wired either. I can confirm one incidence of "pi connected via WiFi no longer responded to pings", a reboot fixed it.

Will-wastelander commented 3 years ago

Gina,

Correct, reboot resolves issue. Is there anything I can look at for logs, etc to provide to assist with trouble shooting ?

On Fri, Nov 13, 2020, 22:52 Gina Häußge notifications@github.com wrote:

As I said, I didn't have time to investigate. No chance to test wired either. I can confirm one incidence of "pi connected via WiFi no longer responded to pings", a reboot fixed it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/guysoft/OctoPi/issues/692#issuecomment-727156735, or unsubscribe https://github.com/notifications/unsubscribe-auth/ARBZ5N4XIZ5FGMKZSMCOEH3SPYSMFANCNFSM4TKAJHTA .

nes-jisc commented 3 years ago

I have been having random drops where the system becomes inaccessible all together via SSH and WebGUI, but OctoDash is still able to access it ? When connecting via hardwire, no DHCP is pulled at all. I do not have a HDMI connected to it, but I do have a 7" screen, ask I am running OctoDash as previously mentioned.

What info can I provide to assist with trouble shooting ?

rPi 4 4GB,, OctoPi 0.18.0 RC1 armhf, OctoDash 2.1.1, 7" DSI screen. This is the 3rd time it has happened in 24 hours. However my OctoPi 0.17.0 armhf, and 0.18.0 arm64 seem to be working fine. 0.17.0 I have no issues w/ network drops at all on the same system(s).

I have seen this same issue with my wifi connected Pi. Octodash continues to work, printing continues but no connection to octoprint web interface or SSH. I am switching to a wired connection to see if this makes any difference.

chudsaviet commented 3 years ago

FYI guys, I'm investigating HLS-on-arm64 issues. This isn't forgotten :)

nes-jisc commented 3 years ago

Wired connection seems stable

chudsaviet commented 3 years ago

Regarding HLS-on-arm64:

  1. There are no VideoCore libraries in /opt/vc/lib. Fixes by rpi-update, not by Apt, because these are proprietary-ish libraries.
  2. FFMpeg is built with different flags by default. It needs to have --enable-omx-rpi to work with h264_omx encoder on Rpi.

I tried to build from source, but it couldn't find the libraries despite they were existing. Will continue work later.

mordhau5 commented 3 years ago

Does anyone know if Python2 is removed at the system level?

chudsaviet commented 3 years ago

@mordhau5 , even if it is, you can always install it from APT.

mordhau5 commented 3 years ago

@chudsaviet true, I guess my real question is if it's going to keep being supported by raspbian, but there's no way they'd pull that so soon.

guysoft commented 3 years ago

Python 2 has reached end-of-life on the start of 2020. So it will not eventually https://www.python.org/doc/sunset-python-2/

mordhau5 commented 3 years ago

@guysoft yep. Hopefully Klipper team makes moves on this before raspbian drops it completely.

chudsaviet commented 3 years ago

Created bug https://github.com/guysoft/OctoPi/issues/697 to track HLS-on-arm64 issues.

dualznz commented 3 years ago

Stable on Pi 4 8gb 32-Bit

guysoft commented 3 years ago

@chudsaviet Is this a show stopper for 0.18.0? Do you think you can fix it and we shall release an RC2?