Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RC Feedback] Feedback on the 1.3.11rc3 Release Candidate #3120

Closed
foosel opened this issue Apr 11, 2019 · 17 comments

Comments

Projects
None yet
9 participants
@foosel
Copy link
Owner

commented Apr 11, 2019

Please provide general feedback on your experience with the 1.3.11rc3 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".


Currently known issues

Unreproduced issues

Unreproduced and information for further analysis missing

Plugin issues

@b-morgan

This comment has been minimized.

Copy link

commented Apr 11, 2019

I have two OctoPi systems, a Pi 3B connected to my LulzBot TAZ 6 using OctoPi 0.14.0 and a Pi 3B+ running OctoPi 0.15.1 which just today got a virtual printer. Both systems were running 1.3.11rc2 and got the announcement for 1.3.11rc3.

The OctoPi 0.15.1 system also got the software upgrade popup (or whatever its called) and successfully upgraded to 1.3.11rc3.

The OctoPi 0.14.0 system did NOT get the software upgrade popup. I've tried restarting OctoPrint and reboot system but neither offers the upgrade. This system was upgraded from 1.13.10 to 1.13.11rc1, then rc2, then back to 1.13.10, then upgraded to 1.13.11rc2.

Suggestions for how to get it back into a state where the updates will be offered automagically are welcome!

@b-morgan

This comment has been minimized.

Copy link

commented Apr 11, 2019

I figured it out. I had to do a "Force check for updates".

@kazibole

This comment has been minimized.

Copy link

commented Apr 12, 2019

21 hour SD card print completed successfully!

@nionio6915

This comment has been minimized.

Copy link

commented Apr 13, 2019

Bug submitted - appearant API key mismatch allows files to be copied to system

@zeroflow

This comment has been minimized.

Copy link

commented Apr 15, 2019

Installed on a Raspi 3B with OctoPi 0.15.1

  • Flawless update
  • Printing works
  • Remove access via Printoid App works the same as before
  • Temperatures not stuck after print
@kazibole

This comment has been minimized.

Copy link

commented Apr 17, 2019

I have done a few more 21 hour SD card prints, as well as a print from OctoPrint, without any issues.

@JohnOCFII

This comment has been minimized.

Copy link

commented Apr 22, 2019

  • Updated successfully from rc2 to rc3
  • Successfully uploaded GCODE, connected to Prusa MK3 and completed print
  • Print History plugin working normally
  • OctoSlack plugin working normally
  • Telegram plugin working normally
@isbric

This comment has been minimized.

Copy link

commented Apr 24, 2019

  • Updated successfully from 1.3.10 to 1.3.11rc3
  • Fixes a bug present in 1.3.10 where G4 commands hung until user resumed. (and sometimes turned off the hotend that did not get reenabled on manual resume)

Tested on:
UM2+ running firmware Tinker-MarlinUltimaker2plus-19.03.1

[EDIT]: clarifying results (yay)

@foosel

This comment has been minimized.

Copy link
Owner Author

commented Apr 24, 2019

@isbric is that a "yay, something got fixed" or a "something broke"? Feedback's a bit too short ;)

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 3, 2019

Short update (after I finally get around into maintenance again after an awesome 3D Meetup Sweden): It looks like we'll need another RC due to what looks like a deadlock when cancelling SD prints, see #3125. I'm trying to understand the scenario under which the deadlock can happen and how to prevent it. Will be a bit before a new RC.

@FormerLurker

This comment has been minimized.

Copy link

commented May 4, 2019

I'm having an issue that I thought was related to my plugin, but I've verified that it occurs even with Octolapse disabled. When I open the settings (wrench/spanner icon) the height of the modal body appears to be way too small. This only seems to occur when I run the application from my development environment. It does not happen when I load OctoPrint from my pi.

Here is a screencap of what I'm seeing:

image

If I zoom in so that the extents of the modal window extend to the edge of the browser, then the settings re-adjust and fill the browser window height:

image

I looked around in the CSS and noticed that if I change the following css:

.full-sized-box {
    position: absolute;
    bottom: 0;
    left: 0;
    right: 0;
    top: 0;
    padding: 15px;
}

to

.full-sized-box {
    position: relative;
    bottom: 0;
    left: 0;
    right: 0;
    top: 0;
    padding: 15px;
}

then it works as expected. It's also worth pointing out that this issue exists even if I disable themeify. Also, if I use position: relative in the full-sized-box class while running OctoPrint from the pi, it still renders correctly.

Ideas?

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 6, 2019

@FormerLurker Are you sure you observed that on the RC? I noticed that too, on maintenance though, and fixed it there in b317338

@FormerLurker

This comment has been minimized.

Copy link

commented May 6, 2019

@foosel , you are correct. Is my face red. I must have switched to maintenance to test out a fix you applied and forgot about it. As usual you are one step ahead of me :)

@evanquinnalaska

This comment has been minimized.

Copy link

commented May 6, 2019

About 170+ hours of printing with RC3, So far the only trouble I have seen with it so far is that I am being throttled with this release where as I was not in RC2 or RC1. throttled=0x20000 Error. It hasn't caused any issues other then some basic lag with file transfers. Once rebooted the error goes away but returns after a day printing or being idle. Not sure if its RC3 specific or if its just time for a clean image after 10+ released / versions on this SD Card.

Average temp during or when Idle is 50-52c. CPU and Memory usage all seem well within normal levels idle and while in use.
3b+, Heat Breaks installed on GPU / CPU, Using a 2.5A, 5V Raspberry Pi Power Supply, Samsung 32gb SD Ultra SD Card. 2x C270 webcams.

Side Note may need a plugin update after the stable has been released: OctoPod seems to be having a Connection error with this release: Connection Error Details: The Operation couldn't Be completed. (StarScream.WSError error1.) http based authentication. Worked before RC3.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 7, 2019

@evanquinnalaska hm... 0x20000 indicates a past overheat issue. I'm not sure how any of the changes in RC3 compared to RC2 could cause the CPU to run hotter during bootup or something, and that's the only things that could happen here from OctoPrint's side, since I only use the vcgencmd get_throttled command as available on the Pi and parse the output instead of rolling my own detection code.

Side Note may need a plugin update after the stable has been released: OctoPod seems to be having a Connection error with this release: Connection Error Details: The Operation couldn't Be completed. (StarScream.WSError error1.) http based authentication. Worked before RC3.

I have no insight into OctoPod so can't say what's needed here. Isn't that also more of a third party client rather than a plugin? 🤔 There shouldn't be any backwards incompatible API changes in RC3, 2 or 1.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 13, 2019

The possible deadlock issue tracked in #3125 is something I still haven't been able to reproduce locally, excessive code analysis also hasn't unearthed anything and it doesn't occur for the OP anymore under safe mode. So I'm going to make a jump here and decide that we'll move forward with 1.3.11.

I'll make some final tests and look into releasing stable 1.3.11 this week.

@foosel

This comment has been minimized.

Copy link
Owner Author

commented May 15, 2019

1.3.11 was released yesterday, thanks everyone for the feedback 🤗

@foosel foosel closed this May 15, 2019

@foosel foosel unpinned this issue May 15, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.