After installing the preheat button, octoprint doesn't start properly. I had tried installing it from the command line, and that failed, so I tried again using the graphical interface, and that seemed to work, but after rebooting, there are two python processes that are each consuming 100% of a CPU. The system is unusable. If I didn't have a fan on it, it would be thermal throttling.
Until recently, I have been using the OctoPi 0.18.0 & OctoPrint 1.7.2 with preheat. I tried to in-place upgrade OctoPi, OctoPrint, platformio and marlin, and somehow the image got corrupted and the SD wouldn't boot anymore. I started over with a fresh SD chip with the latest release (Octopi 1.0.0 and Octoprint 1.9.3), and printed two items from Cura to Octoprint, and it worked fine. Then I decided to add the preheat button, and that's when things went wrong.
What did you already try to solve it?
Reboot several times.
Have you tried running in safe mode?
No. System is too unresponsive. Willing to do it from the command prompt if someone will show me how.
Did running in safe mode solve the problem?
No. Can't get that far
Systeminfo Bundle
I can't get far enough to reach OctoPrint's System Information dialog ...
Yeah, well, this is discouraging. I started over - fresh SD, fresh install - came up great. I went to install the preheat button - from inside the web interface this time, no attempt at command line - and ended up in the same place. Multiple threads in two python processes, just spinning like crazy. I guess we do it again! I've got to learn how to copy the SSH stuff so that I don't have to keep manually deleting and adding keys all the time.
I waited it out and restarted it in safe mode. No difference. I'm initializing yet ANOTHER SD card and we'll see what happens now - and I'll just live without the preheat button - too bad - I like the preheat button....
Before I got a chance to try another fresh install, we had to leave for a few hours. When I got back, CPU usage was very low, the CPU temperature was low, the system was responsive, and the preheat button was present and working. I have absolutely no idea what happened that chewed up HOURS of CPU time, but for the moment, it seems to be working. Go figure.
I talked to foosel.
For some reason the gcode analysis blocks the webserver and that should definitely not happen. Normally the analysis runs in the background and stops when you start a print.
Since there were 220 gcodes queued up for analysis it took some time for the analyzer to finish the job.
The plugin itself is rather small and should be installed in less than a minute - in your case it was installed after 20 seconds -
and then the analysing block happened on the restart needed for activating the plugin.
foosel is investigating the issue.
I would suggest to not upload huge batches of gcodes for now - just one or a few at a time.
foosel identified the issue and a fix is already planned.
It will take a bit of time tho.
The current roadmap is releasing 1.10 within the next two weeks and then releasing a bugfix (which also fixes this issue along with other things) asap afterwards.
If you are interested in the status of the issue, or want more details, you can check the ticket on github
We could give you the fixed file now, but unless you're planning to upload another 200 gcodes at once, you should be fine for now
Ah. I wasn't really "uploading" 220 GCODE files. I was migrating them from my old instance to the new one. It seems I did invent a way to shoot myself in the foot. I couldn't create a backup because the old SD card wouldn't boot anymore. I just copied them from the "uploads" directory on the old SD card into the new system. That seems to have triggered the system into analyzing all of them again. So - what should I have done? Is the analysis stored someplace in a form that is stable across versions and could be migrated?
There is a 'metadata.json' file that is stored alongside the uploads, that holds the analysis data. I think, if you copied that across with the files OctoPrint would not try and re-analyse everything. I would make sure to do this while OctoPrint was not running, to avoid confusing it. In general, while OctoPrint is running it is not recommended to upload directly into the uploads folder as the files are not processed properly by the API and memory vs. disk contents can be different.
Ah hah. Now that I look for it... it's actually ".metadata.json" (leading dot) so a regular "ls" doesn't show it - which is probably why I didn't notice it before. This is VERY helpful - thank you!
OK, folks. I may need that file afterall. Or something. I just stopped and started octoprint (I freed up the resources to compile Marlin), and now it's doing the huge analysis again. Is this something I've preciptated by copying these files into the uploads directory, or is this an aspect of the bug? Note that I have not uploaded or copied any new files - these were all here when it was running last. So far, I've only reprinted prior jobs with this. systeminfo.zip (117.8 KB)
Yeah - there's something more amiss. I just updated to 1.10 - or I should say, I AM updating to 1.10 - and it's redoing all the gcode analysis again. Anyway - I see that I wasn't clear in my last post. When I said, "the file", it was probably interpretted as the .metadata.json file, but I meant the fixed code file you mentioned. So, yeah, I'm sitting here waiting for it to grind through all my gcode files again.... sure glad I got that fan for my RPi...
