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.5rc3 Release Candidate #2095

Closed
foosel opened this Issue Aug 25, 2017 · 40 comments

Comments

@foosel
Owner

foosel commented Aug 25, 2017

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

@roygilby

This comment has been minimized.

Show comment
Hide comment
@roygilby

roygilby Aug 26, 2017

Everything seems fine for me.

RoyG

roygilby commented Aug 26, 2017

Everything seems fine for me.

RoyG

@ntoff

This comment has been minimized.

Show comment
Hide comment
@ntoff

ntoff Aug 26, 2017

Contributor

I mentioned it in the thread where the connectivity checker was implemented but a "test" button might be nice, or at least some way of knowing whether the host you've set is pingable and / or responding.

At the moment it just seems like it's a blind test, nor does it seem to care that the IP isn't even a valid one.

image

Contributor

ntoff commented Aug 26, 2017

I mentioned it in the thread where the connectivity checker was implemented but a "test" button might be nice, or at least some way of knowing whether the host you've set is pingable and / or responding.

At the moment it just seems like it's a blind test, nor does it seem to care that the IP isn't even a valid one.

image

@andrivet

This comment has been minimized.

Show comment
Hide comment
@andrivet

andrivet Aug 26, 2017

I have made some printing with RC3 and so far, so good. My setup:

  • Wanhao Duplicator i3 plus
  • Manual installation of OctoPrint on a Raspberry Pi 3B (Raspbian 32-bit)
  • Slicing with Cura 2.7 Beta. GCODE sent to OctoPrint directly from Cura.
  • Browsers: Safari 10.1.2 and Chrome 60 on macOS 10.12.6, Chrome 60 on Windows 10

andrivet commented Aug 26, 2017

I have made some printing with RC3 and so far, so good. My setup:

  • Wanhao Duplicator i3 plus
  • Manual installation of OctoPrint on a Raspberry Pi 3B (Raspbian 32-bit)
  • Slicing with Cura 2.7 Beta. GCODE sent to OctoPrint directly from Cura.
  • Browsers: Safari 10.1.2 and Chrome 60 on macOS 10.12.6, Chrome 60 on Windows 10
@chippypilot

This comment has been minimized.

Show comment
Hide comment
@chippypilot

chippypilot Aug 26, 2017

I have updated to RC3 and printed OK.
I'm using a Pi Zero W and Chrome and MS Edge browsers.
One comment is that during the update I see some warning messages while the script is running, but there are no problems listed in the log file after the update. I don't know if they are significant or not.

chippypilot commented Aug 26, 2017

I have updated to RC3 and printed OK.
I'm using a Pi Zero W and Chrome and MS Edge browsers.
One comment is that during the update I see some warning messages while the script is running, but there are no problems listed in the log file after the update. I don't know if they are significant or not.

@mgrl

This comment has been minimized.

Show comment
Hide comment
@mgrl

mgrl Aug 27, 2017

Hi! I'm using two instances for 2 printers on a raspberry pi 3b. updated to rc3 when it was released. made a couple of prints since then, works well, no issues detected.

thank you!

mgrl commented Aug 27, 2017

Hi! I'm using two instances for 2 printers on a raspberry pi 3b. updated to rc3 when it was released. made a couple of prints since then, works well, no issues detected.

thank you!

@JohnOCFII

This comment has been minimized.

Show comment
Hide comment
@JohnOCFII

JohnOCFII Aug 27, 2017

RC3 is working well for me. Ran same tests as with RC2.

JohnOCFII commented Aug 27, 2017

RC3 is working well for me. Ran same tests as with RC2.

@b-morgan

This comment has been minimized.

Show comment
Hide comment
@b-morgan

b-morgan Aug 28, 2017

RC3 is working for me (as was RC2).

b-morgan commented Aug 28, 2017

RC3 is working for me (as was RC2).

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Aug 28, 2017

Owner

Thanks to everyone who reported back so far! I can't express how awesome this amount of feedback is, really helps a lot in determining the "seaworthiness" of this build :)

Considering the amount of time RC2 was out, the exclusively positive feedback so far and the fact that so far even I didn't manage to stumble over anything off ;) we might actually get this released this week :) I'll listen to my gut feeling on that one though, so far that has been a good indicator ;)

@ntoff I saw that request in the related ticket, it's something I'll be happy to add, but not as part of this release.

Owner

foosel commented Aug 28, 2017

Thanks to everyone who reported back so far! I can't express how awesome this amount of feedback is, really helps a lot in determining the "seaworthiness" of this build :)

Considering the amount of time RC2 was out, the exclusively positive feedback so far and the fact that so far even I didn't manage to stumble over anything off ;) we might actually get this released this week :) I'll listen to my gut feeling on that one though, so far that has been a good indicator ;)

@ntoff I saw that request in the related ticket, it's something I'll be happy to add, but not as part of this release.

@CapnBry

This comment has been minimized.

Show comment
Hide comment
@CapnBry

CapnBry Aug 28, 2017

Contributor

Am I the only person whose background analysis is failing on rc3? I upload a file, octoprint starts hitting the CPU and eventually it stops and there's no metadata update. There is Invoking analysis command... and then nothing. The .metadata.yaml contains only the hash.

I've got to get to printing but I can probably look into it in more detail tomorrow if I am not the only one experiencing this?

Contributor

CapnBry commented Aug 28, 2017

Am I the only person whose background analysis is failing on rc3? I upload a file, octoprint starts hitting the CPU and eventually it stops and there's no metadata update. There is Invoking analysis command... and then nothing. The .metadata.yaml contains only the hash.

I've got to get to printing but I can probably look into it in more detail tomorrow if I am not the only one experiencing this?

@nate-ubiquisoft

This comment has been minimized.

Show comment
Hide comment
@nate-ubiquisoft

nate-ubiquisoft Aug 29, 2017

Everything has been great so far. The only thing I see is a layout/display issue with the TouchUI plugin on mobile display (see attached photo).
img_1940

Only other thing I saw was a little bit of Chrome dev console complaining about resource load times and caching recommendations. I still plan on digging into improving that when I finally get my TAZ 6 operational. (LPT - DONT BUY the Flexydually extruder. Too many issues to describe here)

nate-ubiquisoft commented Aug 29, 2017

Everything has been great so far. The only thing I see is a layout/display issue with the TouchUI plugin on mobile display (see attached photo).
img_1940

Only other thing I saw was a little bit of Chrome dev console complaining about resource load times and caching recommendations. I still plan on digging into improving that when I finally get my TAZ 6 operational. (LPT - DONT BUY the Flexydually extruder. Too many issues to describe here)

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Aug 29, 2017

Owner

@CapnBry

Am I the only person whose background analysis is failing on rc3?

At least that's complete news to me so far. I'm seeing analysis results on RC3. It's worrying that you don't.

@nate-ubiquisoft That's something @BillyBlaze I think is aware of/has already fixed for the next version of the plugin. I might have misunderstood him though.

Owner

foosel commented Aug 29, 2017

@CapnBry

Am I the only person whose background analysis is failing on rc3?

At least that's complete news to me so far. I'm seeing analysis results on RC3. It's worrying that you don't.

@nate-ubiquisoft That's something @BillyBlaze I think is aware of/has already fixed for the next version of the plugin. I might have misunderstood him though.

@BillyBlaze

This comment has been minimized.

Show comment
Hide comment
@BillyBlaze

BillyBlaze Aug 29, 2017

Collaborator

Yes, this is fixed on my maintenance branch 👍 will be released together with this release.

Collaborator

BillyBlaze commented Aug 29, 2017

Yes, this is fixed on my maintenance branch 👍 will be released together with this release.

@nate-ubiquisoft

This comment has been minimized.

Show comment
Hide comment
@nate-ubiquisoft

nate-ubiquisoft Aug 29, 2017

@BillyBlaze perfect. Other than that everything looks great! Thanks @foosel !

nate-ubiquisoft commented Aug 29, 2017

@BillyBlaze perfect. Other than that everything looks great! Thanks @foosel !

@cxt666

This comment has been minimized.

Show comment
Hide comment
@cxt666

cxt666 Aug 29, 2017

RC3 works well for me (RPi2/Octopi)

cxt666 commented Aug 29, 2017

RC3 works well for me (RPi2/Octopi)

@CapnBry

This comment has been minimized.

Show comment
Hide comment
@CapnBry

CapnBry Aug 29, 2017

Contributor

Regarding my issue with the gcode analysis not working, Here's the stack trace of the interpreter failing

pi@prontwoer:~ $ /home/pi/OctoPrint/venv/bin/python /home/pi/OctoPrint/venv/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/util/gcodeInterpreter.py --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 --offset 0.0 0.0 /home/pi/.octoprint/uploads/hm-case-43-thermistor.gcode
Traceback (most recent call last):
  File "/home/pi/OctoPrint/venv/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/util/gcodeInterpreter.py", line 518, in <module>
    import yaml
  File "build/bdist.linux-armv7l/egg/yaml/__init__.py", line 14, in <module>
    import traceback
  File "build/bdist.linux-armv7l/egg/yaml/cyaml.py", line 5, in <module>
  File "build/bdist.linux-armv7l/egg/_yaml.py", line 7, in <module>
  File "build/bdist.linux-armv7l/egg/_yaml.py", line 3, in __bootstrap__
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources.py", line 1189, in <module>
    class MarkerEvaluation(object):
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources.py", line 1193, in MarkerEvaluation
    'python_full_version': platform.python_version,
AttributeError: 'module' object has no attribute 'python_version'
pi@prontwoer:~ $ /home/pi/OctoPrint/venv/bin/python
Python 2.7.9 (default, Sep 17 2016, 20:26:04)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.python_version
<function python_version at 0x76961030>
>>> platform.python_version()
'2.7.9'
>>>

We worked through this this morning and I uninstalled my host system's libyaml* deb packages and rebuilt venv. After that it worked like a charm, so something about the native yaml library? In either case I don't think this is a 1.3.5 issue, unless the import platform is getting OctoPrint's new platform module which of course does not have python_version() and all that.

That's the only thing I've seen so far and my problem has been resolved so hopefully it is random bits error just for me.

Contributor

CapnBry commented Aug 29, 2017

Regarding my issue with the gcode analysis not working, Here's the stack trace of the interpreter failing

pi@prontwoer:~ $ /home/pi/OctoPrint/venv/bin/python /home/pi/OctoPrint/venv/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/util/gcodeInterpreter.py --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 --offset 0.0 0.0 /home/pi/.octoprint/uploads/hm-case-43-thermistor.gcode
Traceback (most recent call last):
  File "/home/pi/OctoPrint/venv/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/util/gcodeInterpreter.py", line 518, in <module>
    import yaml
  File "build/bdist.linux-armv7l/egg/yaml/__init__.py", line 14, in <module>
    import traceback
  File "build/bdist.linux-armv7l/egg/yaml/cyaml.py", line 5, in <module>
  File "build/bdist.linux-armv7l/egg/_yaml.py", line 7, in <module>
  File "build/bdist.linux-armv7l/egg/_yaml.py", line 3, in __bootstrap__
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources.py", line 1189, in <module>
    class MarkerEvaluation(object):
  File "/home/pi/OctoPrint/venv/local/lib/python2.7/site-packages/pkg_resources.py", line 1193, in MarkerEvaluation
    'python_full_version': platform.python_version,
AttributeError: 'module' object has no attribute 'python_version'
pi@prontwoer:~ $ /home/pi/OctoPrint/venv/bin/python
Python 2.7.9 (default, Sep 17 2016, 20:26:04)
[GCC 4.9.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.python_version
<function python_version at 0x76961030>
>>> platform.python_version()
'2.7.9'
>>>

We worked through this this morning and I uninstalled my host system's libyaml* deb packages and rebuilt venv. After that it worked like a charm, so something about the native yaml library? In either case I don't think this is a 1.3.5 issue, unless the import platform is getting OctoPrint's new platform module which of course does not have python_version() and all that.

That's the only thing I've seen so far and my problem has been resolved so hopefully it is random bits error just for me.

@MoonshineSG

This comment has been minimized.

Show comment
Hide comment
@MoonshineSG

MoonshineSG Aug 30, 2017

After update, it fails to restart:

pi@i3:~/.octoprint/logs $ tail -n 200 -f /home/pi/.octoprint/logs/octoprint.log 
2017-08-30 10:52:10,202 - octoprint.server - INFO - ******************************************************************************
2017-08-30 10:52:10,206 - octoprint.server - INFO - Starting OctoPrint 1.3.5rc3 (rc/maintenance branch)
2017-08-30 10:52:10,207 - octoprint.server - INFO - ******************************************************************************
2017-08-30 10:52:10,273 - octoprint.plugin.core - INFO - Loading plugins from /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins, /home/pi/.octoprint/plugins and installed plugin packages...
2017-08-30 10:52:12,297 - octoprint.plugin.core - INFO - Found 26 plugin(s) providing 22 mixin implementations, 26 hook handlers
2017-08-30 10:52:12,325 - octoprint.server - INFO - Intermediary server started
2017-08-30 10:52:12,325 - octoprint.plugin.core - INFO - Loading plugins from /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins, /home/pi/.octoprint/plugins and installed plugin packages...
2017-08-30 10:52:12,642 - octoprint.plugin.core - INFO - Found 26 plugin(s) providing 22 mixin implementations, 26 hook handlers
2017-08-30 10:52:12,678 - octoprint.filemanager.storage - INFO - Initializing the file metadata for /home/pi/.octoprint/uploads...
2017-08-30 10:52:15,662 - octoprint.filemanager.storage - INFO - ... file metadata for /home/pi/.octoprint/uploads initialized successfully.
2017-08-30 10:52:15,673 - octoprint.plugins.nautilus - INFO - 4 device(s) will receive notifications...
2017-08-30 10:52:15,673 - octoprint.plugins.nautilus - INFO - Nautilus - OctoPrint mobile shell, started.
2017-08-30 10:52:15,676 - octoprint.util.connectivity_checker - INFO - Connectivity changed from offline to online
2017-08-30 10:52:15,685 - octoprint.plugins.led - INFO - Running RPi.GPIO version '0.6.3'...
2017-08-30 10:52:15,687 - octoprint.plugins.log_z_change - INFO - LogZChange initialized...
2017-08-30 10:52:15,856 - octoprint.plugins.softwareupdate - INFO - Version cache was created for another version of OctoPrint, not using it
2017-08-30 10:52:15,859 - octoprint.plugins.sound - INFO - Initialized with 20% from 20 to 8...
2017-08-30 10:52:15,860 - octoprint.plugins.sound - INFO - Sounds not muted: ['@change', '@offset', '@save_offset', '@baby_up', '@baby_down']
2017-08-30 10:52:15,863 - octoprint.plugins.multi_colors - INFO - MultiColors init
2017-08-30 10:52:15,864 - octoprint.plugins.switch - INFO - Running RPi.GPIO version '0.6.3'...
2017-08-30 10:52:15,867 - octoprint.plugins.switch - INFO - SwitchPlugin initialized...
2017-08-30 10:52:17,874 - octoprint.util.pip - INFO - Using "/home/pi/oprint/bin/python -m pip" as command to invoke pip
2017-08-30 10:52:19,971 - octoprint.util.pip - INFO - Version of pip is 8.1.2
2017-08-30 10:52:19,974 - octoprint.plugin.core - INFO - Initialized 22 plugin implementation(s)
2017-08-30 10:52:19,987 - octoprint.plugin.core - INFO - 26 plugin(s) registered with the system:
|  Active Filters (0.0.1) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_active_filters
|  Announcement Plugin (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/announcements
|  Autoscroll (0.0.2) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_autoscroll
|  Core Wizard (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/corewizard
| !CuraEngine (<= 15.04) (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/cura
|  Discovery (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/discovery
|  DisplayZ (0.1.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_displayz
| !EEPROM Marlin Editor Plugin (0.1.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_eeprom_marlin
| !Filament-Sensor (1.0.1) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_filament
|  Fullscreen Plugin (0.0.3) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_fullscreen
|  Gcode Action (0.0.1) = /home/pi/.octoprint/plugins/gocode_action.py
|  GCODE Process = /home/pi/.octoprint/plugins/gcode_process.py
|  LED Plugin (0.0.1) = /home/pi/.octoprint/plugins/led.py
|  Log Z Change (0.0.1) = /home/pi/.octoprint/plugins/log_z_change.py
|  M117PopUp (0.6.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_M117PopUp
|  Multi Colors (1.0.7) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_multi_colors
|  Nautilus (1.17) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_nautilus
|  Navbar Temperature Plugin (0.8) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_navbartemp
|  Plugin Manager (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/pluginmanager
|  Print History Plugin (1.2) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory
|  Print Recovery POC (0.1.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printrecoverypoc
|  Software Update (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/softwareupdate
|  Sound (1.0.3) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_sound
|  switch = /home/pi/.octoprint/plugins/switch
|  Title Status (0.0.4) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_title_status
|  Virtual Printer (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/virtual_printer
2017-08-30 10:52:19,994 - octoprint.server - INFO - Reset webasset folder /home/pi/.octoprint/generated/webassets...
2017-08-30 10:52:19,995 - octoprint.server - INFO - Reset webasset folder /home/pi/.octoprint/generated/.webassets-cache...
2017-08-30 10:52:20,239 - octoprint.cli.server - ERROR - Uncaught exception
Traceback (most recent call last):
  File "/home/pi/oprint/bin/octoprint", line 9, in <module>
    load_entry_point('OctoPrint==1.3.5rc3', 'console_scripts', 'octoprint')()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/__init__.py", line 406, in main
    octo(args=args, prog_name="octoprint", auto_envvar_prefix="OCTOPRINT")
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 1037, in invoke
    return Command.invoke(self, ctx)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/cli/__init__.py", line 173, in octo
    ctx.invoke(serve_command, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/cli/server.py", line 150, in serve_command
    allow_root, logging, verbosity, safe_mode)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/cli/server.py", line 96, in run_server
    octoprint_server.run()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/server/__init__.py", line 460, in run
    session_kls=util.sockjs.ThreadSafeSession)
TypeError: __init__() got an unexpected keyword argument 'session_kls'

MoonshineSG commented Aug 30, 2017

After update, it fails to restart:

pi@i3:~/.octoprint/logs $ tail -n 200 -f /home/pi/.octoprint/logs/octoprint.log 
2017-08-30 10:52:10,202 - octoprint.server - INFO - ******************************************************************************
2017-08-30 10:52:10,206 - octoprint.server - INFO - Starting OctoPrint 1.3.5rc3 (rc/maintenance branch)
2017-08-30 10:52:10,207 - octoprint.server - INFO - ******************************************************************************
2017-08-30 10:52:10,273 - octoprint.plugin.core - INFO - Loading plugins from /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins, /home/pi/.octoprint/plugins and installed plugin packages...
2017-08-30 10:52:12,297 - octoprint.plugin.core - INFO - Found 26 plugin(s) providing 22 mixin implementations, 26 hook handlers
2017-08-30 10:52:12,325 - octoprint.server - INFO - Intermediary server started
2017-08-30 10:52:12,325 - octoprint.plugin.core - INFO - Loading plugins from /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins, /home/pi/.octoprint/plugins and installed plugin packages...
2017-08-30 10:52:12,642 - octoprint.plugin.core - INFO - Found 26 plugin(s) providing 22 mixin implementations, 26 hook handlers
2017-08-30 10:52:12,678 - octoprint.filemanager.storage - INFO - Initializing the file metadata for /home/pi/.octoprint/uploads...
2017-08-30 10:52:15,662 - octoprint.filemanager.storage - INFO - ... file metadata for /home/pi/.octoprint/uploads initialized successfully.
2017-08-30 10:52:15,673 - octoprint.plugins.nautilus - INFO - 4 device(s) will receive notifications...
2017-08-30 10:52:15,673 - octoprint.plugins.nautilus - INFO - Nautilus - OctoPrint mobile shell, started.
2017-08-30 10:52:15,676 - octoprint.util.connectivity_checker - INFO - Connectivity changed from offline to online
2017-08-30 10:52:15,685 - octoprint.plugins.led - INFO - Running RPi.GPIO version '0.6.3'...
2017-08-30 10:52:15,687 - octoprint.plugins.log_z_change - INFO - LogZChange initialized...
2017-08-30 10:52:15,856 - octoprint.plugins.softwareupdate - INFO - Version cache was created for another version of OctoPrint, not using it
2017-08-30 10:52:15,859 - octoprint.plugins.sound - INFO - Initialized with 20% from 20 to 8...
2017-08-30 10:52:15,860 - octoprint.plugins.sound - INFO - Sounds not muted: ['@change', '@offset', '@save_offset', '@baby_up', '@baby_down']
2017-08-30 10:52:15,863 - octoprint.plugins.multi_colors - INFO - MultiColors init
2017-08-30 10:52:15,864 - octoprint.plugins.switch - INFO - Running RPi.GPIO version '0.6.3'...
2017-08-30 10:52:15,867 - octoprint.plugins.switch - INFO - SwitchPlugin initialized...
2017-08-30 10:52:17,874 - octoprint.util.pip - INFO - Using "/home/pi/oprint/bin/python -m pip" as command to invoke pip
2017-08-30 10:52:19,971 - octoprint.util.pip - INFO - Version of pip is 8.1.2
2017-08-30 10:52:19,974 - octoprint.plugin.core - INFO - Initialized 22 plugin implementation(s)
2017-08-30 10:52:19,987 - octoprint.plugin.core - INFO - 26 plugin(s) registered with the system:
|  Active Filters (0.0.1) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_active_filters
|  Announcement Plugin (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/announcements
|  Autoscroll (0.0.2) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_autoscroll
|  Core Wizard (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/corewizard
| !CuraEngine (<= 15.04) (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/cura
|  Discovery (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/discovery
|  DisplayZ (0.1.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_displayz
| !EEPROM Marlin Editor Plugin (0.1.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_eeprom_marlin
| !Filament-Sensor (1.0.1) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_filament
|  Fullscreen Plugin (0.0.3) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_fullscreen
|  Gcode Action (0.0.1) = /home/pi/.octoprint/plugins/gocode_action.py
|  GCODE Process = /home/pi/.octoprint/plugins/gcode_process.py
|  LED Plugin (0.0.1) = /home/pi/.octoprint/plugins/led.py
|  Log Z Change (0.0.1) = /home/pi/.octoprint/plugins/log_z_change.py
|  M117PopUp (0.6.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_M117PopUp
|  Multi Colors (1.0.7) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_multi_colors
|  Nautilus (1.17) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_nautilus
|  Navbar Temperature Plugin (0.8) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_navbartemp
|  Plugin Manager (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/pluginmanager
|  Print History Plugin (1.2) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printhistory
|  Print Recovery POC (0.1.0) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_printrecoverypoc
|  Software Update (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/softwareupdate
|  Sound (1.0.3) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_sound
|  switch = /home/pi/.octoprint/plugins/switch
|  Title Status (0.0.4) = /home/pi/oprint/local/lib/python2.7/site-packages/octoprint_title_status
|  Virtual Printer (bundled) = /home/pi/oprint/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/plugins/virtual_printer
2017-08-30 10:52:19,994 - octoprint.server - INFO - Reset webasset folder /home/pi/.octoprint/generated/webassets...
2017-08-30 10:52:19,995 - octoprint.server - INFO - Reset webasset folder /home/pi/.octoprint/generated/.webassets-cache...
2017-08-30 10:52:20,239 - octoprint.cli.server - ERROR - Uncaught exception
Traceback (most recent call last):
  File "/home/pi/oprint/bin/octoprint", line 9, in <module>
    load_entry_point('OctoPrint==1.3.5rc3', 'console_scripts', 'octoprint')()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/__init__.py", line 406, in main
    octo(args=args, prog_name="octoprint", auto_envvar_prefix="OCTOPRINT")
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 716, in __call__
    return self.main(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 696, in main
    rv = self.invoke(ctx)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 1037, in invoke
    return Command.invoke(self, ctx)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 889, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/cli/__init__.py", line 173, in octo
    ctx.invoke(serve_command, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/core.py", line 534, in invoke
    return callback(*args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/click-6.2-py2.7.egg/click/decorators.py", line 17, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/cli/server.py", line 150, in serve_command
    allow_root, logging, verbosity, safe_mode)
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/cli/server.py", line 96, in run_server
    octoprint_server.run()
  File "/home/pi/oprint/local/lib/python2.7/site-packages/OctoPrint-1.3.5rc3-py2.7.egg/octoprint/server/__init__.py", line 460, in run
    session_kls=util.sockjs.ThreadSafeSession)
TypeError: __init__() got an unexpected keyword argument 'session_kls'
@nate-ubiquisoft

This comment has been minimized.

Show comment
Hide comment
@nate-ubiquisoft

nate-ubiquisoft Aug 31, 2017

@foosel I hate to say it but I believe I found an issue. It may be very specific to the browser (or rather the fact that chrome now "sleeps" any non-foreground tabs). When I have a tab with Octoprint open, navigate away for ~30+ minutes, then navigate back to that tab, the web interface takes a good 10-30 seconds to "reload", as I am just presented with a black screen. Now this is easy to handle as a client right now by just refreshing the page, but when that happens, my TAZ 6 actually froze-up mid-print and when the page finished loading it continued along like nothing happened.

I will capture network & console logs from chrome dev console over an hr+ period as well as test it in Firefox and Safari to see if the issue is there as well. My gut feeling is it has something to do with chrome's new handling of non-foreground tabs but I won't know for certain until I complete some testing in other browsers.

UPDATE:
Chrome dev console throws a warning each time the tab is brought to the foreground:
screen shot 2017-08-30 at 7 13 49 pm

nate-ubiquisoft commented Aug 31, 2017

@foosel I hate to say it but I believe I found an issue. It may be very specific to the browser (or rather the fact that chrome now "sleeps" any non-foreground tabs). When I have a tab with Octoprint open, navigate away for ~30+ minutes, then navigate back to that tab, the web interface takes a good 10-30 seconds to "reload", as I am just presented with a black screen. Now this is easy to handle as a client right now by just refreshing the page, but when that happens, my TAZ 6 actually froze-up mid-print and when the page finished loading it continued along like nothing happened.

I will capture network & console logs from chrome dev console over an hr+ period as well as test it in Firefox and Safari to see if the issue is there as well. My gut feeling is it has something to do with chrome's new handling of non-foreground tabs but I won't know for certain until I complete some testing in other browsers.

UPDATE:
Chrome dev console throws a warning each time the tab is brought to the foreground:
screen shot 2017-08-30 at 7 13 49 pm

@CapnBry

This comment has been minimized.

Show comment
Hide comment
@CapnBry

CapnBry Aug 31, 2017

Contributor

@nate-ubiquisoft You need to disable uBlock Origin for the OctoPrint site. When you refocus the tab, uBlock Origin takes a wicked long time to "catch up" with all the background data. I'm not sure what exactly causes it (is Chrome actually buffering the entire websocket stream then playing it all back when focus returns and uBlock needs to check every DOM change?).

If you turn off ad blocking for your OctoPrint sites, Chrome won't hang any more when you refocus it. I have the same problem with my HeaterMeter web pages (which stream data continuously as well) and they don't have anywhere near the data-binding complexity of OctoPrint, so the delay is entirely in the uBlock code.

Contributor

CapnBry commented Aug 31, 2017

@nate-ubiquisoft You need to disable uBlock Origin for the OctoPrint site. When you refocus the tab, uBlock Origin takes a wicked long time to "catch up" with all the background data. I'm not sure what exactly causes it (is Chrome actually buffering the entire websocket stream then playing it all back when focus returns and uBlock needs to check every DOM change?).

If you turn off ad blocking for your OctoPrint sites, Chrome won't hang any more when you refocus it. I have the same problem with my HeaterMeter web pages (which stream data continuously as well) and they don't have anywhere near the data-binding complexity of OctoPrint, so the delay is entirely in the uBlock code.

@nate-ubiquisoft

This comment has been minimized.

Show comment
Hide comment
@nate-ubiquisoft

nate-ubiquisoft Aug 31, 2017

@CapnBry Spot on the money with that one man. Thanks!
I'm going to do some packet captures with Surge tonight and see exactly how chrome is handling the tab backgrounding/re-focusing. I do bet $ it's to do with the combination of uBlock and Chrome, as I didn't see nearly as drastic a delay when using Firefox with uBlock enabled.

Thanks again guys!

nate-ubiquisoft commented Aug 31, 2017

@CapnBry Spot on the money with that one man. Thanks!
I'm going to do some packet captures with Surge tonight and see exactly how chrome is handling the tab backgrounding/re-focusing. I do bet $ it's to do with the combination of uBlock and Chrome, as I didn't see nearly as drastic a delay when using Firefox with uBlock enabled.

Thanks again guys!

@SAinc

This comment has been minimized.

Show comment
Hide comment
@SAinc

SAinc Sep 1, 2017

Everything seems to be working great. The only issue I have seen is that the temperature graph doesn't update the temperature number in the bottom left corner of the graph when the mouse is over the graph. Example:
image
The value reported by the graph does not match the value the cursor is over.

I haven't seen any other problems otherwise.

SAinc commented Sep 1, 2017

Everything seems to be working great. The only issue I have seen is that the temperature graph doesn't update the temperature number in the bottom left corner of the graph when the mouse is over the graph. Example:
image
The value reported by the graph does not match the value the cursor is over.

I haven't seen any other problems otherwise.

@mgrl

This comment has been minimized.

Show comment
Hide comment
@mgrl

mgrl Sep 3, 2017

Just wanted to setup another instance of octoprint on my raspberry. I could confirm that updating was no problem, but maybe new installs of octoprint with the onlinechecker feature.
Following issue I run into:
Created a fresh instance (as described on some sites/group-postings). Now I see the first run wizzard which forces me to choose whether I want the online checker enabled or disabled. This selection fails. From the server I get the response 403: Octoprint not setup yet. Can anybody confirm this happens on new installs or is it just my instances-setup?

mgrl commented Sep 3, 2017

Just wanted to setup another instance of octoprint on my raspberry. I could confirm that updating was no problem, but maybe new installs of octoprint with the onlinechecker feature.
Following issue I run into:
Created a fresh instance (as described on some sites/group-postings). Now I see the first run wizzard which forces me to choose whether I want the online checker enabled or disabled. This selection fails. From the server I get the response 403: Octoprint not setup yet. Can anybody confirm this happens on new installs or is it just my instances-setup?

@ntoff

This comment has been minimized.

Show comment
Hide comment
@ntoff

ntoff Sep 4, 2017

Contributor

Created a fresh instance (as described on some sites/group-postings).

It might help if you link us to those instructions, there's a few different ways you could be running those other instances. You could install it in a 2nd virtual environment, run a 2nd instance off the same config (probably bad) or be using separate base directories. Need more info on exactly how you're running your 2nd instance.

Contributor

ntoff commented Sep 4, 2017

Created a fresh instance (as described on some sites/group-postings).

It might help if you link us to those instructions, there's a few different ways you could be running those other instances. You could install it in a 2nd virtual environment, run a 2nd instance off the same config (probably bad) or be using separate base directories. Need more info on exactly how you're running your 2nd instance.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Sep 4, 2017

Owner

Just as a quick heads-up here: I'm currently down sick and in no shape to touch code, so things are currently a bit slow from my side again (which annoys me greatly). I really appreciate the feedback though and will make sure to take a proper look at anything reported ASAP!

As a quick side-note to @mgrl: I did test against a completely fresh instance and didn't run into any problems (it's part of my regular "pre flight test" I do for any releases). So if you ran into issues, there was most likely some difference between your and my setup, so as @ntoff said, more details would be golden!

Owner

foosel commented Sep 4, 2017

Just as a quick heads-up here: I'm currently down sick and in no shape to touch code, so things are currently a bit slow from my side again (which annoys me greatly). I really appreciate the feedback though and will make sure to take a proper look at anything reported ASAP!

As a quick side-note to @mgrl: I did test against a completely fresh instance and didn't run into any problems (it's part of my regular "pre flight test" I do for any releases). So if you ran into issues, there was most likely some difference between your and my setup, so as @ntoff said, more details would be golden!

@mgrl

This comment has been minimized.

Show comment
Hide comment
@mgrl

mgrl Sep 4, 2017

okay, here is how I did it:

  1. Follow these instructions: https://groups.google.com/d/msg/octoprint/ima1G632lN0/my0dKrORD2kJ and these https://groups.google.com/d/msg/octoprint/ima1G632lN0/QUoNULNrTHsJ
  2. Configure HAproxy to expose the instance (/etc/haproxy/haproxy.cfg) and restart the service (service haproxy restart)
  3. Call the website e.g. 3dprinter:82.
  4. The firstRun-wizard is presented and forces to set the online-check option.
  5. Click on enable/disable, the server responses with a 403 and the text in the answer is "Octoprint isn't setup yet" from here:
    return flask.make_response("OctoPrint isn't setup yet", 403)

My workaround was to copy the config.yaml from ./.octoprint to ./.octoprint3 (its the third instance now) and restart the server. Then it worked as expected. Could make a fourth instance this evening and add a screenshot of the firefox web development tools.

@foosel: Get well soon!

mgrl commented Sep 4, 2017

okay, here is how I did it:

  1. Follow these instructions: https://groups.google.com/d/msg/octoprint/ima1G632lN0/my0dKrORD2kJ and these https://groups.google.com/d/msg/octoprint/ima1G632lN0/QUoNULNrTHsJ
  2. Configure HAproxy to expose the instance (/etc/haproxy/haproxy.cfg) and restart the service (service haproxy restart)
  3. Call the website e.g. 3dprinter:82.
  4. The firstRun-wizard is presented and forces to set the online-check option.
  5. Click on enable/disable, the server responses with a 403 and the text in the answer is "Octoprint isn't setup yet" from here:
    return flask.make_response("OctoPrint isn't setup yet", 403)

My workaround was to copy the config.yaml from ./.octoprint to ./.octoprint3 (its the third instance now) and restart the server. Then it worked as expected. Could make a fourth instance this evening and add a screenshot of the firefox web development tools.

@foosel: Get well soon!

@cxt666

This comment has been minimized.

Show comment
Hide comment
@cxt666

cxt666 Sep 10, 2017

After a while (~ 1 week of troubleshooting the Z axis alignment) I found the following issue: Moving the Z axis with the Up/Down/Home button also moves the X axis. This happens after I powered up the Anet A9 and connect the Raspi. The behaviour goes away when I move the Z axis with the printers built in controls, at least as log as printer and Raspi keep connected together.

cxt666 commented Sep 10, 2017

After a while (~ 1 week of troubleshooting the Z axis alignment) I found the following issue: Moving the Z axis with the Up/Down/Home button also moves the X axis. This happens after I powered up the Anet A9 and connect the Raspi. The behaviour goes away when I move the Z axis with the printers built in controls, at least as log as printer and Raspi keep connected together.

@Kunsi

This comment has been minimized.

Show comment
Hide comment
@Kunsi

Kunsi Sep 10, 2017

Can't reproduce that "Z movement also moves X" on any of my three instances of OctoPrint here.

Kunsi commented Sep 10, 2017

Can't reproduce that "Z movement also moves X" on any of my three instances of OctoPrint here.

@tkurbad

This comment has been minimized.

Show comment
Hide comment
@tkurbad

tkurbad Sep 11, 2017

RC3 looks fine to me! Printer: Ultibots Kossel 250VS BSE with Smoothieboard 5X. Octoprint running on a RPi3.

tkurbad commented Sep 11, 2017

RC3 looks fine to me! Printer: Ultibots Kossel 250VS BSE with Smoothieboard 5X. Octoprint running on a RPi3.

@tsillini

This comment has been minimized.

Show comment
Hide comment
@tsillini

tsillini Sep 14, 2017

I've had 2 communication failures since updating to 1.3.5 in the last couple days. its hard to pinpoint the source of the errors however. i'll try and reproduce the issue and see if theres any logs I can find with more info.

tsillini commented Sep 14, 2017

I've had 2 communication failures since updating to 1.3.5 in the last couple days. its hard to pinpoint the source of the errors however. i'll try and reproduce the issue and see if theres any logs I can find with more info.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Sep 28, 2017

Owner

So, I'm finally at least back enough on my feet that I could take a look at your reports. First of all again: Thank you for the feedback, this is great and really helps a lot!

@CapnBry I took another look at your libyaml issue and could reproduce easily, just by installing the library again. That's something that worries me tremendously because that library might be installed in the field for other reasons than OctoPrint (OctoPi doesn't ship with it, but that doesn't keep people from installing it on their own for whatever reason). I took another look at the code and found a better approach to spawn the analysis process that doesn't have this issue. So I guess we'll have an RC4 after all.

@MoonshineSG the only way that should be possible is if your sockjs-tornado dependency is not yet version 1.0.2 (which OctoPrint requires since 2015) - I'm a bit at a loss there right now. What does pip freeze | grep sockjs report for you? Should be either 1.0.2 or 1.0.3.

@mgrl I'm able to reproduce this. Let me guess, you had it setup something like "first instance on /, second on /octoprint2"? Because in that scenario I can reproduce due to the fact that after logging into the second instance, it gets cookies sent from the browser for both / and /octoprint2 and sadly the one for / seems to win in the processing, causing the second instance to not recognize the login session and hence anything requiring admin rights to not work (including configuring the online check). That's most likely not a new issue, but more visible now. I'll have to think a bit on how to solve this, this might get tricky.

@cxt666 There were no changes in what commands the buttons on the control panel send and I also cannot reproduce this. Do you also see any X movement commands sent in your Terminal tab? If not, it's on your printer's firmware.

All in all I'm starting to wonder whether I'll ever get this stupid release out of the door, what with all the interruptions I seem to get with it, plus subtle but evil bugs ;) But better they are found now than once the release is out 👍

Owner

foosel commented Sep 28, 2017

So, I'm finally at least back enough on my feet that I could take a look at your reports. First of all again: Thank you for the feedback, this is great and really helps a lot!

@CapnBry I took another look at your libyaml issue and could reproduce easily, just by installing the library again. That's something that worries me tremendously because that library might be installed in the field for other reasons than OctoPrint (OctoPi doesn't ship with it, but that doesn't keep people from installing it on their own for whatever reason). I took another look at the code and found a better approach to spawn the analysis process that doesn't have this issue. So I guess we'll have an RC4 after all.

@MoonshineSG the only way that should be possible is if your sockjs-tornado dependency is not yet version 1.0.2 (which OctoPrint requires since 2015) - I'm a bit at a loss there right now. What does pip freeze | grep sockjs report for you? Should be either 1.0.2 or 1.0.3.

@mgrl I'm able to reproduce this. Let me guess, you had it setup something like "first instance on /, second on /octoprint2"? Because in that scenario I can reproduce due to the fact that after logging into the second instance, it gets cookies sent from the browser for both / and /octoprint2 and sadly the one for / seems to win in the processing, causing the second instance to not recognize the login session and hence anything requiring admin rights to not work (including configuring the online check). That's most likely not a new issue, but more visible now. I'll have to think a bit on how to solve this, this might get tricky.

@cxt666 There were no changes in what commands the buttons on the control panel send and I also cannot reproduce this. Do you also see any X movement commands sent in your Terminal tab? If not, it's on your printer's firmware.

All in all I'm starting to wonder whether I'll ever get this stupid release out of the door, what with all the interruptions I seem to get with it, plus subtle but evil bugs ;) But better they are found now than once the release is out 👍

@MoonshineSG

This comment has been minimized.

Show comment
Hide comment
@MoonshineSG

MoonshineSG Sep 28, 2017

@foosel glad to see you're feeling better. Take it slowly, I bet the backlog is long...

In my case the pip reports sockjs-tornado==1.0.2 (otherwise I guess it would have been upgraded based on the OctoPrint library requirements ?

MoonshineSG commented Sep 28, 2017

@foosel glad to see you're feeling better. Take it slowly, I bet the backlog is long...

In my case the pip reports sockjs-tornado==1.0.2 (otherwise I guess it would have been upgraded based on the OctoPrint library requirements ?

foosel added a commit that referenced this issue Sep 28, 2017

Add & use "octoprint analysis gcode" subcommand
That should solve any weird import issues we have when
running gcodeInterpreter.py directly (and hence putting
octoprint.util as first entry into the python path,
causing potential issues with imported modules such as
yaml to catch the octoprint.util.platform module instead
of the actual python platform module).

See reported problem with that by @CapnBry in #2095

foosel added a commit that referenced this issue Sep 28, 2017

Also include script name in cookie name
Otherwise we might run into trouble if we have an OctoPrint instance
running on / and /octoprint2 for example - the browser will send
cookies for both instances to the /octoprint2 instance and whatever
gets processed last will overwrite the value before in Tornado's cookie
processing. This of course will nuke the login session in case of the /
cookie being sent or processed last.

Appending the path/script root to the cookie name solves this, similar
to how we circumvented an identical problem caused by browsers not
distinguishing between ports for cookies.

Solves an issue reported by @mgrl in #2095

foosel added a commit that referenced this issue Sep 28, 2017

Updated sockjs-tornado dependency
Apparently we need 1.0.3 after all for custom session classes.

Reported by @MoonshineSG in #2095
@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Sep 28, 2017

Owner

@MoonshineSG it turns out that I was wrong and the minimum requirement for that dependency is 1.0.3 after all. I updated that accordingly.

@mgrl, I also found a solution for the problem that you were running into. I've now encoded the target script root into the cookie name, alongside the port number, to get around the browser not making any distinctions here and that leading to cookie overwrites in Tornado.

And the libyaml issue that @CapnBry ran into is also fixed now - turns out that calling the gcodeInterpreter.py directly from the analysis queue caused src/octoprint/util to be prepended to python's lookup path, which in turn then caused issues with imports like platform which also exist in octoprint.util and hence were then resolved to the wrong module. I've turned the gcode analysis into its own subcommand now and use that together with python -m octoprint to start the analysis process now - that gets around this issue and should work everywhere that OctoPrint is installed without causing issues. I just hope that this indeed is the case because it's the only way I could find to not have sys.path "mangled".

I'll poke around the bug tracker a bit more (I still haven't got a full picture sadly, as @MoonshineSG already guessed my general backlog is long) and once I'm sure that everything so far reported with this RC is tackled I'll push out RC4 as the new chapter in this never ending story ;)

Owner

foosel commented Sep 28, 2017

@MoonshineSG it turns out that I was wrong and the minimum requirement for that dependency is 1.0.3 after all. I updated that accordingly.

@mgrl, I also found a solution for the problem that you were running into. I've now encoded the target script root into the cookie name, alongside the port number, to get around the browser not making any distinctions here and that leading to cookie overwrites in Tornado.

And the libyaml issue that @CapnBry ran into is also fixed now - turns out that calling the gcodeInterpreter.py directly from the analysis queue caused src/octoprint/util to be prepended to python's lookup path, which in turn then caused issues with imports like platform which also exist in octoprint.util and hence were then resolved to the wrong module. I've turned the gcode analysis into its own subcommand now and use that together with python -m octoprint to start the analysis process now - that gets around this issue and should work everywhere that OctoPrint is installed without causing issues. I just hope that this indeed is the case because it's the only way I could find to not have sys.path "mangled".

I'll poke around the bug tracker a bit more (I still haven't got a full picture sadly, as @MoonshineSG already guessed my general backlog is long) and once I'm sure that everything so far reported with this RC is tackled I'll push out RC4 as the new chapter in this never ending story ;)

@mgrl

This comment has been minimized.

Show comment
Hide comment
@mgrl

mgrl Sep 28, 2017

@mgrl I'm able to reproduce this. Let me guess, you had it setup something like "first instance on /, second on /octoprint2"? Because in that scenario I can reproduce due to the fact that after logging into the second instance, it gets cookies sent from the browser for both / and /octoprint2 and sadly the one for / seems to win in the processing, causing the second instance to not recognize the login session and hence anything requiring admin rights to not work (including configuring the online check). That's most likely not a new issue, but more visible now. I'll have to think a bit on how to solve this, this might get tricky.

Hello foosel,
I setup the instances on different ports exposed via haproxy. http://3dprinter:80 is the fist, 3dprinter:81 the second and 3dprinter:82 the third. So I don't think that was the issue?

mgrl commented Sep 28, 2017

@mgrl I'm able to reproduce this. Let me guess, you had it setup something like "first instance on /, second on /octoprint2"? Because in that scenario I can reproduce due to the fact that after logging into the second instance, it gets cookies sent from the browser for both / and /octoprint2 and sadly the one for / seems to win in the processing, causing the second instance to not recognize the login session and hence anything requiring admin rights to not work (including configuring the online check). That's most likely not a new issue, but more visible now. I'll have to think a bit on how to solve this, this might get tricky.

Hello foosel,
I setup the instances on different ports exposed via haproxy. http://3dprinter:80 is the fist, 3dprinter:81 the second and 3dprinter:82 the third. So I don't think that was the issue?

@MoonshineSG

This comment has been minimized.

Show comment
Hide comment
@MoonshineSG

MoonshineSG Sep 29, 2017

In that case, how come it's not more widely reported? Anyway, it's good that it's an easy fix.

MoonshineSG commented Sep 29, 2017

In that case, how come it's not more widely reported? Anyway, it's good that it's an easy fix.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Sep 29, 2017

Owner

@mgrl can you share your haproxy configuration? Maybe something's off with that. I cannot reproduce this with different ports per OctoPrint instance, only with a subpath (and that's fixed now too). OctoPrint's cookies are already coded to the port its accessed over to prevent these exact kind of issues, and by default haproxy does provide proxied servers with the required information to do this properly.

What OctoPrint will do is look for X-Forwarded-Host, Host and X-Forwarded-Server & X-Forwarded-Port headers in the incoming request, in that order, and try to extract server name (e.g. octopi.local or 192.168.1.11) and port number (e.g. 80, 5000 or 443) from that. Haproxy does set the Host header to the accessed server name + port combo in generated requests correctly on its own (e.g. octopi.local:82), but if you have it configured to e.g. set X-Forwarded-Host to just the accessed server name without a port number (e.g. octopi.local), OctoPrint will assume the default port for the used protocol (80 for http, 443 for https), which would explain such an issue since then all instances would share the same cookies and depending on usage order sessions will be lost and lead to all kinds of issues.

For reference, here's the config with which I tested just now against 1.3.5rc3:

frontend public2
        bind *:81
        option forwardfor
        default_backend octoprint_vin

frontend public3
        bind *:82
        option forwardfor
        default_backend octoprint_vin2

backend octoprint_vin
        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if { ssl_fc }
        option forwardfor
        server octoprint_vin 192.168.1.3:5000

backend octoprint_vin2
        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if { ssl_fc }
        option forwardfor
        server octoprint_vin 192.168.1.3:5001

The instance on port 81/port 5000 was already configured. The one on port 82/port 5001 was a new one. I was able to successfully complete the setup wizard without any permission issues. A look into the set cookies also verified that the cookies were properly suffixed based on the server port:

image

Owner

foosel commented Sep 29, 2017

@mgrl can you share your haproxy configuration? Maybe something's off with that. I cannot reproduce this with different ports per OctoPrint instance, only with a subpath (and that's fixed now too). OctoPrint's cookies are already coded to the port its accessed over to prevent these exact kind of issues, and by default haproxy does provide proxied servers with the required information to do this properly.

What OctoPrint will do is look for X-Forwarded-Host, Host and X-Forwarded-Server & X-Forwarded-Port headers in the incoming request, in that order, and try to extract server name (e.g. octopi.local or 192.168.1.11) and port number (e.g. 80, 5000 or 443) from that. Haproxy does set the Host header to the accessed server name + port combo in generated requests correctly on its own (e.g. octopi.local:82), but if you have it configured to e.g. set X-Forwarded-Host to just the accessed server name without a port number (e.g. octopi.local), OctoPrint will assume the default port for the used protocol (80 for http, 443 for https), which would explain such an issue since then all instances would share the same cookies and depending on usage order sessions will be lost and lead to all kinds of issues.

For reference, here's the config with which I tested just now against 1.3.5rc3:

frontend public2
        bind *:81
        option forwardfor
        default_backend octoprint_vin

frontend public3
        bind *:82
        option forwardfor
        default_backend octoprint_vin2

backend octoprint_vin
        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if { ssl_fc }
        option forwardfor
        server octoprint_vin 192.168.1.3:5000

backend octoprint_vin2
        reqrep ^([^\ :]*)\ /(.*) \1\ /\2
        reqadd X-Scheme:\ https if { ssl_fc }
        option forwardfor
        server octoprint_vin 192.168.1.3:5001

The instance on port 81/port 5000 was already configured. The one on port 82/port 5001 was a new one. I was able to successfully complete the setup wizard without any permission issues. A look into the set cookies also verified that the cookies were properly suffixed based on the server port:

image

@andrivet

This comment has been minimized.

Show comment
Hide comment
@andrivet

andrivet Sep 29, 2017

@foosel It is great that you find a solution for the cookie problem. I face the same issue when writing my Installing multiple OctoPrints on Raspberry Pi 3 running Raspbian post (but I thought it was my fault...). I will now be able to simplify the procedure. So as soon as RC4 is out, i will specifically check that point.

andrivet commented Sep 29, 2017

@foosel It is great that you find a solution for the cookie problem. I face the same issue when writing my Installing multiple OctoPrints on Raspberry Pi 3 running Raspbian post (but I thought it was my fault...). I will now be able to simplify the procedure. So as soon as RC4 is out, i will specifically check that point.

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Sep 29, 2017

Owner

@andrivet the subpath cookie problem? Yeah, that was me missing a detail about how browsers serve cookies back (if there's a cookie of identical name for both / and /subpath/, both will be sent by the browser when /subpath/ is accessed), combined with tornado throwing all but the last cookie of a certain name away.

Just took a quick look at the the nginx config in your blog post again, and I think that will produce issues with port numbers. proxy_set_header Host $host; leaves the port out (nginx doesn't include that in the $host variable), if I remember correctly you need proxy_set_header Host $host:$server_port; to be on the safe side. Not a problem when you run http on port 80 and https on port 443, but it will cause issues if you listen on a non standard port.

Owner

foosel commented Sep 29, 2017

@andrivet the subpath cookie problem? Yeah, that was me missing a detail about how browsers serve cookies back (if there's a cookie of identical name for both / and /subpath/, both will be sent by the browser when /subpath/ is accessed), combined with tornado throwing all but the last cookie of a certain name away.

Just took a quick look at the the nginx config in your blog post again, and I think that will produce issues with port numbers. proxy_set_header Host $host; leaves the port out (nginx doesn't include that in the $host variable), if I remember correctly you need proxy_set_header Host $host:$server_port; to be on the safe side. Not a problem when you run http on port 80 and https on port 443, but it will cause issues if you listen on a non standard port.

@cxt666

This comment has been minimized.

Show comment
Hide comment
@cxt666

cxt666 Sep 29, 2017

@foosel Without fully understanding the commands it does not seem that anything else than Z should be moved:

Send: N8 G91*25
Recv: ok 8
Send: N9 G1 Z10 F200*14
Recv: ok 9
Send: N10 G90*33
Recv: ok 10

So, please forget about this...

cxt666 commented Sep 29, 2017

@foosel Without fully understanding the commands it does not seem that anything else than Z should be moved:

Send: N8 G91*25
Recv: ok 8
Send: N9 G1 Z10 F200*14
Recv: ok 9
Send: N10 G90*33
Recv: ok 10

So, please forget about this...

@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Sep 29, 2017

Owner

@cxt666 :) Just to clear things up here:

  • G91 - switch to relative positioning (so "X10" moves X 10 mm to the right, not to X=10mm which it would do in absolute positioning)
  • G1 Z10 F200 - move Z up by 10mm with feedrate 200
  • G90 - switch (back) to absolute positioning
Owner

foosel commented Sep 29, 2017

@cxt666 :) Just to clear things up here:

  • G91 - switch to relative positioning (so "X10" moves X 10 mm to the right, not to X=10mm which it would do in absolute positioning)
  • G1 Z10 F200 - move Z up by 10mm with feedrate 200
  • G90 - switch (back) to absolute positioning
@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Oct 2, 2017

Owner

Just for your interest, I'm currently targeting a release of RC4 for wednesday (and I hope I haven't just jinxed that with this announcement, considering my past track record 😒). Changelog looks like this right now:

Bug fixes

  • #2135 - Fixed an issue causing import issues inside the GCODE analysis tool in certain environments due to sys.path entries causing relative imports.
  • #2136 - Fixed wrong minimum version for sockjs-tornado dependency.
  • #2137 - Fixed issue with session cookies getting lost when running an OctoPrint instance on a subpath of another (e.g. octopi.local/ and octopi.local/octoprint2).
Owner

foosel commented Oct 2, 2017

Just for your interest, I'm currently targeting a release of RC4 for wednesday (and I hope I haven't just jinxed that with this announcement, considering my past track record 😒). Changelog looks like this right now:

Bug fixes

  • #2135 - Fixed an issue causing import issues inside the GCODE analysis tool in certain environments due to sys.path entries causing relative imports.
  • #2136 - Fixed wrong minimum version for sockjs-tornado dependency.
  • #2137 - Fixed issue with session cookies getting lost when running an OctoPrint instance on a subpath of another (e.g. octopi.local/ and octopi.local/octoprint2).
@foosel

This comment has been minimized.

Show comment
Hide comment
@foosel

foosel Oct 4, 2017

Owner

Marking as closed because 1.3.5rc4 has been released. Comments are still possible though.

New feedback ticket is #2141

Owner

foosel commented Oct 4, 2017

Marking as closed because 1.3.5rc4 has been released. Comments are still possible though.

New feedback ticket is #2141

@foosel foosel closed this Oct 4, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment