Option to manually tell SimplyPrint if a print was successful after printer error (printer fails to report status)#259

Currently, if the printer fails to communicate with simplyprint (aka it disconnects or internet goes down or something) then the platform autoamtically assumes the print failed and adds it back to the queue even if the print was successful but disconnected from the platform.

It would be great if in this case when we click the “Print Removed?” button for the platform we have the option to tell the system that it was successful so that it does not get added back to the queue by mistake. This would also make the statistics page more accurate in terms of print failures etc.

This is the specific error simplyprint says even though the print completed successfully:

Print failed! This print was stopped due to an error that occurred outside SimplyPrint.

Reason; Failed due to the printer suddenly no longer reporting “printing” state. No errors from Bambu reported

@Muddassir Mohammed I definitely see your point. However, for non-Bambu users, this is hardly ever a problem. So, I’d wait for the Bambu Lab integration to be finished, when issues like the connection problems that can cause this, are fixed, to see if you (and others) still deem this a problem (no need to solve problems that spawn from other problems, that soon won’t exist).

We’ll keep this open, and it’s by no means a “definite no” from our side, and it could be implemented in a nice way if the problem behind it persists.

One thing we’re doing in our OctoPrint and Klipper integrations, is that if it loses internet connection or just loses connection to our server, it locally stores the job status, and tells it to us once the printer reconnects to our servers, which allows us to go back and say “Hey, this job that we didn’t know what happened to, and therefore marked it as ‘Failed’ on the last known completion-percentage was actually completed!”. This removes the issue of “Internet / connection lost”, and as we’re implementing this in the Bambu Lab integration in the future as well, I could see this not being an issue at all in the future.

Of course, when OctoPrint and Klipper loses connection to the printer, the print is 100% failed, as connection lost means OP/Klipper can’t feed the print to the printer, and thereby it fails, whereas our Bambu integration is different; the printer can keep on printing even if the local client loses its MQTT-connection. I can’t say how many print jobs with wrong states are due to this - if it’s in any way frequent, and we can’t do something smart where we, locally, go back and ask the printer “Hey, that job; what happened?”, we may have to implement something like what you suggest.

Thanks for taking the time to write a suggestion! This is indeed a real problem that requires a real solution - though the solution can have many forms. Keep em’ coming!