Update 0.4.0 causes upload fails

[bmueller77]

Upload failed

(Translated) Could not upload the file. Please make sure, it is a readable valid file with one of the following extensions: .g, .gco, .gcode, .stl, .stl Internal Server Error

The server encountered an internal error and was unable to complete your request. Either the server is overloaded or there is an error in the application.

What did you already try to solve it? Tried other files, rebooted Pi, Reset Printer

Logs (octoprint.log, serial.log or output on terminal tab at a minimum, browser error console if UI issue ... no logs, no support!) 2020-01-08 10:21:18,916 - octoprint - ERROR - Exception on /api/files/local [POST] Traceback (most recent call last): File "/home/pi/oprint/local/lib/python2.7/site-packages/flask/app.py", line 1817, in wsgi_app response = self.full_dispatch_request() File "/home/pi/oprint/local/lib/python2.7/site-packages/flask/app.py", line 1477, in full_dispatch_request rv = self.handle_user_exception(e) File "/home/pi/oprint/local/lib/python2.7/site-packages/flask/app.py", line 1381, in handle_user_exception reraise(exc_type, exc_value, tb) File "/home/pi/oprint/local/lib/python2.7/site-packages/flask/app.py", line 1475, in full_dispatch_request rv = self.dispatch_request() File "/home/pi/oprint/local/lib/python2.7/site-packages/flask/app.py", line 1461, in dispatch_request return self.view_functionsrule.endpoint File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/server/util/flask.py", line 1276, in decorated_view return no_firstrun_access(flask_login.login_required(func))(*args, kwargs) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/server/util/flask.py", line 1295, in decorated_view return func(*args, *kwargs) File "/home/pi/oprint/local/lib/python2.7/site-packages/flask_login.py", line 758, in decorated_view return func(args, kwargs) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/server/api/files.py", line 361, in uploadGcodeFile display=canonFilename) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_PrintTimeGenius/init.py", line 546, in new_add_file return self._file_manager.original_add_file(destination, path, file_object, links, allow_overwrite, printer_profile, None, display) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/filemanager/init.py", line 493, in add_file path_in_storage = self._storage(destination).add_file(path, file_object, links=links, printer_profile=printer_profile, allow_overwrite=allow_overwrite, display=display) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/filemanager/storage.py", line 765, in add_file file_object.save(file_path) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/filemanager/util.py", line 92, in save shutil.copyfileobj(source, dest) File "/usr/lib/python2.7/shutil.py", line 63, in copyfileobj buf = fsrc.read(length) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint/filemanager/util.py", line 194, in read processed_line = self.process_line(line) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_cancelobject/init.py", line 37, in process_line line = self._matchComment(line) File "/home/pi/oprint/local/lib/python2.7/site-packages/octoprint_cancelobject/init.py", line 45, in _matchComment line = line.decode("utf-8", "strict") File "/home/pi/oprint/lib/python2.7/encodings/utf_8.py", line 16, in decode return codecs.utf_8_decode(input, errors, True) UnicodeEncodeError: 'ascii' codec can't encode character u'\xb0' in position 46: ordinal not in range(128)

Additional information about your setup (OctoPrint version, OctoPi version, printer, firmware, browser, operating system, ... as much data as possible) Octoprint: 1.3.12 Printer: Prusa i3 MK3s Printer Firmware: 3.8.1

See following entry: https://community.octoprint.org/t/solved-uploading-files-failed

[paukstelis]

Having non-ascii characters in your filename will cause problems with many printer firmwares. If you change the file name of your STL file and reslice it should upload correctly.

[DerBaM]

Confirm that since 0.4.0 upload not work. I‘ve tested it with a file/filename which worked bevor (exactly the same file). To deactivate this plugin let the upload work again.

By respect: to say that the user should change (till yet) working behavior instead to fix your failure is garbage.

[paukstelis]

Confirm that since 0.4.0 upload not work. I‘ve tested it with a file/filename which worked bevor (exactly the same file). To deactivate this plugin let the upload work again.

I did not say use the same file as before. I said to check if changing the STL filename (that has no special characters) allows it to upload. Marlin firmware will crash if it gets non-ascii characters so it is actually a good thing to avoid.

By respect: to say that the user should change (till yet) working behavior instead to fix your failure is garbage.

You are welcome for all the hard work I and others have put into this plugin. If you have a problem with the plugin you are welcome to fix it and submit a pull request for consideration. You can also simply not use it.

[DerBaM]

But to use the same file as bevor make sure that it doesn't depend on the file, right? And I can promise you, that neither my Marlin firmware nor my printer or OctoPi server is crashed till yet and why it should. Also, UTF and not ASCII is the standard since two or three days. And again: to be harsh and leaderish to your users aren't helpfull. If your nazish because my english isn't oxford-standard im not sure if this feel me sorry. To be clear: "by respect" means: I'm not ordering you/I'm not unthankfully/I'm not blame you/... . But your right I'm a little bit misunderstandable: "fix your failures" wasn't meant as order, sorry, it was meant as "if you do something wrong don't do as you're god and the universe must change its behavior".

To use version 0.3.3 works just fine so no need to not use your plugin. But of course this is the logical folowing if 0.3.3 stop working.

I will be thankfully if you fix your failure, but I'm sorry that I can't help you on further questions because I feel that I don't want to communicate further with you.

[paukstelis]

How does one fix a problem if they don't know the source of the problem? You and OP have said there is a problem but have not provided anything useful to fix it. I suggested a course of action, that if tested, would provide some clarity to the problem.

Also, because English is clearly not your first language I'm willing to let it slide, but I take strong offense to being referred to as "Nazish" and so would many others. Consider that in the future.

[PRGeno]

Paul, Please don't let one or two grossly inconsiderate people discourage you. There are many us out here who very much appreciate your selfless contribution to the OctoPrint community. Please keep up the outstanding work you've been doing in spite of those ungrateful few.

[gdombiak]

At work now so I quickly read this thread, when I create the PR that introduced Python 3 support I also discovered a problem in OctoPrint that still needs to be merged. Not sure if this is the same root cause but it has the same symptom which is "fail to upload file when using CancelObject plugin". The fix in OctoPrint is super small so maybe someone can confirm if this fixes this issue.

OctoPrint PR that is still in the queue: https://github.com/foosel/OctoPrint/pull/3393. You can see in the files tab what needs to be changed. Let me know if this fixed this issue.

Thanks, Gaston

[gdombiak]

I see that stack traces are different so chances are it won't work. Can someone post here the gcode file you are trying to upload? I can debug this later tonight

[paukstelis]

I confirmed that the problem is related to having unicode characters in the object name.

The quick work-around I found was to control error behavior to just eliminate the offending character(s) with: line = "{0} {1}\n".format(self._reptag, obj.encode('ascii','ignore')). See 0.4.1 branch. Eliminating might not be the best choice, perhaps just converting to string designation for these characters.

[gdombiak]

@paukstelis could you share an example of an object name with unicode characters? Not sure what you mean by that. Is it something like 'hello\U+00B9' ?

Thanks Gaston

[paukstelis]

Yes. I just added the offending character in the original stack trace: ; printing object 20°mm_cube.stl id:0 copy 0

[Sonsi79]

Same error here since update :-(

[Failed-Prints-Master]

Same error here. After updating just now to 0.4.0, I get the same error as above and can't upload .gcode files. If I disable the plugin, I can upload files just fine.

[gdombiak]

Reproduced locally and have a working fix. Will share with Paul. Thanks guys for the patience

[gdombiak]

Here is my PR for new 0.4.1 branch. Tested with Python 2 + OctoPrint 1.3.13 and Python 3 + OctoPrint 1.4.0rc3

[paukstelis]

Thank you @gdombiak. I have gone ahead and pushed these changes into the 0.4.0/master branch instead of having a new release. For those that are having upload issues, simply uninstall the plugin, restart octoprint when prompted, then install the plugin again.

[biniecki]

Having the same issue. I will try reinstalling the plugin. Would be nice if there was some sort of notice posted informing users of the known issue and how to correct it. If a new release would have prompted a notice and install

[gdombiak]

@biniecki The 0.4.0 release has been updated to include a fix to this problem. You will need to uninstall the plugin and install it again for this to take effect. Could you report back that it is fixed for you after doing this?

Thanks, Gaston

[biniecki]

@gdombiak Yes, uninstalling and reinstalling corrected my problem. I still think it would be nice to have some sort of notice or update pushed to users to make them aware. I spent a decent amount of time troubleshooting before i realized this plugin was causing my problem.

[paukstelis]

The only way to notify users is through an additional release. In this case, I didn't think that was warranted, but perhaps that would have been a better approach. My reasoning was that this was not likely to impact a large number of people since it will ONLY happen with unicode characters in your STL filenames. Further, I am planning on add the ability to post-process files after upload and the option to include the gcodes for firmware-based cancelling in Marlin (M486) in the processing options.

[bmueller77]

Uninstalling 0.4.0, rebooting the server and then installing 0.4.0 again worked for me. Thanks @paukstelis for the quick fix.