Timelapse "Capture post roll images" misbehaves

[ntoff]

---

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
and
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:
https://gist.github.com/ntoff/bfcc679483bf1bbabbf9d7368c089c17

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!

https://www.youtube.com/watch?v=8UwgF4xdXug

I have read the FAQ.

[foosel]

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]

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)

[marclefevre]

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.

[foosel]

@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 :)

[marclefevre]

I believe that I must have NOT checked "save as default". I saw the problem reproduce after printing a file because the postroll window came up indicating that postroll collection was in progress. I also misspoke when I said that I was in the setting manager when I observed the old settings returning. I realized later that you just have to go into the timelapse tab to see the settings. So, ignore that comment. I've been trying to reproduce the problem again since I made the comment on the forum so I could give you more details but I have not been able to. It's very likely that this is operator error so I'll encourage you to ignore this until I can reproduce the problem with the details you'll need to try to solve it. Sorry to have wasted your time.

…

On Wed, Jun 14, 2017 at 4:37 AM, Gina Häußge ***@***.***> wrote: @marclefevre <https://github.com/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 :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1821 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AcBjZe0m9sWtkAePfvkzei8pLrKNOCKDks5sD6nRgaJpZM4Mawh3> .