"Upload" button no longer works, but gives no error message

Get Help
1

Hi everyone, I've just been running Octoprint for a day or two, and I'm having some noob issues. I'm running OctoPrint 1.3.11 on OctoPi 0.16.0 on a Raspberry Pi 3 B. My printer is a Prusa i3 MK2 with the latest available firmware.

Here's my problem: When I click the "Upload" button, I select my .gcode file, click OK, and then I see the little progress bar move from left to right while showing "Saving...". It makes it about halfway across the bar, and then it quickly retreats back to the left as though it's giving up. The whole progress bar cycle takes about a half-second, so I have to watch carefully to see it. There is no error message or other negative status displayed, it simply doesn't upload the selected file. I've gotten it to work before (see below), so I know what to expect, but it's not working any more.

I tried rebooting both Octopi and the printer, but neither made a difference. I was able to use the "Upload to SD" button, and that works fine, but it's known to be very slow, which is why I'm trying to upload directly to the printer memory. I also removed the SD card from the printer just to keep that from confusing anything, and that didn't help either.

I checked the log, and each time I attempt an upload, I see the following lines:

2019-07-07 21:33:44,040 - octoprint.filemanager.analysis - INFO - Starting analysis of local:Print_Test.gcode
2019-07-07 21:33:44,051 - octoprint.filemanager.analysis - INFO - Invoking analysis command: /home/pi/oprint/bin/python2 -m octoprint analysis gcode --speed-x=6000 --speed-y=6000 --max-t=10 --throttle=0.0 --throttle-lines=100 /home/pi/.octoprint/uploads/Print_Test.gcode
2019-07-07 21:33:58,346 - octoprint.filemanager.analysis - INFO - Analysis of entry local:Print_Test.gcode finished, needed 14.30s

There is one more line that's perhaps more interesting, but it doesn't appear for every attempt. Only sometimes (maybe associated with certain .gcode files):

2019-07-07 22:13:29,285 - backoff - INFO - Backing off capture_mjpeg(...) for 670.7s (URLError: <urlopen error [Errno 111] Connection refused>)

I also checked the Terminal tab, and nothing new appears there--only the following two lines that appear repeatedly while idle:

Send: M105
Recv: ok T:26.2 /0.0 B:25.5 /0.0 T0:26.2 /0.0 @:0 B@:0

I found another article or two about a similar problem, but they report seeing a "upload failed" message somewhere. I've never seen that, and I'm not even sure where it would appear. Perhaps I missed it?

Interestingly, the Raspberry Pi is connected to my network via Ethernet because when I first set it up with WiFi, it refused most web connections to its IP address. When I first got it running over WiFi, I was able to open the OctoPrint page in my browser (once), and in that instance, the Upload button worked at least a few times. When subsequent attempts failed to open OctoPrint on other devices (e.g., iPad, iPhone, other computers), I decided to un-configure WiFi on the Raspberry Pi and try Ethernet instead. Now, my browsers will all open the Octoprint page with no issues, but the Upload button no longer works.

Thanks in advance for any solutions or suggestions.

--Kris

2

First things first, try to reproduce this in Safe Mode.

3

Hi, thanks for the suggestion. I wasn't sure what Safe Mode was for, but I tried it, and got the same results--Upload still doesn't work. It appears that Safe Mode just disables plug-ins (maybe more?), but the only one I've installed is Octoprint Anywhere. Anyway, other ideas?

4

Correct, it disables third-party plugins. In many cases, if their code has JavaScript-related problems, it can truncate the collection of JavaScript at some point, preventing, say, the Upload button's functionality perhaps.

You might check to see if you have enough remaining space on your microSD card: df -h. But that's unlikely to be the cause.

You could try to upload a different file (a smaller one?)

You probably should check your power adapter to make sure that it is 5V @ 2.5A. I note that my own rig wants to indicate an undervoltage whenever I'm writing to the microSD card. It's possible that if the voltage is sufficiently low, it simply would fail at some point from a CRC panic. The /var/log/kern.log might confirm this or not.

5

Hi OutsourcedGuru,

Thanks again for the suggestions. Still no luck. My SD card is 32GB, and the only thing on it is the fresh installation of Octopi. I did not expand the file system using raspi-config because the setup page at octoprint.org said that wasn't necessary. I have tried uploading many different .gcode files, all fairly small, ranging from about 750k to about 3MB. None of them go. My power supply is the one recommended and sold by Adafruit.com, and it's 5.25v, 2400ma. That's slightly less than the 2.5A you recommended, but it's slightly higher voltage, which should be enough to compensate for any drop caused by writing to the SD card. Anyway, out of desperation, I figured I'd try a fresh burn of the Octopi image to a different SD card and run through the entire setup again. The only thing I did differently this time was to skip the WiFi setup and just use Ethernet right from the start (and I installed no plug-ins). I was so hopeful, but once I got my printer profile defined and Octoprint connected to the printer, I was still unable to upload. Is it possible I'm just missing something simple? Is there maybe a setting that I need to turn on in order to enable uploading a .gcode file? I'm a complete noob with respect to Octoprint, so maybe I'm just doing something wrong. I did not set up Cura because I'm perfectly happy with my slicer, and all I'm trying to upload is .gcode files (not .STL files). My next step is to find another Raspberry Pi in case there's something wrong with the one I'm using. Then maybe I'd try the setup one more time, but try WiFi again, since that worked for me the first time (aside from not being able to open more than one connection to the Octoprint server). Other than that, I'm stumped. At this point, this is just a fun puzzle that I'd like to solve, but it's not really in my way, since Octoprint is more of a curiosity than a necessity for me. Any other ideas? Thanks again for your attention on this--it's quite a puzzler.
--Kris

6

You'd have to tell us if you're seeing the undervoltage indicator in the OctoPrint web interface's status bar; this would indicate low voltage. You can probably trust your power adapter but you still don't know if the AC power outlet on the wall is providing 115VAC or something less (unlikely).

That was a good troubleshooting step to connect with Ethernet directly. You'd think that would rule out wifi-related problems.

You shouldn't need to do anything special in order to upload files via the File side panel widget.

I was going to suggest that possibly the .metadata file in the ~/.octoprint/uploads folder was corrupt somehow. But installing a new image and it still does that on the new rig makes me think not. As you can see from the log, when uploading a file this triggers the internal analysis to start. It will then update the .metadata file with this information and store it internally during your session. I see that it has two variables for the X/Y speed. Did you set the printer's default profile at least within OctoPrint even if you didn't setup anything for Cura?

7

Hooboy, I found the problem! I happened to sit down somewhere other than at my desk, and I figured I'd open the Octopi page on my iPhone. When I did, I saw three uploaded files in the Files panel--the same files that I'd been trying to upload from my desktop browser. So I headed back to my desk and tried uploading a fourth file from the browser. It seemed to fail, just like all the previous attempts, but on my iPhone, I saw the file appear! That led me to suspect a browser issue. The browser I've been using on my Mac is Safari, and it turns out it's been a Safari issue all along (even though Safari works just fine on the iPhone). More specifically, it looks like the upload was working all along, and the only problem was that Safari wasn't displaying any files in the Files panel. I switched to Chrome (which I was apparently using for the initial installation that worked properly), and it works just fine. So, the problem is definitely just a Safari issue on Mac (Mojave OS, latest updates). In case it's useful for debugging this, I opened the Developer panel (Console) in Safari and reloaded the Octoprint page, and I saw three log items that look like errors.

[Info] Did not bind view model – "UsageViewModel" – "to target" – "#wizard_plugin_tracking" – "since it does not exist" (packed_core.js, line 15928)
[Info] Did not bind view model – "SoftwareUpdateViewModel" – "to target" – "#softwareupdate_confirmation_dialog" – "since it does not exist" (packed_core.js, line 15928)
[Info] Did not bind view model – "SoftwareUpdateViewModel" – "to target" – "#wizard_plugin_softwareupdate" – "since it does not exist" (packed_core.js, line 15928)

So, I don't know if that's useful or not, but I plan to use Chrome for Octoprint from now on, and I'm considering this issue resolved. The only thing left to track down is my initial issue with the WiFi connections, so I'll go pound on that for a while, and I'll post a new issue if I still have trouble with that. Thank you so much for your help on this!

--Kris

3 Likes
8

Brilliant. And yes, those errors possibly are related to the problem. In theory, when the file has successfully uploaded something within the backend or frontend code needs to tell the Files side panel widget to update and it would do it, in theory, through the ViewModel.

It's useful if you were to create an Issue on the OctoPrint repository and make sure to fill in the form that's there for a bug, providing the information requested. Although it's a simple-enough work-around, it sounds like something is now different in Safari that should be looked into.

9

Just for the record, those log lines aren't errors (or out would say error in front instead of info ;)) but completely normal. It's simply an information that the listed view models weren't bound to the wizard, which makes sense if the wizard isn't active.

I agree on this sounding like a safari issue though, a full bug report would certainly be welcome.