FormerLurker / Octolapse

Stabilized timelapses for Octoprint
GNU Affero General Public License v3.0
637 stars 99 forks source link

[Request] Ability to automatically discard failed/cancelled print timelapses #795

Open andreicozma1 opened 2 years ago

andreicozma1 commented 2 years ago

If this is a feature request describe it here

The ability to not render or create timelapses from failed or purposefully cancelled prints. The reasoning behind this is that I find myself always having to delete timelapses of failed or canceled prints manually. For this feature, a checkbox could be used to enable it. When enabled, octolapse runs as normally, with the exception that if the print fails or is cancelled, the timelapse is automatically discarded and nothing is rendered. If the print succeeds, timelapse is processed and rendered as normal.

Version of Octolapse

Octolapse Version: v0.4.1

Version of OctoPrint

OctoPrint Version: 1.7.2

When you ran into the problem, did you have diagnostic logging enabled?

Diagnostic Logging was Enabled: _REPLACE_THISYES_OR_NO

What were you doing when the problem occurred

  1. _REPLACE_THISSTEP_ONE_GOES_HERE
  2. _REPLACE_THISSTEP_TWO_GOES_HERE
  3. _REPLACE_THISSTEP_...

What should have happened?

_REPLACE_THISPUT_YOUR_DESCRIPTION_HERE

What happened instead?

_REPLACE_THISPUT_YOUR_DESCRIPTION_HERE

Operating System running OctoPrint and Octolapse

OS Name: _REPLACE_THISOS_NAME_GOES_HERE Os Version: _REPLACE_THISOS_VERSION_GOES_HERE

Printer model & used firmware incl. version

Printer Model: _REPLACE_THISPRINTER_MODEL_GOES_HERE Printer Firmware Version: _REPLACE_THISPRINTER_FIRMWARE_VERSION_GOES_HERE

Browser and version of browser, operating system running browser

Browser: _REPLACE_THISBROWSER_VERSION_GOES_HERE Browser OS: _REPLACE_THISBROWSER_OS_GOES_HERE

Link to the gcode file you were printing when the problem occurred

Link to Gcode File: _REPLACE_THISGCODE_FILE_LINK_GOES_HERE

Link to settings.json

Link to settings.json with all passwords removed: _REPLACE_THISSETTINGS_JSON_LINK_GOES_HERE

Link to plugin_octolapse.log

Link to plugin_octolapse.log: LINK_GOES_HERE

Link to octoprint.log

Link to octoprint.log: _REPLACE_THISLINK_GOES_HERE

Link to contents of Javascript console in the browser

Link to javascript console output: _REPLACE_THISLINK_GOES_HERE

Screenshots and/or videos of the problem:

Screenshot/Video Links: _REPLACE_THISLINKs_GO_HERE

Please consider becoming a patron

If you like this project, please support my work by becoming a patron, and consider adding a 'star' to the repository. It takes a lot of time and effort to maintain the project and respond to issues. The cost of test prints, software, cameras, printer parts, etc. can quickly add up, so every bit helps.

You can find various videos and tutorials by subscribing to my Youtube channel. You can also follow me on Twitter.

FormerLurker commented 2 years ago

Sorry for not getting back to you sooner. I'm playing serious catchup after being MIA for over 6 months due to some personal/work issues. I'm back, but there is a mountain of issues to deal with, lol!

I actually used to have this option, and it was removed. I was getting issues where people were complaining they didn't get a timelapse, and pulled it at some point. Mostly this was done to reduce debugging efforts for non-issues, but also because I don't like surprising users.

However, I'll reconsider this. As long as I can figure out a way to make it 100% obvious to the user that it is an option they set that prevented the timelapse from being generated.

As an alternative, what about a 'Clear Timelapses for Failed Prints', or a way to filter/select/delete those timelapses in a more convenient way within the file browser? I'm just trying to think of a way to make this easy enough to do manually that the option you are requesting might not be as necessary.

I think there is a 'purge' plugin (don't know the name) that can auto delete files in some situations. I can look for this too, as it might be a solution.

andreicozma1 commented 2 years ago

Sorry for not getting back to you sooner. I'm playing serious catchup after being MIA for over 6 months due to some personal/work issues. I'm back, but there is a mountain of issues to deal with, lol!

I actually used to have this option, and it was removed. I was getting issues where people were complaining they didn't get a timelapse, and pulled it at some point. Mostly this was done to reduce debugging efforts for non-issues, but also because I don't like surprising users.

However, I'll reconsider this. As long as I can figure out a way to make it 100% obvious to the user that it is an option they set that prevented the timelapse from being generated.

As an alternative, what about a 'Clear Timelapses for Failed Prints', or a way to filter/select/delete those timelapses in a more convenient way within the file browser? I'm just trying to think of a way to make this easy enough to do manually that the option you are requesting might not be as necessary.

I think there is a 'purge' plugin (don't know the name) that can auto delete files in some situations. I can look for this too, as it might be a solution.

I think your suggestion of an alternative sounds great. The "Clear Timelapses for Failed Prints" I think would be a clean and simple way to save some time!

chibiconsulting commented 2 years ago

2nd this request. At least I can stop searching for the option that was removed. ;) I would prefer not wasting CPU cycles to render anything when I have canceled the print so that I can immediately start printing again.