Not displayed: 3D object and webcam.

[rogodra]

Hello, thanks for the plugin.

I have duplicate octoprint for two printers. Before the plugin worked for me, the 3D object was visible, the webcam was not visible.

Before I had printers with these names: octopi.local / octopi.local: 5001 /

Now: octopi.local / print1 / octopi.local / print2 /

They are not accessible for security from the ports. I think that from that change it is no longer possible to see the objects in 3D.

It would also be nice to be able to choose the webcam address. This would solve the problems of various webcams.

Thanks for this great plugin. A greeting.

[Kragrathea]

This plugin just shows the same web cam image as the regular OctoPrint tab does. Can you confirm that is working?

[rogodra]

Hello,

No camera comes out when I press the button. Cameras work on all plugins.

Then the 3D visualization is appreciated if you enter by octopi.local:80 or octopi.local:5001.

But the 3D is not displayed if you enter by octopi.local/print1/ or octopi.local/print2/.

Thank you!

[Kragrathea]

Ok, I think I understand now. Because you changed how the printers are addressed it broke something in PGCode (or Octoprint)? Probably around where it gets GCode file. I took a look at the code and there isn't anything obviously wrong. But that sort of change to the way the site is addressed might break more than a few things. Unfortunately I only have one printer so I can't really test that situation very easily.

[Pavulon87]

I have the same problem. Always changing few lines in prettygcode.js: gcodeProxy.loadGcode('/downloads/files/local/' + curJobName); to gcodeProxy.loadGcode('./downloads/files/local/' + curJobName);

[simon-hall]

Same issue here - when clicking the small webcam icon in bottom right of window, nothing appears to happen. No errors noticed in web browser console either (tried FF and Chrome)

[schumar]

Had the same issue, most likely caused by accessing OctoPrint through a reverse proxy (so the URL looks like https://my.web.server/octo/). Fix suggested by @Pavulon87 works for me (replace all 3 occurences of /downloads/files/local/ with ./downloads/files/local/) -- thanks @Pavulon87 !

[schumar]

p.s. fixed a similar issue (print head was not rendered) with the same approach, replacing /plugin/prettygcode/static/js/models/ExtruderNozzle.obj with ./plugin/prettygcode/static/js/models/ExtruderNozzle.obj and replacing /plugin/prettygcode/static/js/helvetiker_bold.typeface.json with ./plugin/prettygcode/static/js/helvetiker_bold.typeface.json

[Kragrathea]

I am not sure what exactly the bug is here anymore. At first I thought it had to do with multiple printers, But now it seems it may be a network pathing issue? Or maybe both?

[schumar]

Path issue; it's fixed by changing the path, and only appears when OctoPrint doesn't live in / (see initial report -- problem occurred when @rogodra moved to using /print1 and /print2 as root location)

[chemixt]

not sure if I have the same issue, but this worked great when first installed. Somewhere between then and now it stopped working. attached is an image of my screen. I do not have a camera icon on the screen and the layer count progress bar on the right is just solid Green line with 1 at the top and 0 at the bottom. The image of the print nozzle seems to be moving exactly to match my printer, but it looks like the filament is invisible. The attache image was at about 80% of a 1 1/2 hour print.

[Kragrathea]

I changed how the camera works in next version. If you are still having problems open a new issue.

[gdachs]

Had the same issue, most likely caused by accessing OctoPrint through a reverse proxy (so the URL looks like https://my.web.server/octo/). Fix suggested by @Pavulon87 works for me (replace all 3 occurences of /downloads/files/local/ with ./downloads/files/local/) -- thanks @Pavulon87 !

Too sad that this changes didn't make it into the latest release, have to edit the files again.

[Kragrathea]

Fix suggested by @Pavulon87 breaks the default case. Unless someone who has this setup and the default can suggest something I have no way of fixing this without setting another octoprint behind a proxy.

[Kragrathea]

Hey @foosel, Do you have any idea what I am doing wrong here? I suspect I am not setting up the path correctly when I try to download the GCode.

[lightmaster]

Looks like my issue (Issue #98) is the same as this one, inability to access PrettyGCode over a Reverse Proxy. Fix for me was to prefix the 4 /downloads/ and and 2 /plugin/ with a . as mentioned above. Seems this fixes it for proxies, but breaks it for the original URL/IP. So what about setting up a check to find the base URL, and then using what scheme or the other based on which URL you are accessing PrettyGCode from?

I don't know much about Javascript, but a quick Google search returned this: https://stackoverflow.com/questions/25203124/how-to-get-base-url-with-jquery-or-javascript

[foosel]

Sorry, I totally missed that notification @Kragrathea

If reverse proxies are the issue here, I suspect you are constructing the URLs in question manually, which is a bad idea as shown. The correct way is to either use the URL provided as part of the file metadata, or to at least take the global BASEURL constant into account which should always reflect the root URL over which OctoPrint was accessed.

[Kragrathea]

Thanks @foosel! Now I have some idea what the fix is I'll try to do it this weekend.

[kylix-rd]

Looks like my issue (Issue #98) is the same as this one, inability to access PrettyGCode over a Reverse Proxy. Fix for me was to prefix the 4 /downloads/ and and 2 /plugin/ with a . as mentioned above. Seems this fixes it for proxies, but breaks it for the original URL/IP.

FWIW, I merely removed the leading '/' and it "seems" to work on both my reverse-proxy system and a simple single instance system. ¯_(ツ)_/¯

Nevertheless, the correct fix is to properly assemble the URL from the metadata or the BASEURL..

YMMV, I may have gotten lucky, yada yada.

[AlvaroBrey]

As @kylix-rd said, just making the path non-absolute (by removing the leading slash) is enough to fix this in reverse proxies (including the homeassistant octoprint addon), and should work in normal access as well. Here are the changes if someone wants to replicate them: https://github.com/alvarobrey/OctoPrint-PrettyGCode/commit/c6d7cd0f456f034be7ed4c30e5f709d1c68a5624