Remote Rendering Always Results in Error 500

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

Comments

  • 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.
  • 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.
  • 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.
  • 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

  • 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:

    p.p1 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px Menlo; color: #000000} p.p2 {margin: 0.0px 0.0px 0.0px 0.0px; font: 11.0px 'Source Code Pro'; color: #000000} span.s1 {font-variant-ligatures: no-common-ligatures} span.s2 {font: 11.0px 'Source Code Pro'; font-variant-ligatures: no-common-ligatures; color: #ba2da2} span.s3 {font: 11.0px 'Source Code Pro'; font-variant-ligatures: no-common-ligatures; color: #d12f1b} span.s4 {font: 11.0px 'Source Code Pro'; font-variant-ligatures: no-common-ligatures; color: #703daa} span.s5 {font: 11.0px 'Source Code Pro'; font-variant-ligatures: no-common-ligatures; color: #4f8187} span.s6 {font: 11.0px 'Source Code Pro'; font-variant-ligatures: no-common-ligatures; color: #31595d} span.s7 {font: 11.0px Menlo; font-variant-ligatures: no-common-ligatures} span.s8 {font-variant-ligatures: no-common-ligatures; color: #4f8187} span.s9 {font-variant-ligatures: no-common-ligatures; color: #31595d} span.s10 {font: 11.0px 'Source Code Pro'; font-variant-ligatures: no-common-ligatures; color: #3e1e81} span.s11 {font-variant-ligatures: no-common-ligatures; color: #d12f1b} span.s12 {font-variant-ligatures: no-common-ligatures; color: #703daa} span.s13 {font-variant-ligatures: no-common-ligatures; color: #3e1e81}

                } 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.
  • Looks like it's fixed in 0.80.4!  Can't wait for the full release of the new version!
  • 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.
  • I replied to your post on my wall with additional info.
  • Nope, no message on my wall, sorry.
  • 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.
Sign In or Register to comment.