Octoprint: [RC Feedback] Feedback on the 1.3.6rc3 Release Candidate

[foosel]

Please provide general feedback on your experience with the 1.3.6rc3 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, please open a new ticket and follow "How to file a bug report".

Note for people who already ran 1.3.6rc1 or 1.3.6rc2, then downgraded back to 1.3.5

You'll need to do a tiny fix in your config.yaml, made necessary by a bug introduced in 1.3.6rc1 and not fully understood as a bug until after 1.3.6rc2 was out, or you won't be able to switch back again to Maintenance RCs to test this second RC. You'll need to remove the method: pip line under plugins.softwareupdate.checks.octoprint and then restart.

You can easily do this config.yaml change via the YamlPatcher plugin using the patch string

[["remove", "plugins.softwareupdate.checks.octoprint.method", ""]]

or via the command line using

sed -i -e "s/method: pip//g" ~/.octoprint/config.yaml

[malnvenshorn]

The print button is clickable even if no file is selected. In 1.3.5 the button was disabled in this case. I assume this new behavior is not intended.

[b-morgan]

Installed 1.3.6rc3. No issues (and no prints) so far.

[ChrisHeerschap]

Confirmed @malnvenshorn 's observation.

[jneilliii]

I also can confirm @malnvenshorn 's observation, tested in safe mode to make sure it wasn't related to a third party theme plugin.

[mcp5500]

It blowup my pi build, could't roll back and, after the install, octprint kept losing connectivity. I could not fix the issue. It looked like the serial port driver was having an issue.
I would like to take this time to thank you for all the hard work you and your supporter's do. I'm a systems design engineer and I see what it takes to do what you do. I am amazed at how versatile the product is and the job that you and the community are providing. Thank you.

I would also like to take this time to suggest, or i'm missing, that I would like to see, or learn, of a way of reducing the video stream space to Off and back On" on the Control tab when needed. When Off, there becomes more room for print control, setting, and other add-ons (less scrolling). When On, the controls and add-ons drop below the video stream, like it is today. I am looking at ways to reduce steps so everyone's procedures can be completed in less time. Nice for people that print remotely and user friendly for those sitting next to there printer. Win Win

Thanks,
MCP5500.

[malnvenshorn]

@mcp5500 I wrote a plugin which shows the webcam stream in a separate tab. Otherwise you should open a separate ticket for your request.

[fiveangle]

Upgraded fine here, but one thing that was odd: I was on RC1 and had Octoprint UI tab burried on my browser while accidentially leaving the HE at cold-pull temp (so active) the last week (d'ooh! - I'm now working on a safety feature for Marlin to treat HE similar to stepper timeouts if no movement after certain amount of time, but I digress…).

With the printer HE active the entire time, the upgrade notification feature appears to have queued up the RC2 and RC3 updates together, presenting me with both instead of giving me only RC3 direct from RC1. Is that by design, or an abberation of both notices coming in while the printer is active, and so queued them up sequentially ? If the later, perhaps a check to purge queued upgrade notices before presenting the latest upgrade notice would be prudent ?

I may have been able to manually "ignore" the RC2 notice, but figured this was an odd behavior so went through with the RC2 upgrade instead since I thought upgrading through the RC2 notice while the RC3 notice was also present on-screen might be a path that should be tested to see if it broke, which it didn't.

-=dave

[fiveangle]

Update: checked my other OP host which had been idle during this same period and running RC1, and confirmed that it presented only the RC3 update notification, not both RC2 and RC3.

[ntoff]

I'm now working on a safety feature for Marlin to treat HE similar to stepper timeouts if no movement after certain amount of time, but I digress…).

OctoPrint has a heater timeout plugin you can use during your development of that feature. It'll automatically turn the heaters off after a specified idle timeout.

[jbjones27]

Installed rc3 today on my Raspberry Pi and ran 4 small prints so far. Works great!
Like others have mentioned, THANK YOU Gina for all you do! This is an amazingly useful piece of software!

[JohnOCFII]

Upgraded from rc1 directly to rc3 today. Successfully printed the same 3.5 hour print that experienced the checksum mismatch error with rc1. Successfully uploaded and deleted files. Also successfully created, downloaded, and deleted timelapse. The Telegram, OctoSlack, and Print History Plugins seemed fine.

[foosel]

Thanks everyone for the feedback!

@malnvenshorn, @ChrisHeerschap, @jneilliii

The print button is clickable even if no file is selected. In 1.3.5 the button was disabled in this case. I assume this new behavior is not intended.

That indeed isn't intentional. It's merely cosmetic in nature (it does send a request to the server, but the server internally just goes "what are you asking me to do here, I don't have a file"), however I nevertheless will either simply revert the commit that introduced that issue (8a977e87775f229fdc50e174cc545ae5db5544df) in 1.3.6 stable or maybe leave it in. Reverting it should be risk free enough to do without having to go for another RC round since it indeed only reverts one specific and well isolated set of changes. And the issue is definitely too minor to justify the overhead of another RC round.

@mcp5500

It blowup my pi build, could't roll back and, after the install, octprint kept losing connectivity. I could not fix the issue. It looked like the serial port driver was having an issue.

O_O This sounds decidedly strange. What do you mean with it blowing up your pi build? Maybe something like this known issue with older OctoPi installations? Sadly hard to say more with that amount of information :/

@fiveangle

the upgrade notification feature appears to have queued up the RC2 and RC3 updates together, presenting me with both instead of giving me only RC3 direct from RC1.

Huh. That's odd, because the Softwareupdate Plugin should already replace its own open popups when a new one comes in, and it should also only perform an update check when you load the page or click the corresponding button. I'm not sure how having two notifications open could happen without something seriously hiccuping to be honest, but it's something I'll keep an eye out for. Maybe something similar to the print button issue. Since you couldn't reproduce it a second time I'd say that's also not ground enough for another RC.

All in all, apart from the "blow up" hinted at by @mcp5500 which I so far cannot categorize, this sounds overall positive so far. I've also had 1.3.6rc3 print several hours over the weekend (lithopane presents ;)), so things are looking promising for a stable release tomorrow or the day after, or what do you think?

[malnvenshorn]

@foosel just add a check for self.filename() !== null and it should work fine

[foosel]

@malnvenshorn I'm aware of the solution ;) However I fear that this specific commit where I moved a bunch of == comparisons over to === (and != to !==) might have introduced other issues like that (because undefined ain't null) that so far just haven't surfaced. So reverting that specific commit in that case is the more defensive option for 1.3.6, and for 1.3.7 I'll then make a more careful attempt at the same cleanup.

[andrivet]

I tested RC3 this weekend (for prints of 4 hours each). No problem.

[JohnOCFII]

I've also had 1.3.6rc3 print several hours over the weekend (lithopane presents ;)), so things are looking promising for a stable release tomorrow or the day after, or what do you think?

I Agree. I also did a bunch of additional, longer prints yesterday without issue.

[fiveangle]

Just finished a 12hr print on RC3 w/o issue.

Since you couldn't reproduce it a second time

I never attempted to reproduce it a second time. It very well could be that if 2 updates come in while a printer is "active" (e.g. HE running the entire time) that it may do the same thing, but I have no way to test.

I agree even if it is an issue, it is minor and shouldn't impact moving forward with a release.

-=dave

[foosel]

I never attempted to reproduce it a second time.

Oh, sorry, that was badly phrased on my part. I was referring to your update:

Update: checked my other OP host which had been idle during this same period and running RC1, and confirmed that it presented only the RC3 update notification, not both RC2 and RC3.

and the fact that it didn't do it on your second instance.

[ntoff]

I've done a few short prints (got nothing large to print) on the old Firehazard5000 and all seems to be well.

[foosel]

Please tell me that printer has a prominent tag with that name attached to it.

[ntoff]

No, the name that shows up is a tiny bit inappropriate, but since the printer isn't a total hunk of dung anymore and prints first time every time, I've taken to calling it by its new name of the Firehazard5000 because A) It's made out of wood (that's more dramatic if you say it in Amy Pond's voice when she first sees the TARDIS) and B) the wiring is a bit of a rats nest. Safe, but messy.

[foosel]

Closing because 1.3.6 was just released.

[fiveangle]

and the fact that it didn't do it on your second instance.

There was no second instance. The second printer with Octoprint did not have an active tab and active hotend with browser continually updating the temperature graph the entire time (1+ week) while the 2 sucessive updates came through, which the 1st Octoprint setup did.

In short, the "2nd instance" was just the standard scenario everyone else is in: 2 updates come in on an otherwise idle Octoprint, and that worked fine (as expected).