Does not load image

When I run openframe, it does not get past this point:

pi@raspberrypi:~ $ openframe

Loading /tmp/56e0c15e17bbab454407c2b7autumnleaves.jpg as the following uniform:
uniform sampler2D u_tex0; // loaded
uniform vec2 u_tex0Resolution;


I am using a RPi 2 Model B, with Raspbian 8 / Jessie, and
Linux raspberrypi 4.1.19-v7+ #858 SMP Tue Mar 15 15:56:00 GMT 2016 armv7l GNU/Linux


Any ideas?


Hmm, haven’t seen this one before — it does look like it’s trying to display the image with glslViewer, which is correct for the latest version of the image extension.

Did you have openframe installed and working previously and this occurred after the latest update? Or is this a fresh install?

I installed it, never got it to run, then upgraded it. From the directories in ~/.npm/openframe, it looks like I have initially installed version 0.1.30 and then upgraded to 0.3.1.


Ok, it might be because you went directly form 0.1.x to 0.3.x, skipping 0.2… try manually installing the latest versions of the format extensions:

$ npm install -g openframe-image@latest openframe-video@latest openframe-glslviewer@latest openframe-website@latest

No joy. I ran your command, rebooted and got the same result.

Should I just delete it all and install from scratch? If so, what is the best way to delete the current installation?


Shucks, sorry.

If you want to try one last thing, you could try re-installing glslViewer — it seems it’s something to do with that, since you’re getting some output from there.

Otherwise, the most surefire way would be to do a full reboot, starting by flashing the SD card with NOOBs, then running the openframe install script: bash -c “$(curl”.

Update on this — I’ve seen this error now too! I think it has to do with the size of the image. The image extension uses glslViewer to display the image as a texture, and for some reason the one image isn’t working, and it’s the image that is significantly bigger than the rest. Might be a memory issue, or a limitation of openGL ES. I will look into it further.

Reinstalling glslViewer did not help.
So I did the full reboot. Using NOOBS instead of Raspbian costs over 1GB of SD card space, so I loaded Raspbian directly onto the SD card.
Why do you use the bash command for the install script, and not just "curl" by itself**?**
After going through the full reboot, it is mostly working. If I load an image from my Collections that is bigger than my monitor, it does not display. I resized it to exactly the monitor’s resolution and it worked.

I get the following error when I try to display the YesPls shader from your Stream page. Other shaders work. I haven’t tried them all yet.


pi@raspberrypi:~ $ openframe
? Enter a name for this Frame: johnsframe

[o] Connected! You can now push artwork to this frame.

This frame should now appear as johnsframe when you log in to Openframe at http//

Usage: glslViewer shader.frag [shader.vert] [mesh.(obj/.ply)] [texture.(png/jpg)] [-textureNameA texture.(png/jpg)] [-u] [-x x] [-y y] [-w width] [-h height] [-l/–livecoding] [–square] [-s seconds] [-o screenshot.png]
[Function: _replaceTokens] ‘/home/pi/.nvm/versions/node/v4.3.2/lib/node_modules/openframe-website/scripts/.xinitrc’ { ‘$url’: ‘’ }

Fatal server error:
(EE) Server is already active for display 0
If this server is no longer running, remove /tmp/.X0-lock
and start again.
Please consult the The X.Org Foundation support
for help.
XIO: fatal IO error 11 (Resource temporarily unavailable) on X server “:0”
after 7 requests (7 known processed) with 0 events remaining.

Raspbian is fine, no need to use NOOBS if you’re comfortable flashing the SD card.

That script needs to get executed on the pi, hence the use of bash. We download the file with curl, then run it with bash.

Thanks to our shader guru Patricio, we realized that for some larger images and shaders to display you may need to increase the memory allocation to the GPU. Easiest way is through raspi-config -> advanced -> memory split, then set the value you want. Maybe 256 or 512? This should take care of some of these issues, but images that are super big might still cause problems.

The broken shader you mentioned was added by a user — it’s not formatted in a way that can be run by our shader extension, which uses glslViewer.