Sorry, it was not my intension to step on someone's toes. My apologies for this.
What I tried to express, that it is possible to have smooth running OctoPrint.
For myself, I'm struggling to get my MMU2 to work properly.
I could say, I leave it and use only the MK2.5, but I want to have it run.
Seeking the forums for valuable hints, but I don't give up.
So my questions to @DivideByZero to find out what makes his system in stable.
Thanks dude, it certainly does seem to be the way to go... which is a shame but there you go.
At least this has actually led to me getting my platform slightly more stable now.
And you are right in what you say, just because the majority of people don't have issues doesn't mean something is perfect and after all, I am posting here in the get help section. "Well it works for me" is not really any use to someone needing help as it is obviously not working for them.
Thanks, I know it's possible to run smooth as many 3D print people use this and sing its praises.
It's very frustrating when you want to be getting on printing however and a system that should be quick and simple to setup actually introduces a lot of new issues instead of making things easier.
Anyhoo. It seems SD upload is hella slow and so I can sack that off as a bad idea. Shame, but whatever, we move on.
On the plus side, looking in to this might have actually found and fixed my stability issues which seem to be files on the SD card in the printer that it did not like... so maybe I will now be able to enjoy some OctoPrint goodness.
Thanks all - will post back in a few days or so to confirm my findings.
Yes, some SD cards can be faulty. Even the good ones.
I'm happy with you that you made some progress.
I would bet that it was actually files on the card rather than the card itself.
I expect that Octoprint was doing some kind of operation with all the files on the SD card and causing the issue.
When you use the printer interface, it probably doesn't even scan though the folders unless you manually open that folder and it wont inspect a file unless you tell it to print that.
That's my guess.
Octoprint can't even interact with the files on your printer's SD card, at least not in the way I'm guessing you think it does.
Your printer doesn't act like a card reader, octoprint asks your printer for a list of what's on the sd card, which it then reports back. When transferring files, octoprint asks your printer to please start saving this stream of bits to a file on the sd card. It's then up to your printer's firmware to read those bits over the serial connection, and then your printer's firmware saves them to its internal sd card.
Octoprint is only responsible for files you save onto the sd card of the raspberry pi it's running on (or otherwise the storage medium of the server since that might be a spinning hard drive or ssd or anything).
You are expecting that there's no overhead at all involved here for actually getting the data to the printer, which it is however. The only way to get data on the SD is via the same kinda protocol that's used to print on your printer. So line numbering every single line, checksumming it, sending it over, waiting for the firmware to parse that line, check line number and checksum, stripping that, writing it to the SD, acknowleding this via ok, then sending the next line, ...
See also the FAQ on this:
Yeah, it works how I thought it did thanks. Sure, not before using Octoprint, but pretty soon after.
Definitely what was happening was Octoprint was doing something, maybe as simple as asking for a list of every file on the printer which the printer was having issues with. Without Octoprint attached, no issue, so regardless of where the problem actually was, it was only coming to life with Octoprint attached.
There's a difference between and overhead and "it'd be quicker to write the gcode by hand".
I was expecting maybe half the transfer speed, not less than 1/8th.
But there you go, that's what it is and how it works.
As I said though, this did lead me to find my stability issue so I am thankful for all the replies.
As I need to mark something the answer...
Summary of my issue: Transfer of files to SD card was hanging, crashing, killing the printer / Octoprint. Files on SD card not showing in the list of files.
Resolution: Cleared all files off the SD card, aside from a few known good .gcode files.
I am fairly certain there was a file on the SD card that was causing issues when Octoprint requested a list of files on the SD and killing the printer. Looking in the file list on boot, it was not showing anything on the SD. Once I cleared most of the files, it started working OK and would list the files on boot and I could transfer files to the SD.
Note: Transfer of files to the SD card is extreemely slow via Octoprint, a roughly 13MB file would take about 3 hours. This is expected. As long as you can see the file transfering and list of files stored on your SD card, then the transfer and connection to the printer is still working.
Thanks everyone for the help, info and suggestions. Much appreciated.
Me too. Feel free to tag me in a thread about that 
DBZ, is your 'pi overclocked?
Nah, stock clocks. Pretty sure the HW is fine too, as I stuck RetroPie on a spare SD card and that runs like a champ.
It's just a file (or files) on the SD card in the printer that was causing it.
When I start Octoprint now, I see a list of files on the Pi and on the printer's SD. Before, I was only seeing files on the Pi... nothing from the printer. This would have been trying to get the file info on boot and had already started what would go on to kill my printer and crash OctoPrint shortly thereafter.
(Boot up, Get a list of files on printers SD... invalid character / contents or something... , maybe the printer or maybe OctoPrint could not interpret something to do with that file, tried and tried and some bug caused a crash / hang / kill after a few minutes of trying). Something like that.
The fact that I was trying to copy files to the SD card was largely irrelevant, but did actually accellerate that issue... though it would crash anyway after a mere couple of minutes.
Anyway, the copy to SD is now working successfully and I have stability (which is ultimately what I was looking for), though now I can see just how slow that copy is - I sadly won't be using it.
Cheers
It certainly wouldn't be the first printer we've seen freaking out due to some sort of corruption on its own SD, there are a couple of topics around these forums of printers starting to beep, reboot or do god knows what on file list.
If it's not a rare occurence, it might be worth putting a one liner on the " Setting up OctoPi" page, because the issue is not obvious (it doesn't tell you straight out that the printer is being killed because it failed to read a file etc.).
A simple one liner of "We reccomend clearing all files from your printers SD card before first use" would do it.
Just a thought.
Thanks.
It's rare. It's just not "I've never heard about this before". And it seems to be somewhat printer dependent, all printers this has happened with so far that I'm aware of are Creality ones.
That'll teach me to buy a cheap printer
Might well be because the Creality comes with a bunch of files on the SD card when you get it. It's not an issue if you are using the SD card in the printer as it seems to only look at files when you tell them to open and can browse / list everything OK.
I'm considering going back to octoprint again, I did not install it on my new prusa mk3 yet.
I have a FlashAir card in it so it's not a problem to send files to the printer SD card.
I wonder that when the pi hangs, will the print continue if using the SD card?
I want octoprint for the time-lapse on layer change and monitor the progress.
Hi,
I have personally given up with using the SD card and just let OctoPrint do the whole job.
Apparently, if you initiate the SD print from Octo it will keep going even if Octoprint reboots etc. However, I found that working with the file on the SD card was just as slow as copying and so basically unusable. I might have been doing it wrong (by hitting load before printing it) but anyway, I didn't use that method.
You wont be able to use the layer change timelapse on the SD however, that only works when it is on Octoprint I believe (certainly what the warnings say).
Slightly correct, but horribly misleading with conditions.
If you start a print on the SD card, yes you can turn off your octoprint machine and the printer will continue printing (maybe).
If you reboot your octoprint machine, any attempt to reconnect to the printer can reset your printer, this is due to how many printer controller boards are made, based on arduino technology.
If you plan to turn off your octoprint machine, I would highly suggest unplugging the usb cable, then start the sd print from the printer's own control interface.
Conditions and restrictions apply, and there are always exceptions to the rule. Some boards have a jumper that disables reset on serial activity, some boards have it permanently disabled (these boards may also be the same boards that require external hardware to update the firmware).