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.47k stars 367 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

chudsaviet commented 3 years ago

@guysoft , I don’t think its a show stopper. We are advertising HLS as experimental, so the fact its not working on arm64 is not blocking the release I think.

jneilliii commented 3 years ago

@guysoft with the release of octoprint 1.5.0 right around the corner, maybe we should have an rc2 round with that version once it comes out stable and then go stable with 0.18 shortly after?

Will-wastelander commented 3 years ago

Is there any update on what is causing the wifi to completely stop working on the ARM64 build ? I've offered to provide info, but no one has provided me details on how to get the info that would be needed.

guysoft commented 3 years ago

@Will-wastelander Currently I am not sure how to debug this at all. It might be worth reporting to https://github.com/raspberrypi/linux . But I doubt they will take anything under condiration with out some for of log. Perhaps the output of dmesg after the network is down should be enough to understand what is going on.

You can save dmesg to a file using dmesg > /home/pi/dmesg.log with a screen and keyboard attached, and then reboot, copy it off and send.

Will-wastelander commented 3 years ago

@Guysoft thats will be impossible to do, as plugging in a keyboard and mouse doesn't work. Once the system is hung, there is nothing I can do, other than reboot. I will try to do this again, but the last 3 times I tried, nothing worked.

On Mon, Nov 30, 2020, 06:22 Guy Sheffer notifications@github.com wrote:

@Will-wastelander https://github.com/Will-wastelander Currently I am not sure how to debug this at all. It might be worth reporting to https://github.com/raspberrypi/linux . But I doubt they will take anything under condiration with out some for of log. Perhaps the output of dmesg after the network is down should be enough to understand what is going on.

You can save dmesg to a file using dmesg > /home/pi/dmesg.log with a screen and keyboard attached, and then reboot, copy it off and send.

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

Will-wastelander commented 3 years ago

@guysoft I also don't seem to have the issue w/ my rasbianos arm64 systems.

ideal2545 commented 3 years ago

This has been working really well for me, any word on when its going offiical release?

gdombiak commented 3 years ago

Successfully tested HLS using OctoPi 0.18.0 RC1 (32 bits) and OctoPrint 1.5.0 (released version). I was able to see the camera in OctoPrint webUI and also in OctoPod (unreleased version). However, I noticed something that wanted to bring up here in case it was not discussed before.

I'm using a Raspberry Pi 3 Model B Plus Rev 1.3 with a single OctoPrint instance (no plugins) running and using a RPi camera v2. CPU usage is extremely high and OctoPrint is doing nothing. It is not even connected to a printer. I have no client connected to OctoPrint and nothing is connected to the camera. CPU idle seems to be at 67% so might not such an issue?

Screen Shot 2020-11-30 at 11 13 25 PM

Is there a warning somewhere indicating that using HLS with a RPi 3 might have an impact on print quality when printing from OctoPrint? I have not tested this so cannot confirm that it will have an impact. However such high CPU usage (with minimal load) makes me wonder how much CPU is going to be left for OctoPrint and potential impact when printing from OctoPrint.

I purchased a couple RPi 4 where I will have this setup for my local "farm" of printers. Having a more powerful CPU, I anticipate that it should not be an issue with RPi 4.

Anyway, too long of a post to ask: Has anyone tested HLS with RPi 3B (+?) and printed from OctoPrint? Have you observed any impact on print quality? Is there value adding a warning that RPi 4 is recommended when enabling HLS?

Thanks, Gaston

jneilliii commented 3 years ago

I think that's why it's labeled as experimental. I too am running this combination and have only printed once since enabling hls and did not see any print quality issues, but it was a simple print.

chudsaviet commented 3 years ago

Hi, @gdombiak . Its nice to see people start testing HLS feature :) Unfortunately, high CPU usage is not going to go anywhere. Even with the fact we are using hardware h264 encoder, significant CPU is required, both for HLS and high FPS JPEG encoding (there is a side JPEG stream for timelapses). Good news are that 122% in ‘top’ on a 4-core machine is not a very high usage. Your capacity is 400%. Moreover, we run FFmpeg with lower process priority, so its supposed not to displace OctoPrint. On the other side, Linux is not a real time OS, so its not guaranteed.

Please, try to do test prints with Rpi3, the community will be really glad if you do some real life testing. :)

gdombiak commented 3 years ago

@chudsaviet, thanks for sharing that info. That feels better knowing that it runs with a lower priority. When I monitored a while while while back CPU usage when using MJPEG (when I installed multiple webcams on the same RPi 2) I noticed that if no one was watching the camera then there was no CPU impact/usage. I was expecting to see something similar with HLS. Anyway, once I released the new version of OctoPod (iOS, AppleWatch and AppleTV) with HLS support I will go back to printing and test how things work.

@jneilliii hey man! Nice to see you around this repo as well! :) When I read that it was experimental I assumed that it might break/fail. If we confirm that it introduced print quality issues (based on @chudsaviet comment I would expect to NOT be the case) then a more explicit warning might be needed or maybe a recommended hardware requirements message might help. Anyway, I'm getting ahead of ourselves. First let's confirm this is an actual issue.

rmeissn commented 3 years ago

Just wanted to let you know, even though it's not supported officially, that a Raspi 1 B+ isn't booting. It takes ages until the login service is started (still no login prompt) and keeps accessing the sd card a lot (not happening on 0.17). Even though it's not supported for performance reasons it should still boot up, right? EDIT: Sorry, it's a Raspi 1 B with 256MB RAM

guysoft commented 3 years ago

@rmeissn It should, could you take a look at the output of top see if something his hogging the CPU? It might be that the move to python 3 made it go slower. Also what class is your SD card?

rmeissn commented 3 years ago

I've got a 16GB Sandisk Ultra SDHC Class 10, rated at 80MB/s. That card works perfectly for all other images, including Octopi 0.17 (tested after 0.18rc1 failed). Actually there is no top available. It won't boot up to a login prompt (attached to a display) and hasn't registered in my local network yet - no IP, no SSH. The boot process seems to work fine until "LSB: Switch to ondemand governor ...". After that it gets slimy slow. The network leds are turned on, but there is no device showing up in the network. The sd-card led is constantly turned on since >40min. There is no difference if I try to boot without the network cable. EDIT: nightly build shows the same issue

I've booted for >45min. See the pictures below: IMG_20201203_131927__01 IMG_20201203_131936__01

guysoft commented 3 years ago

@rmeissn Strange, its halted on "started daily download archives" I would guess that its crashing because of a network issue. I see you have the ethernet plugged in, so its not wifi/usb stuff:

Searching brings up this. Putting as refrence: https://github.com/MichaIng/DietPi/issues/1330

If you can try this from a working Pi and then boot, we will see if that is what is causing the issue:

systemctl stop apt-daily.timer
systemctl disable apt-daily.timer
systemctl mask apt-daily.service
systemctl daemon-reload

Source: https://gist.github.com/noromanba/6e062d38fd7fd2cd609a6ef1c26ea7bc

rmeissn commented 3 years ago

Unfortunately I don't have another Pi around (yet)... Maybe someone else might have a newer one to test this. From experimenting with tweaking 0.17 for the Pis low RAM amount I ended up having the same issue if a) I reduced the gpu_mem to below 32mb and b) if the Pi is lifting heavy work on startup, thus swaps a lot and runs into low mem (mem and swap full) on boot.

kennethjiang commented 3 years ago

@guysoft @chudsaviet I just opened an issue #702 before I realized you guys are already discussing it here in this issue. Feel free to close that one or leave it open. I'll subscribe to this issue too.

Let me know if there is anything I can do to here with this issue.

guysoft commented 3 years ago

Considering an RC2 with the new RpiOS release, and OctoPrint 1.5.2. Also if the HLS stuff can be fixed, @chudsaviet would that help you?

cp2004 commented 3 years ago

@guysoft I would vote for the latest OctoPrint image when you release, if this means an RC2 I vote for this too.

If you look at the shiny new https://data.octoprint.org/, you can see that a significant number of users stay on 1.3.12, which is more used than 1.4.0 at the moment. I also see on the forums etc. people using 1.3.12 and we have to ask them to install latest, but they are confused, since they just downloaded it.

I might also ask/suggest that when it is published, we strongly recommend the 32 bit build, since while it is stable for many there are still more issues that I see around forums/discord that are 64 bit only (mostly the webcam stuff, which you are aware of I think), and are solved when we suggest trying 32bit.

kennethjiang commented 3 years ago

+1 for recommending the 32-bit build, which doesn't have the libmmal.so issue.

chudsaviet commented 3 years ago

@guysoft , lets keep HLS-on-arm64 for next release because of next reasons:

  1. Switching to ‘v4l2m2m’ is a switching to a new encoder API. It doesn't seem like a fix, more like a feature. It will need a ton of fine tuning.
  2. arm64 build seems to be experimental in this release.
  3. I have to setup my workflow for arm64 builds, and it will take time.
  4. Cyberpunk 2077 is released.
guysoft commented 3 years ago

Ok, seems like everyone is voting for releasing this, and I will amend the known issues. And then prep a next release with fixes. @foosel your with that too?

foosel commented 3 years ago

I read it that most here vote for a second release candidate with the latest OctoPrint release, which is 1.5.2 as of writing this. The first RC still has 1.4.2. So 0.18.0rc2.

My vote would also be for a second RC for 0.18, and recommending the 32bit build because the 64 one still seems to be too fundamentally buggy (due to the base images being buggy).

I'm not sure whether this second RC should be based on the former image or the recent one, given that you mentioned that latest image breaking some stuff.

guysoft commented 3 years ago

@foosel Ok then!

nimbo78 commented 3 years ago

how about orange pi zero2 support?

guysoft commented 3 years ago

@nimbo78 If someone helps me maintain the images sure. There is an armbian variant that needs someone to take care of it. Not this release but next one.

antoneliasson commented 3 years ago

I've installed the 32-bit version of 0.18.0 RC1 on a RPi 4 (4 GB) as a new installation, no configuration restore. Immediately after boot systemctl status shows the system as degraded with one failed service. It's webcamd (I don't have a camera connected to the RPi):

pi@octopi:~ $ systemctl status webcamd
● webcamd.service - the OctoPi webcam daemon with the user specified config
   Loaded: loaded (/etc/systemd/system/webcamd.service; enabled; vendor preset: enabled)
   Active: failed (Result: start-limit-hit) since Thu 2020-08-20 11:47:51 BST; 6min ago

Aug 20 11:47:51 octopi systemd[1]: webcamd.service: Service RestartSec=100ms expired, scheduling restart.
Aug 20 11:47:51 octopi systemd[1]: webcamd.service: Scheduled restart job, restart counter is at 8.
Aug 20 11:47:51 octopi systemd[1]: Stopped the OctoPi webcam daemon with the user specified config.
Aug 20 11:47:51 octopi systemd[1]: webcamd.service: Start request repeated too quickly.
Aug 20 11:47:51 octopi systemd[1]: webcamd.service: Failed with result 'start-limit-hit'.
Aug 20 11:47:51 octopi systemd[1]: Failed to start the OctoPi webcam daemon with the user specified config.

The setup wizard hanged for about 5 minutes after clicking Enable Anonymous Usage Tracking. During this time journalctl showed a few slightly different instances of this error because my RPi does not have internet access (the time on my RPi is not set correctly so the timestamps are wrong):

Aug 20 11:49:46 octopi octoprint[300]: 2020-08-20 11:49:46,274 - octoprint.plugins.announcements - ERROR - Could not fetch channel _blog from https://octoprint.org/feeds/octoblog.xml
Aug 20 11:49:46 octopi octoprint[300]: Traceback (most recent call last):
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connection.py", line 160, in _new_conn
Aug 20 11:49:46 octopi octoprint[300]:     (self._dns_host, self.port), self.timeout, **extra_kw
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/util/connection.py", line 84, in create_connection
Aug 20 11:49:46 octopi octoprint[300]:     raise err
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/util/connection.py", line 74, in create_connection
Aug 20 11:49:46 octopi octoprint[300]:     sock.connect(sa)
Aug 20 11:49:46 octopi octoprint[300]: socket.timeout: timed out
Aug 20 11:49:46 octopi octoprint[300]: During handling of the above exception, another exception occurred:
Aug 20 11:49:46 octopi octoprint[300]: Traceback (most recent call last):
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connectionpool.py", line 677, in urlopen
Aug 20 11:49:46 octopi octoprint[300]:     chunked=chunked,
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connectionpool.py", line 381, in _make_request
Aug 20 11:49:46 octopi octoprint[300]:     self._validate_conn(conn)
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connectionpool.py", line 978, in _validate_conn
Aug 20 11:49:46 octopi octoprint[300]:     conn.connect()
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connection.py", line 309, in connect
Aug 20 11:49:46 octopi octoprint[300]:     conn = self._new_conn()
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connection.py", line 167, in _new_conn
Aug 20 11:49:46 octopi octoprint[300]:     % (self.host, self.timeout),
Aug 20 11:49:46 octopi octoprint[300]: urllib3.exceptions.ConnectTimeoutError: (<urllib3.connection.HTTPSConnection object at 0xb14f6690>, 'Connection to octoprint.org timed out. (connect timeout=30)')
Aug 20 11:49:46 octopi octoprint[300]: During handling of the above exception, another exception occurred:
Aug 20 11:49:46 octopi octoprint[300]: Traceback (most recent call last):
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/requests/adapters.py", line 449, in send
Aug 20 11:49:46 octopi octoprint[300]:     timeout=timeout
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/connectionpool.py", line 727, in urlopen
Aug 20 11:49:46 octopi octoprint[300]:     method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/urllib3/util/retry.py", line 446, in increment
Aug 20 11:49:46 octopi octoprint[300]:     raise MaxRetryError(_pool, url, error or ResponseError(cause))
Aug 20 11:49:46 octopi octoprint[300]: urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='octoprint.org', port=443): Max retries exceeded with url: /feeds/octoblog.xml (Caused by ConnectTimeoutError(<urllib3.connection.HTTPSConnection object at 0xb14f6690>, 'Connection to octoprint.org timed out. (connect timeout=30)'))
Aug 20 11:49:46 octopi octoprint[300]: During handling of the above exception, another exception occurred:
Aug 20 11:49:46 octopi octoprint[300]: Traceback (most recent call last):
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/plugins/announcements/__init__.py", line 384, in _get_channel_data_from_network
Aug 20 11:49:46 octopi octoprint[300]:     r = requests.get(url, timeout=30)
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/requests/api.py", line 76, in get
Aug 20 11:49:46 octopi octoprint[300]:     return request('get', url, params=params, **kwargs)
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/requests/api.py", line 61, in request
Aug 20 11:49:46 octopi octoprint[300]:     return session.request(method=method, url=url, **kwargs)
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/requests/sessions.py", line 530, in request
Aug 20 11:49:46 octopi octoprint[300]:     resp = self.send(prep, **send_kwargs)
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/requests/sessions.py", line 643, in send
Aug 20 11:49:46 octopi octoprint[300]:     r = adapter.send(request, **kwargs)
Aug 20 11:49:46 octopi octoprint[300]:   File "/home/pi/oprint/lib/python3.7/site-packages/requests/adapters.py", line 504, in send
Aug 20 11:49:46 octopi octoprint[300]:     raise ConnectTimeout(e, request=request)

Other than that the setup wizard went through fine.

antoneliasson commented 3 years ago

I set the printer build volume to 250x210x210 mm XYZ during the setup wizard (for a Prusa i3 MK3S). Next I downloaded the original Marvin from https://www.thingiverse.com/thing:215703/files and sliced it using PrusaSlicer 2.2.0 for Prusa i3 MK3S with the built-in profile 0.30mm DRAFT. I'm attaching the gcode. After uploading it and selecting it for printing I get this warning:

Object doesn't fit print volume

Object in 20140205_Marvin_KeyChain(1)_0.3mm_PLA_MK3S_24m.gcode exceeds the print volume of the currently selected printer profile, be careful when printing this.
More

You can disable this check via Settings > Features > "Enable model size detection [...]"

journalctl shows the following which might be relevant:

Aug 20 12:28:04 octopi octoprint[367]: 2020-08-20 12:28:04,495 - octoprint.filemanager.analysis - INFO - Starting analysis of local:20140205_Marvin_KeyChain(1)_0.3mm_PLA_MK3S_24m.gcode
Aug 20 12:28:04 octopi octoprint[367]: 2020-08-20 12:28:04,496 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python3 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/20140205_Marvin_KeyChain(1)_0.3mm_PLA_MK3S_24m.gcode
Aug 20 12:28:04 octopi haproxy[717]: ::ffff:192.168.1.5:52602 [20/Aug/2020:12:28:04.427] public octoprint/octoprint1 0/0/0/102/103 201 1233 - - ---- 2/2/1/1/0 0/0 "POST /api/files/local HTTP/1.1"
Aug 20 12:28:04 octopi octoprint[367]: grep: Invalid content of \{\}
Aug 20 12:28:04 octopi haproxy[717]: ::ffff:192.168.1.5:52602 [20/Aug/2020:12:28:04.547] public octoprint/octoprint1 0/0/0/365/366 200 41136 - - ---- 2/2/1/1/0 0/0 "GET /api/files?recursive=true HTTP/1.1"
Aug 20 12:28:07 octopi octoprint[367]: 2020-08-20 12:28:07,456 - octoprint.filemanager.analysis - INFO - Analysis of entry local:20140205_Marvin_KeyChain(1)_0.3mm_PLA_MK3S_24m.gcode finished, needed 2.96s

The gcode contains a number of { and } in comments that grep might be choking on. I ignored the warning and the print started and finished successfully.

20140205_Marvin_KeyChain(1)_0.3mm_PLA_MK3S_24m.zip

guysoft commented 3 years ago

@antoneliasson The first error is that the intenret is not working and not reaching octoprint.org. Second one I am not sure. Looks like an OctoPrint issue.

antoneliasson commented 3 years ago

Thanks for the reply. I would expect the setup to not hang if it is unable to reach the internet but rather fail gracefully. I don't know if that is a bug in Octoprint or in Octopi.

webcamd failing is no big issue, I just expect all services to succeed (or avoid starting if preconditions are not met) on a healthy system.

I managed to reproduce the print volume warning on Octoprint 1.5.2 running on plain Raspbian Buster, so that is definitely not an issue in Octopi. I will write a separate bug report against Octoprint for that in the next few days.

cp2004 commented 3 years ago

@antoneliasson Re. connection error: did you enable the connectivity check? The reason it is there is to prevent problems like yours. If you did enable the connection check, it failed and then still tried to connect to the internet that is a bug and should be reported to OctoPrint as such.

Re. analysis error: As is (by the looks of things) the analysis one, but without the full bug report I am not going to try and figure out where it came from.

Re. webcamd: I don't know if there is a way to start webcamd, have it do its whole try-and-detect the camera & load the config, attempt to start and then show as 'succeeded', when it hasn't really started, because it couldn't find a camera.

antoneliasson commented 3 years ago

The option to enable the connectivity check is on the screen after the anonymous usage tracking screen so at that stage of the setup wizard I didn't have a way to enable it. Perhaps the screens should switch place? I tried it again on a newly imaged 0.18 RC1 (32-bit) and the time it was stuck after enabling usage tracking this time was around 45 seconds. I can't be sure now whether the 5 minutes that I gave two days ago was correct.

On webcamd: I looked at /root/bin/webcamd more closely and yes, that seems to be non-trivial especially since it can use two completely different camera interfaces (MMAL and V4L2).

cp2004 commented 3 years ago

I'll see if we can get the connectivity check screen to show first - that would eliminate the hanging time since it would not try at all if connectivity check was offline.

cp2004 commented 3 years ago

Looks like the script to install desktop on 64 bit image doesn't work, couple of reports on the community forum I wanted to link to you @guysoft in case you hadn't seen them:

https://community.octoprint.org/t/desktop-install-didnt-work-no-monitor-output/27469?u=charlie_powell

https://community.octoprint.org/t/octoprint-on-a-pi4-8gb/20670/186?u=charlie_powell

and I believe someone has asked this question on discord too, since that prompted my reply to the 1st link above to ask about 64/32 bit.

adegenaar 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 :).

Try this video https://www.youtube.com/watch?v=K0A-sIUBFfU Chris explicitly goes over settings up a multi-instance using 0.18

gunnarx commented 3 years ago

FYI in 62eabbf you forgot to change README.rst because it still suggests that Cura is pre-installed. ref #654

bvrielink commented 3 years ago

As Python 2 is now unsupported I want to start using 0.18 for some testing. Is RC2 already released? If not would it better to use the latest nightly or use RC1? TIA.

guysoft commented 3 years ago

@bionik If you want to test python3 RC1 should be enough. I am investigating RC2 using Ubuntu for only 64bit today/during this week and will decide if its worth releasing an experimental with it for RC2, since Rpi Foundation are saying that they are not maintaining a 64bit build.

CRCinAU commented 3 years ago

Rpi Foundation are saying that they are not maintaining a 64bit build.

That's a bit weak on their part..... given that 64 bit is quite a lot faster than the 32 bit OS on the same hardware...

cp2004 commented 3 years ago

Experimental 64 bit build sounds like the way to go then. Shame Raspberry Pi Foundation didn't want to do it. To be honest, their initial blog post never really seemed like they thought it had much benefit, it never sounded keen.

From a community perspective, supporting two different base distros would be a bit of a pain, so maybe if the experiment proves successful, would it be worth switching the 32 bit to (I assume) ubuntu server? It's a massive shift, and probably quite a lot of work for you to adapt all the scripts etc, appreciate all of that. We will wait and see if there is an improvement to not using Raspberry Pi OS images. One downside I did think of is it may be slower to support new RPi boards that come out, as opposed to the RPiOS images which have to be compatible when they first go on sale.

guysoft commented 3 years ago

@cp2004 Yes that is what I am thinking too. I will want to hear @foosel thoughts, but frankly Rpi foundation have an unorganized release cycle which has been giving us a hard time here, we never know if something will come out. For example RC1 came out here and then they released an image at the start of December, a month after. Ubuntu has defined release dates so we can match them. I would have also loved to use the Debian Rpi builds. But their approach is to have an image for every machine. And I really rather have 2 images to maintain.

But again, I am starting this as a 64bit experiment for RC2, and we will see how it goes from there.

chudsaviet commented 3 years ago

I would like to oppose moving away from RaspberryPi OS because of possible issues with cameras/encoders support. RaspberryPi OS is still the official supported OS.

guysoft commented 3 years ago

@chudsaviet That is why I have been keeping it. However, it seems like now I also have the potability to build OctoPi for Ubuntu too. Having this time where there is no 64bit Raspberrypi OS might be a good time to test this argument. The kernel should be the same kernel so cameras/encoders support. But we won't know until we put it out there for people to test and report. @foosel would value your input before I release an RC2 with this.

CRCinAU commented 3 years ago

RaspberryPi OS is still the official supported OS.

If they don't support a 64bit OS, is it?

guysoft commented 3 years ago

@foosel Says we also need support for vcgencmd. So I need to install the PPAs at: https://wiki.ubuntu.com/ARM/RaspberryPi Can try add that too.

foosel commented 3 years ago

Especially vcgencmd get_throttled, because otherwise no undervoltage warnings by OctoPrint on the image and that would mean a support nightmare.

chudsaviet commented 3 years ago

@guysoft , I do see a lot of extra steps needed to make Ubuntu build usable - https://wiki.ubuntu.com/ARM/RaspberryPi . And I predict even more steps I don’t see. Actually, I don’t think having a officially supported 64bit release is worth all the hassle. I think Raspberry PI OS will fully support arm64 eventually. They have 8 gb RAM boards anyway, and I don't think they will abandon them. Lets just call our 64bit release experimental until RaspberryPi OS 64bit is called experimental. I will make HLS work on it. Its just my opinion, @guysoft snd @foosel are the bosses :)

foosel commented 3 years ago

After taking a closer look at that wiki node, I agree. We already have enough support hassle, we don't need to make things worse by trying to enforce a stable 64bit build.

My vote: ignore 64bit outside of nightlies until Raspbian declares the base image stable. Push out an rc2 with OctoPrint 1.5.2 asap.

gdombiak commented 3 years ago

@foosel that is a practical comment! Well said. ROI is not there for 64bit. It has high chances of creating more headache/support/issues than benefit of running in 64bit. I've been using RC1 32 bit and it is pretty solid and meets the needs. I bet that will be enough for 99% of our community.

4wrxb commented 3 years ago

Note: these comments are based on the assumption that the recommend upgrade path for non-expert OctoPi uses to move to Python 3 will be do a new install of v0.18. With this being the case I would expect a greater user-base wanting to restore backups when installing the released v0.18 over time (as more extension etc. begin to rely on Python 3). If there's a plan to provide (non-expert user) Python 3 upgrade capabilities w/in previous OctoPi installs then it would be safe to assume that the backup restore path remains an expert-usage case.

From a use-ability standpoint it would be helpful to offer to update the Octopi server at the beginning of the set-up wizard since this is required in order to restore a backup (if there is a version mismatch). I know folks should be comfortable enough with SSH access to log-in and change the default password and thus would be able to run a simple pip command to update octopi, but the extra hurdle seems unnecessary.

At the very least, in order to avoid support requests from the google-challenged, I would have the UI link here: https://community.octoprint.org/t/how-can-i-update-the-octoprint-installation-on-my-octopi-image/207