Skip to content
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

Timelapse "Capture post roll images" misbehaves #1821

ntoff opened this issue Mar 13, 2017 · 5 comments


None yet
3 participants
Copy link

commented Mar 13, 2017

What were you doing?

Fiddling about as usual, testing some timelapse stuff.

To reproduce:

Turn timelapse on, turn OFF capture post roll images, save as default.

Turn timelapse mode OFF, save as default.

Turn timelapse back on, observe that "capture post roll images" checkbox is NOT ticked, even though default is: value self.defaultCapturePostroll = true;, but also neither is it set to "false" anywhere in config.yaml anymore (since it's removed upon setting timelapse mode to "off"), tick save as default, and press save, and observe that "capture post roll images" has now enabled itself without ever having being clicked.

What did you expect to happen?

"Capture post roll images" checkbox to stay unchecked.

What happened instead?

Upon saving, the checkbox will enable itself if disabled.

Branch & Commit or Version of OctoPrint

Version: 1.3.1 (master branch
OctoPrint 1.4.0.dev215+g8107d65 (devel branch)

Printer model & used firmware incl. version

Home made mendel90 and the built in virtual printer

Browser and Version of Browser, Operating System running Browser

Chrome Version 56.0.2924.87 and Firefox 51.0.1 (32-bit) on windows 10 pro

Link to octoprint.log

Nothing to report, but here:

Link to contents of terminal tab or serial.log

n/a, not a serial issue

Link to contents of Javascript console in the browser

Still, nothing to report.

Screnshot? NO! New fangled moving pictures!

I have read the FAQ.

@foosel foosel added this to the 1.3.3 milestone Mar 14, 2017


This comment has been minimized.

Copy link

commented Mar 14, 2017

That should be fixed now on maintenance and will also be merged to devel ASAP. Was a whee bit too late though to still make it into 1.3.2 for which the first (and as it looks now only) RC was released on friday, so this fix will have to wait for a stable release until 1.3.3.

foosel added a commit that referenced this issue May 24, 2017

Better fix for #1821
Instead of disabling capturing of postroll by default (which we actually
don't want and doing so was a mistake thanks to misremembering the
meaning of the variable in question), we now properly reset the
default value for that check box (which wasn't properly set only due to
a very stupid typo).

This comment has been minimized.

Copy link

commented May 24, 2017

I realized my prior fix was not really a fix, but at least it made a bug show up we'd otherwise not found for a while probably (see #1934). New fix now on staging/maintenance, soon on maintenance and devel and to be deployed with 1.3.3rc3 (hopefully later today)

@foosel foosel closed this in 315a80a May 31, 2017


This comment has been minimized.

Copy link

commented Jun 12, 2017

I have version 1.3.4 and I'm still seeing this behavior. I can turn off "capture post roll images" and save. When I come back to the settings manager, it's still set.


This comment has been minimized.

Copy link

commented Jun 14, 2017

@marclefevre "save" or "save as default"? And what do you mean with "when I come back to the settings manager"? After a server restart? After a page reload?

Step by step reproduction instructions would be awesome :)


This comment has been minimized.

Copy link

commented Jun 14, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.