Raspberry Pi for the win!

A couple of years ago, Tom Hoogendyk and I set up systems to run digital signs using drupal sites at UMass using a simple recipe. We created a simple one for the Biology Department first, and then Tom went on to build a more robust one for the College of Natural Science. The signs are great because they mostly repurpose the same content you need to post to keep the website up-to-date.

Other groups on campus have used commercial systems (which are wicked expensive and finicky) or tried to just loop Powerpoint presentations (which are clunky and prone to freezes) and quickly find that building custom content is time-consuming when you have to build it especially for the signs. Our system has been really reliable and simple to manage.

The content is all managed in Drupal, but we still needed some kind of player. In my initial discussions with George, I kept going back and forth whether it made more sense to use a mac mini or a little linux box. George heard "mac mini" and told everyone to just buy a mac mini. So we built the first version using mac minis. Since we were already supporting lots of macs, it was easy to support a handful of mac minis the same way. We've been using radmind for years to support macs.

Radmind has been wonderful: much better than anything else for supporting unix computers. It works like a tripwire, calculating checksums for all the files on the computer every night and replacing anything that gets modified or removed -- or installing anything new that's placed on the server. My (somewhat limited) experience with software that trusts clients to install packages has been poor: its a recipe for having clients diverge over time and, eventually, become unmanageable.

Turning the macs into players was somewhat difficult because so much of the macos is a black box. There were a bunch of odd problems: e.g. how to make the cursor disappear, how to start a browser in full-screen mode. It was a nightmare finding a programmatic way to shut off the displays at night: there is no way to script having the mac power off the display. There is a magic keystroke, but you can't execute the keystroke with Applescript. But I found a binary someone had made that happened to work.

Our existing players are all still working, but the new mac mini that Apple is releasing now won't run that version of the operating system. And the new versions of the MacOS are less amenable to being supported by local staff. They want everything to be installed via the Apple Store. And the operating system complains if you try to remove or simplify stuff (like removing the other dozen languages you don't need). So when we started needing to build new players, I looked again for a simpler solution. Eventually, I decided to try building a player using a Raspberry Pi.

I started with the basic Raspbian Wheezy distribution, compiled radmind (you need to apt-get install libssl-dev first), captured a base transcript, and then configured the stuff I needed for a player: we used Chromium for the browser, I adapted the script (written in PHP) to manage downloading the configuration for the player and starting the browser with the correct URL, and solved a handful of minor problems. You can start Chromium in full-screen with command-line switches. We use unclutter to hide the cursor (although x11vnc doesn't like that). We use tvservice to power off the display at night. The one thing I haven't figured out: I can shut off the display at night, but I can't power the display back on without rebooting. That's not fatal: we generally only power off the displays at night and then update and reboot in the morning.

I built it all and did some testing with one Raspberry Pi. This afternoon, we got a second and I used radmind to install the player image onto the new device. I found one little snag, but it basically just worked. On Monday, we'll swap out the new one and I'll get my prototype back and can play with it some more.

I was worried that it might have trouble driving a 1920x1080 display, but it pretty much worked right out of the box. At first the display was using 16 bit color, which resulted in dithering on gradients. I tried 24 bit color, but there are bugs in the driver. But 32 bits works just fine (as long as you turn off the alpha channel). But I increased the amount of RAM allocated to the GPU to 128mb. You can play with all these parameters in /boot/config.txt. I tried increasing the VRAM to 256mb, but then the OS began to thrash when I tried to run Chromium.

I was worried that the GPU wouldn't be able to run the cross-dissolves in views_slideshow that we use for the signs. They're perhaps not quite as smooth as they were in the Mac, but they're entirely satisfactory.

It looks like it will all just work. I plan to build a new control system that's based on downloading a table and looking up configuration information based on ethernet address. Currently, we use reverse-dns, which we've outgrown. I have some questions about how long these will last: I worry a bit that keeping the browser cache will cause memory fatigue on the sd card. It may be possible to work around that by creating a disk image in RAM and using the for the cache. Still -- I'm not going to bother trying solve the issue until I find that its really necessary.

Next, we need to build one for the Climate Lab. And we want to put several into the ISB, so that each floor can have its own player. And there's the whole new Life Science Laboratory building coming online that will probably use them.

The most time-consuming part is probably removing the paper from the assemble-it-yourself machine-cut Lucite case. We could probably find a prebuilt case, but, as George says, removing the paper and assembling the case is like therapy. We can use more of that.