I know I can disable the timelapse feature. That's not at all what I'm asking and I've found pretty much nothing about this.
I'm using a Pi Zero 2W, which works for printing, but is s-l-o-w in rendering a timelapse. I've had a number of times when something goes wrong on an overnight print and the printer stops and turns off the bed and head heaters and sits there for many hours until I wake up and get to it. When this happens, it can take 10-20 minutes to render the timelapse. (So far, on this one, I've been waiting 15 minutes!)
It's extremely frustrating when I have a complete print, but the render is taking forever because filament ran out and it was hours before I could get to the printer to put a new spool in for a few more minutes of printing. Now it's done and I have to wait for the timelapse to completely render before I start my new print.
I've seen a few people ask about this, but never seen a case where anyone seemed to get their question. The answer always seems to be, "You can disable timelapse here." NO. Not what I'm asking. I am hoping there's a way to stop the rendering process. I considered the idea of using ssh to log in, then find the directory with all the stills timelapse uses and just deleting them. That's kludgey. I'm not clear why, with a process that can take a long time, there's no "Cancel" button to stop it if you don't want it to finish.
The next release of OctoPrint version 1.11.0 will have additional options related to timelapse rendering.
#1313: Added an option for whether to automatically render captured timelapses. Timelapses can now be set to never render automatically, only in case of a successful or only in case of a failed print, and of course also always (the previous behaviour). See also PR#4994.
Interesting. I know, before, you could set it to only render timelapses for successful prints and I think there were a few other criteria you could pick. With this new option, does that mean you can set it to not render and then, if you want to see the timelapse for a particular print, could you manually start the rendering process?
I'm finding it interesting there is a workaround for this, but not a way to just cancel while it's rendering.
Perhaps I'm a bit naive but pkill ffmpeg should cancel the rendering process.
One could build a bash script around that command if there is other cleanup desired, and the Custom Control Manager can be used to add a control on the OctoPrint web interface.
Maybe I misremember, but I am pretty sure that one time I rebooted and the rendering process just restarted, so I figured killing it wouldn't help much. Maybe I remember wrong.
I was not aware of the Custom Control Manager, so I'm looking into that later today.
What triggers the timelapse system to start ffmpeg? Does it get triggered on boot or the completion of a print, then checks if conditions are met, then starts rendering? I'm just wondering about what happens if I kill it and delete all the stills. Would that guarantee it wouldn't try to start and fail in some way if the stills were gone?
I know the timelapse processing gets triggered when a print finishes.
I suspect that if you kill it and delete all the stills, that should be enough. I'd have to do some experimenting to be sure.
With this new option, does that mean you can set it to not render and then, if you want to see the timelapse for a particular print, could you manually start the rendering process?
I just ran a test with 1.11.0rc7 and yes, that is exactly what that means. The finished timelapse below was with Render timelapse after print "Always" and then I changed the setting to "Never" and now have the unrendered options to render or delete.
I'm not sure I follow this completely. Are you saying that, with the new RC, that if I pick "Never" for rendering, that if I run a print and it goes bad, I can still render it so I can see what went wrong? Or if it went well and I want to show someone a timelapse of it, I can still just click a button to render it? (I would assume I have to render it before I do another print and only the stills from the last print would still be there?)
Side note on this issue: I'm at a disadvantage. Right now I only have one printer that's not down for maintenance and upgrades - the one I had this issue on. It's on a Pi Zero 2W and I've been planning to upgrade that to a Pi 3 for a while. For some reason, ssh is not working on it, so I can't log in that way to check on things like if the still images are there (or to delete them). It's not worth fixing ssh on this system, since I'll be replacing it soon.
This is exactly what never means. It should work with multiple, and the collected images for the render job will stay for a grace period, which is configurable in config.yaml directly.
It's currently a 7th release candidate, so probably in the next couple of weeks to a month I suspect. You could easily switch yourself from the software update settings. it should be stable enough now that I suspect there won't be any changes between it and when it's released, unless something wildly wrong gets reported. would have expected to see something by now, it's been out for two weeks and haven't seen any issues reported.
