Hell Is Other Peoples’ Code

My primary target for the set top box project is, of course, the Raspberry Pi 2 – it’s a handy platform to build simple embedded appliances on, just like a little set top box, but I wanted to expand its reach a bit for showing offtesting. My first thought was to port it to Windows, but after much arsing about with msys2 and mingw32 and getting precisely nowhere, I eventually gave up and turned to Linux. Many hours and much staining of my desk with the blood from my forehead, I have just about managed to port something resembling my project sufficiently that it runs in a Debian VM. See exhibits A and B below:

You’ll note that it’s not perfect, the text rendering is boned and I’m going to have to attempt to fix it, because it looks horrible, and video streaming is touchy at best (potentially requiring transcoding, which is too CPU-intensive for dozens of concurrent channels, at least without dedicated machines to do it).

But, during this painful misery of hacking at crap code, I have learnt one thing: just because a framework exists does not mean it’s a good idea to use it. I’m using openFrameworks to build this project on, I discovered it some time back and latched onto it because it allowed me to quickly set myself on the path to being able to program graphical things for Linux. All very well, of course, it did very much speed my path to being able to do so, but it turns out that it’s not as “standard” as you might expect. It uses different video libraries on just about every platform, and it doesn’t do a terribly good job of hiding that fact. Admittedly, my Pi code makes use of ofxOMXPlayer, which is a plugin designed explicitly for the Pi and nothing much else, but on Linux in general it uses GStreamer (inefficient and slow on the Raspberry Pi), on OSX it appears to use QuickTime, and on Windows it… well, I can’t even work out what it uses, but it sure didn’t work.

My solution to this seemed simple. Pick another plugin, one that’d work cross-platform, VLC perhaps. Alas, I was thwarted by the fact that the early efforts to include VLC by what I believe to be one of the openFrameworks devs had been abandoned, and the only other option looked like it was probably a lot of hassle to work with. Other plugins seemed to be platform-specific or incomplete too. Call me lazy if you like, but what’s important to me when I’m writing code for a project is being able to write code for my project, not spending days fruitlessly wrestling with stuff that’s probably not going to work no matter how hard I try, or helplessly pawing at my keyboard in the vain hope that I might be able to pretend I know what I’m doing with just enough capability to hack something towards functionality.

So ultimately I ended up with Windows not being an option, Linux being just barely possible (with work), and the Pi version being about as unstable as it ever was. I don’t mean to be an arse about people contributing free code to the world, and mine certainly isn’t brilliant, but I really do wish that this stuff was easier to work with. In this case, it’s openFrameworks and all its associated third party plugins, and if it worked the way it claims to it’d be brilliant, a simple cross-platform framework that includes more than the basics, a plethora of tools and code to get you started. But that’s the bait that get you hooked. It turns out hooks are painful.


A Remote Chance of Success

Progress, as I’m sure you can establish from the (in)frequency of posts here, has been rather slow, but I have attempted to resume development of my Sky prototype reproduction. I’ve added the basis of the menu system (besides the EPG, which I had already written), so I should be looking to add the actual menus in time. Below you can see the beginnings of the menu system:


The interactive “page” is actually a placeholder even in the real firmware, for a year or so at least, the interactive services hadn’t yet launched, but the boxes had been released with the future functionality in mind. They promoted the not-yet-available functions as a future perk, which would be added when it became available (which it was, in 1999, I believe). Luckily for me, that means I don’t actually have to do anything more in this section, beyond tweaking the “coming soon” banner to be sized more like the real thing.


If you’ve used a Sky receiver before, you’ll know that the icons at the top of the screen aren’t usually yellow and blue, but I have a bit of a problem here. I partly chose blue and yellow just for the sake of testing, it’s nice and easy to see the difference, easier than two shades of blue. However, to the best of my knowledge there are no screenshots or demos of this area of the UI dating as far back as the EPG screenshots I’m basing my work on. This might be because they hadn’t designed/written the menu system yet, or just because they didn’t feel the need to show it off, I don’t know, but the problem is that the icons on the retail firmware are blue and white. But I can’t use white, because the prototype design uses a white background. So I’m left to guess or improvise, and blue/yellow is what I’ve chosen for the time being.


I’ve also picked up a FLIRC IR receiver dongle, and I can now control what I’ve written so far with an official Sky remote control, which feels much more natural. However, the FLIRC dongle has a habit of sending certain button presses a number of times at once, so I’ve had to artificially slow the responsiveness of the UI in an attempt to prevent unintended actions. I don’t know how else to fix this issue at present, but it’s hardly the first issue I’ve had, so it’ll go on the list of “things to attempt to fix properly at some point”. I’ve also added the ability to use the channel up/down buttons to navigate for channel hopping, however this exhibits some problematic behaviour at present, either reloading the current channel or skipping several at once.


See that? That’s the absence of teletext. I know it works, it works on my TV, but try as I might (and I have, I bought yet another capture device for the job), I can’t get my PC to “receive” teletext for capturing examples and demos. It might be DScaler, the capture application, but there seem to be so few options for doing things like this, particularly on more modern operating system versions.

Segmentation fault

I’m still having to wrestle with, or more accurately grudgingly tolerate, the instability of the libraries the application is based on. It’s exceptionally good at segfaulting, which is incredibly unhelpful. I think it could probably be worked around by ensuring that the network connection is rock solid and the video files are encoded in a codec as friendly to the video decoder as possible. It’s not foolproof, but it’ll have to do, unless I figure out how to fix that as well.

That’s about where I’m at right now, I’ll continue to incrementally improve it as well as I can, and I hope when I’m “done” it’ll pass for a functional application.