Octoprint: [bug] Octoprint stuck on 'saving' when uploading a file to print.

[Tob3ster97]

What were you doing?

Uploading file to OctoPrint.

What did you expect to happen?

File to be uploaded for printing.

What happened instead?

'Saving' stuck. Stays at Saving forever.

Did the same happen when running OctoPrint in safe mode?

Yes.

Version of OctoPrint

OctoPrint 1.3.12

Operating System running OctoPrint

OctoPi (0.17.0)

Printer model & used firmware incl. version

CR10s Pro. Stock Firmware

Browser and version of browser, operating system running browser

Chrome (Version 79.0.3945.130 (Official Build) (64-bit))

Link to octoprint.log

https://gist.github.com/Tob3ster97/9fc597102674e182477a956915367449

Link to contents of terminal tab or serial.log

n/a serial logging not enabled.

Link to contents of Javascript console in the browser

https://gist.github.com/Tob3ster97/9fc597102674e182477a956915367449

Screenshot(s)/video(s) showing the problem:

attached as comment

I have read the FAQ.

[Tob3ster97]

[Steeven9]

Same problem here. The file will eventually be uploaded but after ~5 minutes stuck on Saving...
OctoPrint 1.4.0rc4 on win7 32bit, Ender 3 with Marlin 2.0.1

[foosel]

Can both of you please share a file with which you can reproduce the behaviour?

And can you @Steeven9 also share octoprint.log and the contents of your browser's error console as well as a screenshot of the network tab focused on the upload request?

[Tob3ster97]

Mini_caballete_easel_no_support.zip

[Tob3ster97]

The attached file isnt the original one, howevever the same issue is seen. Stuck on saving and sometimes with eventually upload after 5+ minutes. Some files can take over 30 minutes when i leave it on. And i do have fast internet so i assume this isnt the issue.

[Steeven9]

As for the file causing the issue, I tried with 10 different models and it happened with all of them, here's one: Phone_Stand03.txt (converted to txt since GitHub doesn't accept .gcode)

octoprint.log (canceled out IP addresses)

Browser console tab (Chrome Version 79.0.3945.130 (Official Build) (64-bit)):

Network tab while waiting:

Network tab when done:

[Tob3ster97]

Also OctoPrint as a whole is extemely slow. can take 5-30 minutes to load the web interface and the same again to login.

[Steeven9]

Also OctoPrint as a whole is extemely slow. can take 5-30 minutes to load the web interface and the same again to login.

Maybe it helps, maybe it doesn't, but since I updated to rc3 (and then rc4), the OctoPrint webpage on load shows "Loading OctoPrint's UI, please wait...", while it never did before on stable versions.
Could it be somehow realted to this?

Also perhaps it's worth noting that I had no issues whatsoever with Python 2.7 and the latest stable version. Then I updated to Python 3 and rc3 and this popped up

[xthedakmanx]

+1 having same issue still. Happens for larger files. Uploading directly through FTP and refreshing octoprint does not cause it to lock up.

File example: https://www.dropbox.com/s/zfu1pptbewbea6z/Einsy-doors_0.2mm_PC_MK3S_1d4h21m.zip?dl=0

[StevoP80]

+1 I have the same issue. Seems to happen randomly. I run multiple instances of octoprint on a single raspberry pi, and can upload the same file to multiple instances and it may hang on one instance but work on another. Does not seem to be file dependent.

[fieldOfView]

To everybody who has "the same issue", we need logs or we can not see what happened.

[fieldOfView]

As requested by @foosel above:

octoprint.log and the contents of your browser's error console as well as a screenshot of the network tab focused on the upload request

See this FAQ entry about where to find the logs:
https://community.octoprint.org/t/where-can-i-find-octoprints-and-octopis-log-files/299

[foosel]

The only thing I've been able to reproduce so far that looked familiar turned out to be caused by a test plugin I had written for something else. So... cannot reproduce, need more logs and test samples.

[EddieGreen]

I've experienced the same issue for a long time.

The cause for this on my install was the plugin DisplayLayerProgress.

This plugin seems to take quite a long time to process anything but the smallest file. Until it has finished, upload progress will remain 'saving...'

Can anyone else confirm that they have this plugin installed and, by disabling it, speed of upload is restored to normal?

[foosel]

I recently pushed a performance fix for the wrapper that plugins like that one need to use for processing files on upload, so maybe that issue is now actually fixed as far as possible.

[EddieGreen]

Do you think that this adresses my concerns and potential fixes suggested over at DisplayLayerProgress?

[foosel]

It adds an optimization, however it still doesn't solve really bloody expensive processing inside a third party plugin, it can only optimize the stuff around that. DLP still probably should have that investigated.

I found that by switching one of my own plugins wrapping the file uploads from using regex matching to substring search and modifying the logic slightly I could significantly improve on performance.

[EddieGreen]

Thanks for this explanation.

For this and another issue - stalling prints during upload - it looks like OctoPrint gets the blame for processor intensive tasks within plugins and, like me, folks run around looking for bugs and fixes to OctoPrint.

Does OctoPrint's plugin interface require developers to allow its current tasks to complete and report before they take over? Or to require them to report the plugin's status such as starting, processing, and completion?

I don't see a status bar in the main interface but it could be implemented and made a requirement. Sure would reduce all the head-scratching in such cases as this.

[foosel]

Does OctoPrint's plugin interface require developers to allow its current tasks to complete and report before they take over? Or to require them to report the plugin's status such as starting, processing, and completion?

This interface doesn't. And adding that would also be non trivial.

In general, OctoPrint does have a safe mode precisely so that users can disable all third party plugins with one central switch and check if a problem persists in that mode. If it doesn't -> third party plugin issue, not core OctoPrint.

Sadly way too many people ignore this request in the bug template and also the debugging steps outlined on the forum.

[EddieGreen]

OctoPrint does have a safe mode...

Good point.

[iplayfast]

I recently had the same problem. Which happened after completing a print and starting the next.
I noticed that swap was being used so turned that off. (sudo swapoff -a)
That made little difference. The big problem seemed to be wifi connection. Pinging back to my computer (I was connected through ssh) took 450ms.
Giving up, I decide to reboot. (sudo shutdown -r now)
Which seemed to clear whatever error there was.
Back to normal now.

[foosel]

Still unreproduced on my end, however, as mentioned 1.4.1 contains improvements in the upload pipeline that might solve this. Please test against the 1.4.1 RCs that are out already, if I don't hear anything about this still being an issue against the RCs I'll close this on release of 1.4.1.

[foosel]

1.4.1 has just been released