Remote Rendering Always Results in Error 500

james0x2a

I am running Repetier-Server 0.80.3 (Pro trial period) on several devices, with the printer connected to a Raspberry Pi Zero W. Everything is working fine on the RPi so far, although rendering and timelapse are extremely slow due to the limitations of the processor. To try to pick up the slack, I've tried installing Repetier-Server on other, more powerful machines. So far, I have tried on my AMD64 Gentoo server (manually unpacking the .deb file, seems to work fine), Windows 10 x64, and Windows Subsystem for Linux, effectively running Ubuntu Xenial. All report able to remote render, and they all will take the job and run it successfully. However, when the RPi fetches the job results, getting the .png file results in an HTTP error 500. All logs on rendering servers look entirely successful, and I can't find any error messages that indicate the source of the 500 error.

From the RPi:

2017-04-30 14:39:07: Job created: /var/lib/Repetier-Server/printer/Anet_A2_Plus/models/00000029_3DBenchy.u

2017-04-30 14:39:07: finish job /var/lib/Repetier-Server/printer/Anet_A2_Plus/models/00000029_3DBenchy.u

2017-04-30 14:39:07: Updating info for /var/lib/Repetier-Server/printer/Anet_A2_Plus/models/00000029_3DBenchy.g printer Anet_A2_Plus

2017-04-30 14:39:07: Uploaded size:8344157

2017-04-30 14:39:24: LUA job rendering.render#{"id":29,"image":"/var/lib/Repetier-Server/printer/Anet_A2_Plus/models/00000029_3DBenchy_l.png","layer":"/var/lib/Repetier-Server/printer/Anet_A2_Plus/models/00000029_3DBenchy.layer","list":"models","slug":"Anet_A2_Plus"}

2017-04-30 14:39:24: cloudinitalize:application/json

2017-04-30 14:39:38: get 00000029_3DBenchy_l.png status 500

2017-04-30 14:39:38: contenttype:

2017-04-30 14:39:38: error rendering over cloud

2017-04-30 14:39:38: cloudinitalize:application/json

2017-04-30 14:39:51: get 00000029_3DBenchy_l.png status 500

2017-04-30 14:39:51: contenttype:

2017-04-30 14:39:51: error rendering over cloud

2017-04-30 14:43:23: Reading configuration file ...

Build 2

Input file: /var/lib/Repetier-Server/printer/Anet_A2_Plus/models/00000029_3DBenchy.layer

Rendering shadows ...15.667 seconds.

Rendering gcode ...153.232 seconds.

Number of end triangles: 272748

Number of normal triangles: 4090108

Rendering background ...

Time for raytracing: 36.7885 seconds.

Computation time: 211.405 seconds

From the Windows log (representative of all render hosts logs):

2017-04-30 14:46:30: localCloudDispatcher job

2017-04-30 14:46:30: renderCloudRemote called

2017-04-30 14:46:30: base = 00000030_3DBenchy

2017-04-30 14:46:46: Reading configuration file ...

Build 2

Input file: C:\ProgramData\Repetier-Server\tmp\5b9cc383-3ed0-486c-aa79-048a9e6e2f8e\00000030_3DBenchy.layer

Rendering shadows ...1.88879 seconds.

Rendering gcode ...10.0097 seconds.

Number of end triangles: 272748

Number of normal triangles: 4090108

Rendering background ...

Time for raytracing: 2.45931 seconds.

Computation time: 14.8804 seconds

james0x2a

Follow-up: to eliminate variables, I have also tried uploading GCode to other Repetier-Server instances to farm out, and they also fail in exactly the same way, including when the RPi is asked to render the image.

Repetier

OK, I tried it and it worked on first instance, so it seems to be no general problem. But since you have tested several combinations I wonder what could get wrong and analysed the sources. I have found the source fetching your files and they receive a 500 error code, so that they stop and then render themself is ok and expected.

The question is what on the remote server goes wrong. All planned paths return a content type so a good try would look like this:

2017-05-01 09:32:51: Job created: /var/lib/Repetier-Server/printer/Delta_Tower/models/00000007_BagClip_85 PET.u

2017-05-01 09:32:51: finish job /var/lib/Repetier-Server/printer/Delta_Tower/models/00000007_BagClip_85 PET.u

2017-05-01 09:32:51: Uploaded size:998967

2017-05-01 09:32:51: Updating info for /var/lib/Repetier-Server/printer/Delta_Tower/models/00000007_BagClip_85 PET.g printer Delta_Tower

2017-05-01 09:32:52: LUA job rendering.render#{"id":7,"image":"/var/lib/Repetier-Server/printer/Delta_Tower/models/00000007_BagClip_85 PET_l.png","layer":"/var/lib/Repetier-Server/printer/Delta_Tower/models/00000007_BagClip_85 PET.layer","list":"models","slug":"Delta_Tower"}

2017-05-01 09:32:52: cloudinitalize:application/json

2017-05-01 09:32:58: get 00000007_BagClip_85 PET_l.png status 200

2017-05-01 09:32:58: contenttype:application/octet-stream

2017-05-01 09:32:58: get 00000007_BagClip_85 PET_m.png status 200

2017-05-01 09:32:58: contenttype:application/octet-stream

2017-05-01 09:32:58: get 00000007_BagClip_85 PET_s.png status 200

2017-05-01 09:32:58: contenttype:application/octet-stream

2017-05-01 09:32:58: Images rendered over cloud

but your content type was empty so my guess is that a uncaught error happens when you try to fetch the result and receiver sets the 500 error code instead since it did not get anything but a broken connection. For the future releases I have added some more error testing and messages to locate the problem better.

For now have you also tried the other way around? Meaning from big pc to pi for rendering? Since we already know pi can render successfully including file storage. I'm currently working on wifi handling but when that is finished I could give you a new pi version with the improved error handling that might give a clue why this happens to you.

james0x2a

I also get the error when the Pi is tasked with the rendering from another server. I have manually reconstructed the sequence of HTTP POSTs to invoke a rendering job, and I sent this sequence by hand to both a Linux x64 server and to the Pi server. The uploading of the files is successful, and the rendering is successful. Before sending the fetchFile request, I can see the 3 output png files in the tmp directory (JOBID/JOBNAME_[sml].png). The png files are all mode 666 (which is probably a bug), and owned by the repetierserver user. Sending a fetchFile request for any of the png files results in a 500 error. Sending the fetchFinished request successfully removes all files in the tmp/JOBID directory.

james0x2a

Here's an example fetchFile request that is being generated:

POST /cloud/fetchFile HTTP/1.1

Content-Type: application/x-www-form-urlencoded

Content-Length: 172

Connection: Close

Host: repetier.internal.domain.com:3344

apikey=4b27abe0-3abe-4b92-acb4-e2b152111c8b&id=a436cecb-2198-4d70-8fba-e92e27f4f702&secret=cf673c4c-907d-483e-ab82-05798fdeb664&file=00000025_spinner-cap-with-chamfer_s.png

Repetier

Yes, this states what I think. It crashes somehow in fetchFile. Since you also checked existence of images we can exclude this as well. Since you seem to have some programming knowledge here the fetch part:

} else if(a == "fetchFile") { std::string id = ctx.form.get("id",""); std::string secret = ctx.form.get("secret",""); RemoteCloudJobPtr job = findRemoteJobFinished(id); if(job == nullptr) { obj["error"] = "Unkown job id"; responseCode = Poco::Net::HTTPResponse::HTTP_NOT_FOUND; } else if(secret != job->secret) { obj["error"] = "Wrong secret"; responseCode = Poco::Net::HTTPResponse::HTTP_FORBIDDEN; } else { std::string filename = fileSecureName(ctx.form.get("file","")); boost::filesystem::path file(job->folder / filename); if(boost::filesystem::exists(file)) { ctx.resp.setContentType("application/octet-stream"); ctx.addContentDisposition(filename); ctx.resp.setContentLength(boost::filesystem::file_size(file)); ctx.resp.setStatus(Poco::Net::HTTPResponse::HTTP_OK); ctx.resp.sendFile(file.string(), "application/octet-stream"); return; } obj["error"] = "File does not exist"; }

As you can see job is known or you get special error message. Secret and file existence also trigger an error and your return is a repetition of the post data. That sounds like no answer got formulated and poco send this as last solution.

I'm currently compiling a new version and send you a PM with it for the pi. Should be finished in 15 minutes. It should log the exception that causes all the stuff to get skipped. Maybe we then get an idea what is wrong here.

james0x2a

Looks like it's fixed in 0.80.4! Can't wait for the full release of the new version!

Repetier

Mhh. I did not add anything to fix the problem. I just added some more error logging to find the source. Stange, but happy it works. Does it now also work in the other direction with pc as cloud server? I mean that was not updated.

james0x2a

I replied to your post on my wall with additional info.

Repetier

Nope, no message on my wall, sorry.

james0x2a

As we discussed, this was traced to an issue with the User-Agent string being set. To compensate for this while we wait for 0.80.4, I have created a little proxy in Python that does just enough to get a UA header added to make this functionality work with 0.80.3.

https://pastebin.com/07U6c2kz </div></div>