Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Terminal enableFancyFunctionality gets disabled when processing is too slow (like a tab is in the background), but never gets re-enabled #1862
What were you doing?
Printing with the UI open and in a background tab
What did you expect to happen and what happened instead?
Expected result: Terminal is switched to non fancy mode due to performance decrease in background tabs. Once tab is brought to the foreground the Terminal is switched back to fancy mode due to performance returning to normal.
Branch & Commit or Version of OctoPrint
OctoPrint 1.3.2 (master branch)
Operating System running OctoPrint
Raspberry PI 2B
Linux octoprint 3.18.11-v7+ #781 SMP PREEMPT Tue Apr 21 18:07:59 BST 2015 armv7l GNU/Linux
PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
Printer model & used firmware incl. version
Micromake D1, Azteeg X5 Mini 1, latest edge of smoothieware
Browser and Version of Browser, Operating System running Browser
macOS Chrome 57.0.2987.133 (64-bit)
Link to octoprint.log
I don't think I need to include this as its a UI bug
Link to contents of terminal tab or serial.log
Same as above. Not needed for a UI bug
Screenshot(s) or video(s) showing the problem:
I have read the FAQ.
Just adding this issue here as we spoke about it a little while back on IRC, but I wanted to make sure it got logged so it didn't get forgotten (and I haven't noticed a commit to reflect it being fixed - so this is also to be used as a reminder :-) )
Performance is never evaluated again after fancyFunctionality is disabled for the terminal. So once it gets disabled it never gets re-enabled till you reload the entire interface.
And at least under chrome when the Octoprint tab is in the background it often gets dinged performance wise so the processing time of log messages while printing some times drops below the acceptable limit. But when the tab is back in the foreground performance increases again to well within acceptable limits, but sadly the terminal is still in dumb mode :-(
It looks like there is some information missing from your bug report that will be needed in order to solve the problem. Read the Contribution Guidelines which will provide you with a template to fill out here so that your bug report is ready to be investigated (I promise I'll go away then too!).
If you did not intend to report a bug but wanted to request a feature or brain storm about some kind of development, please take special note of the title format to use as described in the Contribution Guidelines.
Also make sure you are at the right place - this is the bug tracker of the official version of OctoPrint, not the Raspberry Pi image OctoPi nor any unbundled third party OctoPrint plugins or unofficial versions. Make sure too that you have read through the Frequently Asked Questions and searched the existing tickets for your problem - try multiple search terms please.
I'm marking this one now as needing some more information. Please understand that if you do not provide that information within the next two weeks (until 2017-04-25 16:00 UTC) I'll close this ticket so it doesn't clutter the bug tracker. This is nothing personal, so please just be considerate and help the maintainers solve this problem quickly by following the guidelines linked above. Remember, the less time the devs have to spend running after information on tickets, the more time they have to actually solve problems and add awesome new features. Thank you!
PS: I'm just an automated script, not a human being, so don't expect any replies from me :) Your ticket is read by humans too, I'm just not one of them.
Should be fixed now on
So far so good. Seams to flip back and forth as needed. haven't tried it during printing, but just having it spit out 105's is enough to see it.
A good way to test also it so throw a breakpoint into the log message processing stack somewhere. Just sit on it for a second and then continue. Then remove (or disable the breakpoint).
Temporarily causes log processing to take a while and then return to normal speed.
@pyjamasam I was out of a commission for the past week. Just now took a look (using the same breakpoint approach that you described, which I actually also used during development testing), but I can't reproduce the "scrolling stops" behaviour right now over here. Did this only happen during actual printing or did you also repro this with the breakpoint approach?
No worries @foosel.
So the funny terminal behaviour some times manifests its self as the auto scrolling not working, and sometimes it just ends up being slightly "off" when scrolling.
The other part of this is that if I add some debug logging as the first line in TerminalViewModel.scrollToEnd it doesn't ever get called.
Once I rename scrollToEnd to scrollToEnd2 (and update the calling methods to reference this new name) then I see the debug logging as well as better auto scrolling.
I am running commit 844494a now as well.
Hope that helps.
My apologies for not catching that. Yes it looks like I do have something that overwrites the terminal's scrollToEnd method.
I can confirm disabling that plugin makes the issue go away.
Only thing I have noticed now (and it might be a side effect of using the background animation stuff to do the scrolling is that if I click on another chrome tab and leave octoprint in an inactive tab with the terminal visible for a little bit and then click back to octoprint's tab the auto scrolling hasn't happened and the terminal text is off the bottom. As soon as another log message comes in the auto scrolling is done and the display looks correct. Should never be an issue when priting due to the speed at which log messages come in. But I notice it when just getting M105 requests and responses when idle.
I don't think its anything that needs to be fixed. Just an observation.
I'll open a ticket on the autoscroll repo to deal with this as its whats broke.
I think this ticket can be closed as the original issue has been corrected. (well I guess close it when the release is released :-) )