Reduced activity mode

Get Help
1

What is the problem?

Let me start by saying that I absolutely love OctoPrint. It makes using my printer so much easier. But I think Octoprint doesn't cares for me in the same way.

I'm not in a position to use my 3D printer on a regular basis. As a result Octoprint sits idle for fairly long periods of time. There no particular pattern to the idleness. Sometimes I go one week between uses, other times I might go three months between uses.

During those idle periods, Octoprint often encounters some kind of problem and shutdown/crashes. Since I'm not using Octoprint during those periods I don't know it has happened and therefore I don't usually know why. I would estimate that in the past 4 years, this has happened 12-15 times. I have never been able to repair the issue (whatever it may have been) and I invariably reinstall Octoprint. That's not so terrible, but taking an hour to re-set-up octoprint every time I want to use it is a hassle.

I guess what I would like to know is this: Is there there a way to prepare Octoprint for extended periods of idleness?

What did you already try to solve it?

Making Debian read-only (didn't help).
Studying the error logs for some clear failure (nothing has ever stuck out).
Shutting down between Octoprint uses. About half the time Octoprint fails to start-up when I restart the pi.
I have replaced the SD card repeatedly. I'm certain that the SD Card is not becoming corrupted.

Have you tried running in safe mode?

Yes.

Did running in safe mode solve the problem?

No

Systeminfo Bundle

I doubt this will help. I was typing this cry for help while reimaging Octoprint again.

browser.user_agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
connectivity.connection_check: 1.1.1.1:53
connectivity.connection_ok: True
connectivity.enabled: True
connectivity.online: True
connectivity.resolution_check: octoprint.org
connectivity.resolution_ok: True
env.hardware.cores: 4
env.hardware.freq: 1500.0
env.hardware.ram: 912539648
env.os.bits: 32
env.os.id: linux
env.os.platform: linux
env.plugins.pi_support.model: Raspberry Pi 4 Model B Rev 1.1
env.plugins.pi_support.octopi_version: 1.0.0
env.plugins.pi_support.octopiuptodate_build: 1.0.0-1.9.3-20231009151442
env.plugins.pi_support.octopiuptodate_build_short: 2023.10.09.151442
env.plugins.pi_support.throttle_check_enabled: True
env.plugins.pi_support.throttle_check_functional: True
env.plugins.pi_support.throttle_state: 0x0
env.python.pip: 22.3
env.python.version: 3.9.2
env.python.virtualenv: True
octoprint.last_safe_mode.date: unknown
octoprint.last_safe_mode.reason: unknown
octoprint.safe_mode: False
octoprint.version: 1.9.3
printer.firmware: Marlin 2.0.9.1 (Sep 25 2021 07:51:49)
systeminfo.generated: 2023-12-17T15:51:09Z
systeminfo.generator: zipapi

WRITE HERE

Additional information about your setup

OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible

WRITE HERE

2

This is a very bad stat, and implies something is definitely wrong somewhere. It should not fail to restart and have to be reimaged every other time you turn it off. A lot of people turn off their Pi when they are not printing, while a lot also don't.

I'd probably be inclined to sort this unreliability. OctoPrint should have no issues running forever. It certainly shouldn't need to be prepared to do so, and should just carry on and work.

Maybe next time you experience an issue restarting etc., it would be good to go through some troubleshooting steps, and we can see if we can figure out why it's not started up again. There's no such thing as it silently failing to start, we'll be able to figure out a reason somehow.

3

OK. I appreciate that someone responded. I had sorta figured there wouldn't be an easy answer. This is very definition of an intermittent problem.

After I finish the project I'm working on I'll let Octoprint sit idle and ask for help the problem happens again.

Thanks for your help.

4

as Charlie mentioned, it shouldn't die in a way to not be able to start. most times we've seen this in the past is because of failure to cleanly shutdown the pi prior to pulling power. this in some cases has caused SD card corruption, hence the need to reflash.

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.