Octoprint: [RC Feedback] Feedback on the 1.4.0rc5 Release Candidate
Please provide general feedback on your experience with the 1.4.0rc5 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
- ✔ #3455 self._printer injected into plugins is broken under py3 and can't be used - fix ready for 1.4.0rc6
- ✔ #3456 Firmware info not reported to plugins if firmware autodetection is disabled - fix ready for 1.4.0rc6, not a regression but implications severe enough to merit inclusion ASAP
- ✔ #3459 Login sessions not persistent even with "Remember me" selected. - fix ready for 1.4.0rc6
Unreproduced issues
Unreproduced and information for further analysis missing
- ❓ #3394 comm port autodetection still broken - appears to not be a regression and will get a closer look in 1.4.1
Unrelated third party issues
Issues needing analysis
foosel
All 22 comments
Installed ok.. Can confirm anonymous login (ie login disabled) works ok. Test print started ok.
No obvious issues straight up...
CRCinAU
on 11 Feb 2020
All is working fine. running on 2 pi's. Login issues gone. Thanks for the hard work
Demigod001
on 13 Feb 2020
Auto detecting a serial port is broken. See my comment on #3394
Once connected everything running as it should, no problems.
MatejSpindler
on 13 Feb 2020
So far no problems yet.
Klipper with SKR 1.1 Pro (Ubuntu Server)
4 Prints (24h)
schnello
on 14 Feb 2020
Ok - so noticed an issue that I'm not sure is related to the RC or not...
I have a rather large P buffer in Marlin (128) - when I'm waiting for the printer to reply, I sometimes get the 'printer timed out' message - as the default timeout seems to be 3 seconds for printers that support BUSY...
Once the printer has timed out once, it seems OctoPrint will stop sending commands AFTER a temperature autoreport is received from the printer until the P buffer is empty. There's a slight stutter, then OctoPrint starts sending commands again and fills the P buffer again - until the next temp auto-report.
If it never hits the initial timeout, this doesn't seem to happen.
You can easily reach the timeout by doing long lines at slow speeds - this doesn't seem to be dependent on the buffer size - but by how long a single line takes to print.
Is this new behaviour related to any change, or am I just coming across this now?
CRCinAU
on 14 Feb 2020
Which branch holds 1.4.0rc5? I'd like to build a new plugin in Python 3 against it, but as someone just getting into this, I'm struggling - I can't spot any info on which branch to clone, and the branches themselves don't identify which version they currently represent (although all of them state the current stable release).
stantond
on 16 Feb 2020
The release candidates are in rc/maintenance, but if you want to check out that specific rc, you can also check out the 1.4.0rc5 tag.
fieldOfView
on 16 Feb 2020
Perfect, thanks!
The release candidates are in
rc/maintenance, but if you want to check out that specific rc, you can also check out the1.4.0rc5tag.
Perfect, thanks! https://community.octoprint.org/t/towards-python-3-and-octoprint-1-4-0/12382 suggests using the devel branch, so maybe could use an update regarding advice for testing plugins.
stantond
on 16 Feb 2020
devel and maintenance are currently in sync. This is where the development happens. After OctoPrint 1.4.0 is released, development that will eventually be in OctoPrint 1.4.1 will go into maintenance, work towards OctoPrint 1.5.0 will go into devel. But because @foosel is working hard on OctoPrint 1.4.0 and no further work is going to be put into OctoPrint 1.3.x, devel and maintenance are currently the same.
When a new rc is released, maintenance is merged into rc/maintenance. The latter is more stable than the former.
When a new stable version is released, rc/maintenance is merged into master. By that time, rc\maintenance has been extensively tested.
The forum topic is still correct. devel can work on Python 3. But so can rc\devel, rc\maintenance, and maintenance.
fieldOfView
on 16 Feb 2020
Ok - so noticed an issue that I'm not sure is related to the RC or not...
I have a rather large P buffer in Marlin (128) - when I'm waiting for the printer to reply, I sometimes get the 'printer timed out' message - as the default timeout seems to be 3 seconds for printers that support BUSY...Once the printer has timed out once, it seems OctoPrint will stop sending commands AFTER a temperature autoreport is received from the printer until the P buffer is empty. There's a slight stutter, then OctoPrint starts sending commands again and fills the P buffer again - until the next temp auto-report.
If it never hits the initial timeout, this doesn't seem to happen.
You can easily reach the timeout by doing long lines at slow speeds - this doesn't seem to be dependent on the buffer size - but by how long a single line takes to print.
Is this new behaviour related to any change, or am I just coming across this now?
I was observing the same problem, but after I replaced my UART flat cable by the shielded one, connection is more stable. It looks like my old flat cable was picking some interference from cables around.
rmoravcik
on 17 Feb 2020
I really don't think this is due to the USB cable...
CRCinAU
on 17 Feb 2020
Is this new behaviour related to any change, or am I just coming across this now?
I'm pretty sure this is not related to a change but it still sounds like something that should be looked into in general. Could you please open a ticket incl. logs and such? Cheers!
foosel
on 17 Feb 2020
I'm pretty sure this is not related to a change but it still sounds like something that should be looked into in general. Could you please open a ticket incl. logs and such? Cheers!
Thanks - I'll have to try and reproduce. I'm not 100% certain that it isn't related to this:
https://github.com/MarlinFirmware/Marlin/issues/16509
I'm using the non-USB target to build against now and haven't seen it again - but I also haven't been watching very closely... I'll file a bug if I can reproduce it successfully with the non-USB version of Marlin...
CRCinAU
on 17 Feb 2020
Just finished a 3rd print and all is good!
louispires
on 18 Feb 2020
So I managed to reproduce the timeouts today in Marlin with a slow print. If someone can check my logic here - but it looks like Marlin just doesn't respond until later on...
Lodged here: https://github.com/MarlinFirmware/Marlin/issues/16894
CRCinAU
on 18 Feb 2020
Just a quick info on the further timeline... I was thinking long and hard today whether to push a new RC with the two fixes I already did today or wait until early next week. I've decided to give RC testers another weekend to unearth anything that might yet to be unearthed instead of releasing a new RC now and then possibly yet another one. I really want to make RC6 the final one.
foosel
on 19 Feb 2020
Release as you're ready - we can deal with it :)
CRCinAU
on 19 Feb 2020
Still getting logged out regularly with "Remember Me" apparently doing nothing. Been trying to figure out how to reproduce and it seems tied to connecting simultaneously from multiple computers on the same account. I also access the octoprint instance from port forwarded ssh connections which might complicate things. Getting to the point where I might just disable access control and do away with the logins.
ChrisHeerschap
on 21 Feb 2020
@ChrisHeerschap hmmm... can you share a log with tornado.access set to DEBUG log level? It's weird. I don't seem to see this myself. Would also be interesting if you could check your cookies the next time this happens, there should be a cookie "remember_token_P80" (with the P80 suffix depending on the port you are accessing OctoPrint under) that gets sent with the initial request to /.
Can you also tell me a bit more about the forwarded SSH connections? Does the port number change? Or the IP?
foosel
on 21 Feb 2020
The session issue reported by @ChrisHeerschap is tracked in #3459 and I think I have it solved, at least I can no longer reproduce it after having found a way to reproduce it reliably on my development machine.
foosel
on 24 Feb 2020
No problems on my stock Ender 3 that I've noticed - been using RC5 since it was released...
Many thanks for all the hard work!
Andy-ABTec
on 25 Feb 2020
1.4.0rc6 is out, new ticket is here: https://github.com/foosel/OctoPrint/issues/3463
foosel
on 26 Feb 2020
Related issues
halkeye
·
4Comments
christianh17
·
5Comments
fake-name
·
4Comments
ModischFabrications
·
3Comments
mdelecate
·
5Comments
Most helpful comment
Just a quick info on the further timeline... I was thinking long and hard today whether to push a new RC with the two fixes I already did today or wait until early next week. I've decided to give RC testers another weekend to unearth anything that might yet to be unearthed instead of releasing a new RC now and then possibly yet another one. I really want to make RC6 the final one.