OctoPrint / OctoPrint

OctoPrint is the snappy web interface for your 3D printer!
https://octoprint.org
GNU Affero General Public License v3.0
8.15k stars 1.67k forks source link

[RC Feedback] Feedback on the 1.8.0rc1 Release Candidate #4452

Closed foosel closed 2 years ago

foosel commented 2 years ago

Please provide general feedback on your experience with the 1.8.0rc1 Release Candidate here. An "All is working fine" is valuable feedback as well, because it tells me that people in fact are testing the RC and just not finding any problems. Thanks :)

If you run into any obvious bugs not yet listed below the following line, please open a new ticket and follow "How to file a bug report". I need full bug reports, not just a statement that something doesn't work!


Update test matrix

image

✔ = expected to work, ❌ = expected to fail, ☑ = successfully completed. Releases aren't rolled out unless all tests in the update test matrix succeed.


Currently known issues

Unreproduced issues

Unreproduced and information for further analysis missing

Third party issues

Issues needing analysis

pingywon commented 2 years ago

Upon update the pi comes back up and now I get a 500 error and cannot access the GUI at all.

foosel commented 2 years ago

Please try a shift reload in case that is some weird caching issue. If that doesn't help, please submit a full bug report.

jneilliii commented 2 years ago

Had one instance update fine, had another instance not do so well with the following when I try to manually start octoprint via ~/oprint/bin/octoprint serve. Will try to grab more details later today as I have to get to work right now.

pi@flsun:~ $ ./oprint/bin/octoprint serve
2022-03-14 08:41:05,384 - octoprint.startup - CRITICAL - Could not initialize settings manager: can only concatenate str (not "int") to str
2022-03-14 08:41:05,384 - octoprint.startup - CRITICAL - There was a fatal error starting up OctoPrint.
Could not initialize settings manager: can only concatenate str (not "int") to str
There was a fatal error starting up OctoPrint.
pingywon commented 2 years ago

What were you doing?

  1. update to 1.8.0
  2. after reboot web GUI give me a 500 error

What did you expect to happen?

a successful upgrade

What happened instead?

an unsuccessful upgrade and a 500 error on the web GUI

Did the same happen when running OctoPrint in safe mode?

Tested in safe mode and thing appear to work as expected. It is indeed a 3rd party plugin crashing it. I know you dont want plugin bugs here, but maybe with it being an RC you do.

Version of OctoPrint

1.8.0

Printer model & used firmware incl. version

Raise 3D Pro2 Plus

Browser and version of browser, operating system running browser

debian desktop and windows 10

System Info Bundle

included.

Im not sure how to figure out what plugin is crashing the non-safe mode boot.

octoprint-systeminfo-20220314124301.zip

I have read the FAQ.


Bundles:

edited by @github-actions to add bundle viewer links

pingywon commented 2 years ago

Octo Boot Log Error: 2022-03-14 12:48:43,445 - octoprint.plugins.raisecloud - INFO - Raisecloud connecting ... 2022-03-14 12:48:43,570 - octoprint.plugins.tracking - INFO - Sent tracking event ping, payload: {'octoprint_uptime': 20, 'printer_state': 'OFFLINE'} 2022-03-14 12:48:44,280 - octoprint.server.preemptive_cache - INFO - Preemptively caching / (ui _default) for {'base_url': 'http://192.168.0.136/', 'path': '/', 'query_string': 'l10n=en'} 2022-03-14 12:48:44,806 - octoprint.server.util.sockjs - INFO - User pingywon logged in on the socket from client ::ffff:192.168.0.45 2022-03-14 12:48:47,565 - octoprint.plugins.tracking - INFO - Sent tracking event startup, payload: {'version': '1.8.0rc1', 'os': 'linux', 'bits': 32, 'python': '3.7.3', 'pip': '20.3.3', 'cores': 4, 'freq': 1200.0, 'ram': 915722240, 'pi_model': 'Raspberry Pi 3 Model B Rev 1.2', 'octopi_version': '0.18.0'} 2022-03-14 12:48:48,126 - octoprint - ERROR - Exception on / [GET] Traceback (most recent call last): File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 2073, in wsgi_app response = self.full_dispatch_request() File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 1518, in full_dispatch_request rv = self.handle_user_exception(e) File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 1516, in full_dispatch_request rv = self.dispatch_request() File "/home/pi/oprint/lib/python3.7/site-packages/flask/app.py", line 1502, in dispatch_request return self.ensure_sync(self.view_functions[rule.endpoint])(**req.view_args) File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/views.py", line 348, in index fetch_template_data(refresh=force_refresh) File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/views.py", line 1227, in fetch_template_data name, implementation, configs, template_rules File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/views.py", line 1429, in _process_template_configs name, implementation, rule, config=config, counter=counters[template_type] File "/home/pi/oprint/lib/python3.7/site-packages/octoprint/server/views.py", line 1488, in _process_template_config data["template"] = implementation.template_folder_key + "/" + data["template"] TypeError: can only concatenate str (not "NoneType") to str 2022-03-14 12:48:48,167 - octoprint.server.preemptive_cache - INFO - ... done in 3.89s

foosel commented 2 years ago

Y'all, may I remind you of:

If you run into any obvious bugs not yet listed below the following line, please open a new ticket and follow "How to file a bug report". I need full bug reports, not just a statement that something doesn't work!

And this sounds like what @jneilliii already saw. In any case I need more details because I went through all of these plus two local installs and three further tests this morning without any issues at all:

image

GitIssueBot commented 2 years ago

This issue has been mentioned on OctoPrint Community Forum. There might be relevant details there:

https://community.octoprint.org/t/new-release-candidate-1-8-0rc1/42911/6

mod38 commented 2 years ago

Temperature display not scaling properly Update went smoothly, stl export from Prusa Slicer 2.4 went perfectly including thumbnail. Camera on Pi working as usual Temperature display showed start flag - slightly after temperatures had started to rise Temperature display froze at one point when another window on PC was selected, came back after restart of UI 65min after start of print temp display is only showing last 30min instead of temp from start. Do you need a full bug report as well? octoprint-systeminfo-20220314155715.zip


Bundles:

edited by @github-actions to add bundle viewer links

foosel commented 2 years ago

Temperature display showed start flag - slightly after temperatures had started to rise

That sounds about right.

65min after start of print temp display is only showing last 30min instead of temp from start.

That is expected behaviour and has been like this since forever. OctoPrint doesn't keep a full temperature history but only up to a cutoff point, by default 30min.

Temperature display froze at one point when another window on PC was selected, came back after restart of UI

Define "froze" and "restart of the UI". Browsers these days pretty aggressively limit the processing allowed by background & out of focus tabs, which is why OctoPrint also pauses processing if not in foreground, so that would explain "freezing". Stuff should pick up again once you refocus the tab however. If it didn't and you can reliably reproduce this behaviour -> full bug report please (though in all likelihood that would not be a regression but rather some rare bug that's been in there for a long time).

mod38 commented 2 years ago

Thank you for the response. "froze" meant the temp display stopped updating "restart of the UI" meant clicking "reload" on the Firefox browser

Still testing, latest issue is gcode viewer has stopped syncing. I will see if I can reproduce it after this print finishes and will submit a bug report if it does.

foosel commented 2 years ago

This sounds like a general break in communication between your browser and the server, so possibly network problems or an overzealous browser.

mod38 commented 2 years ago

Same problem using Chrome browser on PC and also Chrome on a Pi 4 and on my Android tablet. Webcam is running smoothly with no jerks so network is fine. When this print is finished I will reboot everything and try again. I didn't reboot after the upgrade to 1.8.0 RC so maybe something is unhooked.

foosel commented 2 years ago

Please also roll back to 1.7.3 and verify the issue does not arise there as well.

mod38 commented 2 years ago

I have to go out now but I have rolled back to 1.7.3 and everything worked. I re-upgraded to 1.8.0 RC, restarted in safe mode and problem returned. I restarted normal mode and checked that problem is same as in safe mode. The gcode renderer progress bar under the viewport seems to go too fast - reaching 100% when a layer is only partially complete - and the renderer then stops updating the display. It restarts correctly at the start of the next layer but again goes too fast. I hope this gives a clue as to where the bug might be as I note that the gcode viewer was updated. I will check back later and compile a bug report then.

foosel commented 2 years ago

FYI, 1.8.0rc2 might not happen today after all as another bug was found this morning and I just found another issue with the new settings layer while attempting to run update tests. Will have to see how long it takes to fix that.

foosel commented 2 years ago

@mod38 please open a full bug report as well, this slipped my mind because I didn't have a ticket for it. Bug reports are THE most important part of an RC phase.

mod38 commented 2 years ago

Bug report on gcode viewer now submitted.

foosel commented 2 years ago

That was a tough nut, but for now everything reported has been fixed. However, it's almost 6pm here, so way too late for a release tonight. I'll update the changelog, prepare the release announcement and then see I can push out rc2 tomorrow. Hopefully this time without any hiccups along the way.

AndKe commented 2 years ago

I REALLY dislike the "refresh" idea. it adds pointless clicks

No serial port found, are you sure your printer is physically connected and supported? Try [refreshing] and if that doesn't help please see [the FAQ]

before: I could switch on the printer (from the menu, by GPIO) - then just click "connect" Now: I see the big red text as if something was wrong, need to click "refresh" - THEN click "connect"

To mitigate: -have an option to auto-connect whenever a serial device spawns, (switch on power .. it connects) -have an option to disable this new "feature"

Another feedback

from 1.7.3 stable, I got the option to update to this RC and to update the "marlin flasher" plugin. Accepted to update both - and then I saw marlin flasher settings, clicked "save" - and I were in 1.7.3 -... until I manually reloaded the webpage - apparently, the usual "please reload" dialog was not there . (1.8.RC1 loaded when reloading webpage.)

foosel commented 2 years ago

-have an option to disable this new "feature"

If you had read the release notes, you would have seen this:

"This behaviour can be disabled by setting serial.ignoreEmptyPorts to true in config.yaml."

-have an option to auto-connect whenever a serial device spawns, (switch on power .. it connects)

PortLister plugin.

-have an option to disable this new "feature"

Your scare quotes are unnecessary and out of line. This was added after spending a lot of time helping users who were completely lost because they didn't notice their printer wasn't even being recognized by the underlying OS, causing excessive roundtrips during support and frustration on all sites. This will help a TON here.


from 1.7.3 stable, I got the option to update to this RC and to update the "marlin flasher" plugin. Accepted to update both - and then I saw marlin flasher settings, clicked "save" - and I were in 1.7.3 -... until I manually reloaded the webpage - apparently, the usual "please reload" dialog was not there . (1.8.RC1 loaded when reloading webpage.)

I'm not familiar with what the marlin flashed plugin does, but if it managed to somehow override the reload dialog (there are options for that for certain workflows), I could see this happening. I haven't seen any behaviour like this in tests with stock (incl. bundled plugin updates), all prompted for reload properly.

If this is reproducible in any way, I'll need a full bug report.

foosel commented 2 years ago

1.8.0rc2 has been released, new feedback ticket is #4457