Setting up a Raspberry Pi 3 (and an Amazon FireTV Stick) as a general purpose media hub

Some months ago, the pc we were using upstairs as a media center took its final, epic dump.  I tried to update Ubuntu from 14.04 to 16.04, and a hard crash midway through made it unbootable.  After struggling for ages with flakey behavior, I decided I'd had enough, so I finally did something I'd been looking for an excuse to do for a while:  I bought a Raspberry Pi.  I got the kit with the case and the cable and the little heat sinks.  I just wanted it to be easy.  And for the most part, it was.

The Pi ran for well over an hour on a 2600ah battery pack (on the right)

The initial Raspbian installation was stupid simple, so I'm not sure I have much to add there.  Just follow the menus and it was done likety split.  Plug in my wireless mouse and keyboard, and the network cable, boot it up and.... whaaaaat is with the mouse??  First problem I ran in to was this weird laggy/sluggish/squishy mouse behavior.  It was clearly going to be a deal breaker if I couldn't resolve it.  I found this youtube video which explained the fix:  https://www.youtube.com/watch?v=IcdIyxgXwIU.  Basically, the fix is to open up /boot/cmdline.txt as root, and concatenate "usbhid.mousepoll=0" to the end.  That's it.  Mouse works as expected. Woot.

Next order of business was getting a proper web browser installed.  Ephiphany may work for some, but I found it to be rubbish.  I'm sure the developers are proud of it but it just didn't do it for me.  So I installed Chromium (Chrome proper will not work as it is not available for the ARM architecture). These are the instructions I used: https://www.raspberrypi.org/forums/viewtopic.php?t=121195.  One of the crucial use cases for me was playing bedtime music for my daughters (room right next to the living room).  The Pi didn't like Infinitelooper.com, but Listenonrepeat.com worked fine, so they got their Beethoven on a loop back :D

Without Chrome proper, it quickly became clear that Netflix was not going to work on the Pi.  Every work around I found basically said it was unwatchably choppy, so I didn't spend a lot of time thrashing on it and just bought the Amazon FireTV stick instead.  I don't remember what the deciding factor was.  I think it boiled down to the wife preferred that one lol.  I'm not going to bother with a picture because it's stuffed behind the wall mounted TV.  Netflix and Hulu run great on that, and it even has some decent games.  Not a bad buy for $40.

The last big use case for the Pi, which proved to be the trickiest to get working, was playing videos over my home network.  The files themselves are hosted from the downstairs media center.  In the old setup, I used VLC Player, which was easy to configure in such a way that network latency didn't create an issue (basically just cache a bit more).  I tried installing VLC on the Pi, but video's were unwatchable.  They just wouldn't play.  And the explaination was simple:  to run the decompression algorithms used on modern video files, you need some serious CPU, and on the Pi, that comes from hardware acceleration.  The only player that supports hardware acceleration on the Pi is the bundled player, OMXPlayer.  Compared to VLC it's horribly clunky, but it's the only tool for the job, so I had to figure out how to make it work.

My first problem was a lack of audio.  I had the Raspberry connected to the TV with the hdmi cable, and it turns out you have pass a commandline argument to OMXPlayer for it to use hdmi audio.  So "-o hdmi" fixed that problem.  But then another, more insidious problem reared it's ugly head.  Long videos would play for about five minutes, then crash.  I suspected it was due to a "buffer underrun" kind of situation, but for the life of me I couldn't find decent documentation of anyone having a similar problem.  I did finally figure out the command line arguments that would give me control over the video buffer, and I cranked that sucker up as much as I dared.  There is a bit of a delay when a video first starts as the buffer is filled, but then it's smooth sailing.  The cli argument is "--video_queue 200" where 200 is the number of MB to use.

One thing to note here that I thought was interesting (well, more like annoying but whatever).  OMXPlayer is both a binary file (the bona-fide program) and a script file that is what is actually called when you run the GUI interface.  This script file is where the additional command line arguments were added.  So whether I was using the tboplayer frontend or the omxplayergui that comes by default, both used the same settings.

The last thing I ended up doing setup-wise was adding some symbolic links to the samba shares on the desktop.  They point to the full local filesystem path (though they won't work if samba hasn't connected to the shares).  Usually I just open Nautilus and select "Open Server" to reopen the shares when need be, maybe one of these days I'll automate it.  But for now, it works well enough.  It was the only way I could navigate to the shares from inside the omxplayer gui to add a whole folder.

I will say that, while definitely not a replacement for a full desktop machine, the $75 I spent on the setup, and the $40 I spent on the FireTV stick, were a great value.  The two together really manage to perform the same functions I was using the media pc for.  In addition to Netflix and Hulu, I've also found that Youtube plays better on the fire stick than it does on the Pi.  The Pi will run lower resolution videos, but anything approaching HD and I'm much better off with the stick.  The only other weird quirkiness I've run into actually involves the fire stick:  for some damn reason, when I change inputs on the TV, it won't let me change back to the fire stick.  I suspect this is wonkiness with my TV though, so I'll leave it at that.