Improved connecting for some printers, destroyed it
completely for others, so this needs some more work/
thought before it's ready for prime time.
This reverts commit c82ec3d3af.
M110 is now sent every second until either a connection is established or the connection
attempt times out. That should prevent connection handshakes from failing due to
some initial garbage on the line that swallows an ok.
We currently do not have a storage configured for SD card since
that hasn't yet been ported to the storage interface. So on an
SD card fail we need to capture that error when attempting to log
the print recovery data, or there will be issues processing
the cancel properly. A bit more of error handling is a good
idea here in any case too.
Fixes#1226
In case of trying to switch to state printing with no selected file that
scenario is now caught by setting an internal manualStreaming flag.
That will stop the M105 polling until M29 is sent (through whatever
means).
Note that printing is not disabled... this is merely for testing stuff and
not encouraged to be used for actually streaming files to the printer,
use the built-in functionality for that!
This reverts commit 1e429606e1.
Commit used functionality that currently is only available in
Chrome and maybe Opera. No alternative solution could be found
that works reliably across browsers.
* persistent notification on ongoing timelapse render job (#485)
* non-colliding timelapse snapshot name generation to not delete
existing snapshots when new print starts and timelapse has not
yet been rendered, also only delete snapshots if timelapse rendered (#318)
* list of unrendered timelapses, with option to delete files
or to render timelapse
Use this carefully. An error reported by your firmware usually hints
at something being off about your printer (e.g. thermistor troubles)
or the firmware not being fully compatible to OctoPrint since
it doesn't recognize a lot of commands.
If you print with this option enabled, it will still fail if you firmware goes
into lockdown, but now it will keep trying to send data to your printer.
That might cause issues. So best not use that option, only if you absolutely
have no other way to get some misbehaving printer to work with
OctoPrint.
The client now tries to detect if it's fast enough to process the
state updates usually send every 500ms, and if not notifies the
server to throttle the rate (e.g. to 1/1s, 1/1.5s etc).
Additionally, since the terminal tab of the client turned out to
be quite CPU intense when line number calculation, filtering etc
is enabled, the terminal tab now also falls back into a bit less
fancy mode if it detects its being processed too slow and optionally
even disables logging completely during printing (where a lot
of log messages need to be processed in a minimum amount of
time).
That way the UI should stay responsive even on very low powered
clients (e.g. chromium on a Pi), while printing.
We suffer from the same problem as commands being suppressed in the
send queue here. If a non-GCODE-command we send to the printer
produces no output, our _monitor loop will wait until the next response
produced by another command. Which we won't send though since
we are stuck waiting in the _monitor loop waiting for a response. Hence
we need to manually trigger further command processing from the
send loop here in order to ensure things keep going.
Also make sure that if we have a pkg_resources version that returns
tuples we not only remove any intermediary version parts if the base
version is requested, but we also append "*final" to the tuple afterwards,
otherwise the compatibility check will fail.
That way people will not see connection failed messages while the server is
still starting up.
Served intermediary page als "pings" an image on the backend to detect if
a) the backend is still responding at all ("intermediary.gif") and b) whether the
server has fully started up ("online.gif").
If the backend stops responding for 5s, a message is output that tells the user
that something went really wrong and to please check the log file.
Once the server becomes online, the intermediary page reloads/switches to the
actual UI.
When autoscroll was disabled, terminal could run on endlessly, eating
memory until the browser crashes. Now a hard upper limit ensures
that not more than 3000 lines are ever stored in the terminal. If autoscroll
is disabled and the limit is reached, no more log lines will be added. That
ensures that the log will not scroll and the current log excerpt will stay put.
UI + assets should actually have ETag and LastModified headers and proper
IfMatch handling on the server side and hence the server should do the
right thing on its own.
That should improve performance tremendously.
Both ETag and LastModified depend on all files the template rendering
depends on. If any of the depended on files changes, both values will
change as well. That allows us to track whether our cached copy is
still current (and force a refresh if not) and also process IfMatch request
headers and reply with a 304 directly so that we do not even have to
transfer the data if nothing changed and the browser still has it.
Also now tracks timestamps of last access to a preemptively cached
resource and cleans up stuff that hasn't been accessed in a while (7 days
by default)
Introduced a @preemptively_cached decorator that for decorated views
persists the provided data in ~/.octoprint/data/preemptive_flask_cache.yaml
in a list indexed by the view's path if the data is not yet part of the list.
During initialization the server will iterate over the persisted paths and data
and for each persisted path and entry in the list initialize a temporary WSGI
environment based on the data (which is interpretated as keyword arguments
to werkzeug's EnvironmentBuilder) which will then be used to call the view
function in the correct context.
The current implementation for / and /i18n/<locale>/messages.js utilizes
that decorator to allow preemptive caching of those views (/ being probably
the most expensive one in the whole core application) utilizing request base URLs
(internal access, external access, reverse proxy with prefix url etc) that had been
encountered in the past.
Through the new config setting server.preemptiveCaching.exceptions it is
possible to define a set of base URLs to never cache. Preemptive caching can
be globally disabled by setting devel.cache.preemptive to false.
This way we create separate caches for URLs access via different schemes/prefixes/etc.
Otherwise our generated page might not work when accessing OctoPrint from external
after accessing it from internal once.
Otherwise the GCODE Viewer will get stuck "half way through" if
"sync with progress" is enabled but the tab/browser tab loses focus
during printing and only regains it after the print has finished.
This might help with #1065 if indeed is related to background tab suspending behaviours in
browsers, but is a completely blind guess at this point since I still have not been able to
reproduce that issue myself.
Backported.
(cherry picked from commit 720cdad)
