OpenFrame ISO pre created SD image

[adria...@gmail.com]

Is there a working SD image with openframe preinstalled?

I believe that would end a lot of issues people are having getting started. 

I recently embarked on building a few photo frames with raspberry pis when ran into openframe. 

The project looks great and seems to do everything I wanted and more. 

The only problem is getting a frame started is becoming a pain. 

First I ran into an error "terminal xterm-256color does not support --blank" I have fixed that by running with noobs and not raspian. 

Now I am reaching an error with glsviewer "glslviewer error while loading shared libraries libglesv2.so".

I am sure after a few more attempts, I will probably get it to work. 

However, it seems a lot of these noob problems could be resolved by releasing packaged iso. 

The image would be burned to the sd card using something like BalenaEtcher. 

[Jonathan Wohl]

Good question! And yes, I agree this would be a good thing to provide. We haven't had a chance to update the install script(s) in quite a while, so not surprising that things don't work perfectly anymore with raspian updates, etc. 

If you do get it working, would you mind replying in this thread with the additional steps you needed to take in order to get it running? It might be helpful for others...

And even better, when you get it set up, feel free to share a link to the SD image!!

[Adrian Goris]

I will do when I get it working. 

I am currently compiling bin/glslViewer from source. lol 

I will share if I get it working but it might take a weekend hacckathon for me. 

Once we have an image perhaps we can move the configurations to config.txt 

[luk...@gmail.com]

Ohh, would be awesome if you did this. I had an openframe instance running, but it somehow stopped working once I updated the RaspberryPi. Would love to have someone who knows this stuff better than me prepare an SD image. Good luck with the hack-a-thon!

Thanks!

[Adrian Goris]

I continue to have issues with glsViewer. I am running Raspbian Buster Lite 2019-07-10 . 

To test things out I installed Chromium and have it working in kiosk mode using openbox.  

I am not sure why Chromium is working but openframe fails, as they both depend on libGLESv2.so. 

Is there a big difference in performance when running glsViewer vs running the full chromium instance for openframe?

It could be easier to maintain and develop openframe by loading a full chromium instance.

I will continue messing with the current development but just something to consider. 

[Jonathan Wohl]

A few things to note:

- glslViewer is a separate application that Openframe's 'shader' and 'image' extensions currently use to display artwork, it's not built or maintained by Openframe. If I remember correctly, there was some issue with the latest version(s) of Raspbian and its compatibility with glslViewer, and users had to build it from source rather than depending on the package from the Raspbian repo.

- I'm not sure what you mean about Chromium. Openframe itself doesn't run in a browser, though the 'website' extension (which always had the most problems) did use Chromium. It might be that Chromium could be used as a replacement for glslViewer in the shader and image plugins, if glsl support is good in Chromium (it wasn't when Openframe was first being developed).

- Ideally we wouldn't load Chromium unless we needed to, since it's slow and bulky compared to other light-weight processes that can be used to display artwork

Sorry I don't have more time to debug at the moment...

[Adrian Goris]

Yes I have glslViewer running on my Mac and ubuntu installs.

There was a bug when using the Debian maintained package glslViewer but I was able to resolve that by compiling from the latest source. 

The new bug is with GLFW and X11. 

GLFW error 0x10008: X11: Failed to open display :0

I believe it's related to xauth magic cookie. 

Which is probably also related to this:

https://github.com/patriciogonzalezvivo/glslViewer/issues/58

So I compiled GLFW from source and still the same problem. 

I am digging through the issues on the GLFW GitHub. Which currently has 270 open issues. 

https://github.com/glfw/glfw/issues

I agree with you. Ideally we wouldn't load chromium but offloading supporting these packaged might be worth the performance hit. 

P.S.

I tracked down the loader to this python script which executes a system command for GLSL. Is this correct?

~/.nvm/versions/node/v12.8.1/bin/glslLoader

[Jeremias Volker]

I would love to see this. 👍

I'm facing similar issues trying to run openframe at the moment: https://github.com/OpenframeProject/Openframe/issues/40

[Jeremias Volker]

Seems like the major issues of the extensions are solved now. Good time to create a working ISO?

[Jeremias Volker]

Seems like the major issues of the extensions are solved now. Good time to create a working ISO?

Well, not exactly. We could create a working image based on Rasbian Jessie which is not compatible with the Pi 4.

On the latest Raspian Buster the image and glslViewer extensions are broken.

So what would be a good way to set up such an ISO?

I came across https://pibakery.org which seems awesome, but is still in an early stage and has some issues apparently. The official download comes with Rasbian prepacked (not sure what version that is). There is some sort of alpha/beta of a new version which comes without Raspbian and lets the user select an image when writing to SD: https://github.com/davidferguson/pibakery/releases/tag/v2.0.0 I tried this with the latest Rasbian and it failed during install (setting up the wifi) on the Pi. I'm not sure if this is related to Raspian Buster or a general issue with PiBakery. Maybe Jessie would work?

I attached this recipe (config file) to the post.

I also thought it would be very convenient to be able to set up the Pi without a keyboard and mouse or having to log in to the Pi via SSH.

The user could add a config file to the boot partition which stores login data to Wifi, Openframe and Openframe configuration options. Then on first boot, there would be a script running (Pibakery could help here) that automatically logs into wifi, changes login to command line, installs Openframe, logs into Openframe, sets it up and maybe installs more extensions. The frame should then be ready without any user interaction on the Pi.

Or you install everything manually. But I was wondering how to reset the image (disable SSH, reset the Frame and disable Wifi) cleanly? Ideally, we would have a script doing that automatically, so it's reproducible, right?

What do you think would be the best way of doing this?

[Jeremias Volker]

Maybe I posted too early. After a few minutes, while hanging in setting up the Wifi, the Pi seemed to have continued and rebooted.

I ended up with a Pi that had Wifi set up, hostname changed and boot options changed. I added an SSH file to the boot partition of the SD card with my laptop and was after booting able to log in via SSH. Openframe did not install automatically though. But anyway that's a neat way of setting up a Pi.

[Jeremias Volker]

I just spent a few hours on an image that works and a guide to creating images. My post got deleted and this has happened before. That's frustrating. Not sure what causes this. We need a new Forum!

[Jeremias Volker]

I think it had too many links and was considered spam. And since I'm on Googlemail it seems like the corresponding email has been deleted too. Can anyone recover it from their mails please?

Anyway, this is the link at least: http://openframe.jeremiasvolker.com/images/2019-09-27-Openframe-Buster.zip

hostname: OpenframeRaspi

password: openframe

[Jeremias Volker]

Luckily I had a backup somewhere: Openframe-Image-Creation-Guide.md

[Jeremias Volker]

I created working images for Pi4 and for all other Pis. You can find them in the updated guide: https://gist.github.com/jvolker/96a52b05459316643f8e110ff46b8e32