When setting the tracked target temperature from a sent temperature
command, the changes in tracked temperature were not propagated
from the comm layer to registered callbacks.
But since the standard printer also didn't make a copy of the mutable
dict of tool temperatures, those were in fact updated even without
propagation in the printer implementation when the values in the
comm layer got updated, whereas the bed temperature - an immutable
tupel - was not.
Two wrongs sometimes do in fact make a right. In this case that led
to target temperature changes on the tools immediately reflecting
in printer.get_current_temperatures after the command was sent,
but changes to the bed target taking until the next M105 response
to propagate.
Decoupling the data structures and adding propagation commands
to the comm layer solves this issue.
Fixes#1543
-r only allows a limited set of target framerates according to the mpeg2
standard, but -framerate allows to specify how long each frame should
be shown, giving us full control over "virtual" fps without causing errors
when the user selects a non-standard frame rate
Long lines (longer than rx buffer) could not be processed at all, leading
to a serial timeout exception thrown by the virtual printer. Adjusted
to allow for partial processing like on maintenance
That way a JS error in an external plugin won't nuke the whole UI, which IMHO
is worth the additional requests needed to load the split up files.
See #1544 for an example of such a situation.
The bug only manifests if a user had installed 1.2.16 earlier and never once hit "Save" in the
settings before attempting to update to 1.2.17. With 1.2.16 the updater script and settings for
OctoPrint's own update mechanism were changed to prefer "checkout_folder" instead of
"update_folder". In earlier versions however "update_folder" was still used. Saving settings
even once (even without any changes!) will migrate the data. But if that's not done a
KeyError will be raised when trying to retrieve "update_folder" from the check config, with
"checkout_folder" as its fallback.
Rather stupid error really.
* show special error if timelapse can't be rendered due to no frames having
been captured
* inform user during print about repeated capture errors
* do not start post roll recording if after a print no frames were captured at all
* also interpret non-ok-ish return codes from snapshot url as capture error
* documentation for CaptureFailed event
Filter toggling didn't remove the specific filter but always the last item
in the filter list. No, I don't know either why I didn't notice this earlier m(
