RaspBMC: Ebay USB IR remote

One of the beauties of RaspBMC is the variety of control methods available to the user.  My first box is connected to an HDMI-capable television and uses CEC to pass control codes from the TV to the Raspi, which is all very neat and convenient.  I also use Yatse XBMC remote on my Android phone because there are lots of benefits to being able to browse titles, select and queue content to watch (it can also be a little more responsive than the TV remote).  I also like the feature where you can browse on your phone and send youtube content to the TV, etc.

But the second box is connected via composite video and so gaining control codes from the remote is not an option.  Until very recently this unit did not have network connectivity either, so control via a phone app wasn’t possible either.  Indeed even though it now does have wifi, phone control as the sole option isn’t exactly the golden solution.  Sure, browsing the library via the phone is much nicer than the blocky, hard to read, low resolution of the TV but for every day tasks like pausing, volume control, etc having to unlock your phone is not super convenient.

So I thought that I’d have a go ordering a really cheap, generic USB IR remote off ebay ($4 delivered) and simply see what happens.  Again this is one of those areas where I have not read any forums posts about whether or not this works but it’s not a high-stakes gamble.

And the answer is that yes it does work.  You’ll need to reboot to get it to recognise, it won’t just hot-plug the same way that connecting a mouse to your PC would.  Many of the common keys are already functional straight away (eg play, pause, arrows, page up/down) and the mouse feature also works.  There are plenty of buttons however that are not assigned, but that should be fairly trivial to work out using a similar approach to detecting CEC commands via SSH and then creating an appropriate entry in /home/pi/.xbmc/userdata/keymaps/remote.xml.

RaspBMC: USB Wifi with RTL8188CUS

I recently built up my second RaspBMC box and due to its location this one really has a need for wireless network connectivity.  Taking a quick look on ebay this is actually a very cheap thing to achieve – indeed, a tiny USB wifi adapter at $4 (including postage) is cheaper than buying a network cable.

The one draw-back is that I have read many forums posts about people having issues with certain chipsets not being supported by RaspBMC out of the box.  In particular was Realtek’s RTL8188CUS, which seems to be by far the most popular (if not completely ubiquitous) chip in these cheap usb wifi sticks.  Most of the posts seemed to me to be a number of months old and in that time the RaspBMC project has come a long a lot in terms of updates.  So, although I have not read anything to say that this problem has gone away, I thought I would commit the measly funds required to buy one regardless and see what would happen.

And so the point of this post… I have tried it with RC4 and the RTL8188CUS chipset works totally fine without the need to install any additional drivers.  The Network Manager add-on was required, however, to get everything configured and connected.  And it’s worth noting that if initial wired network connectivity is a problem there are some pre-built images available which come with this add-on already installed.

Hopefully this post will let others know that it appears that bog-standard ebay adapters are now fine after all and the search for less widely available chipsets is no longer required.

RaspBMC: Samsung remote key codes

In a previous post I detailed the difficulty that I have been experiencing mapping the non-standard key codes implemented by Samsung for my television remote.  In that post I showed how SSH can be used to inspect log files to see what actions are taking place in response to key presses.  While this can be very useful it is not always possible to discover all the key names in order to map them.  So the purpose of this post is to keep a running list of the keys on my remote, whether they are mappable and what their key code is (if I can discover it).  As I find new codes I’ll update the list.

First of all here’s a picture of my remote for reference.  I would seem that plenty of Samsung TV remotes for different models keep the same physical layout but just screen print different labels on the buttons.  If your remote differs from mine only in a minor way it may be worth matching your physical button up with mine and giving the respective code a go.  Certainly on my remote the key codes do not necessarily match the physical label on the button.

So working from left to right, top to bottom I will present each button in the following format: <physical label>,<behaviour>,<key code>…

POWER    tv only  --
TV/DTV   tv only  --
ON/OFF   tv only  --
1        passed   one
2        passed   two
3        passed   three
4        passed   four
5        passed   five
6        passed   six
7        passed   seven 
8        passed   eight
9        passed   nine
-/--     passed   title
0        passed   zero
PRE-CH   ??       ??
+(ch)    passed   pageplus
MUTE     tv only  --
^(vol)   tv only  --
-(ch)    passed   pageminus
SOURCE   tv only  --
v(vol)   tv only  --
GUIDE    passed   guide
MENU     tv only  --
W.LINK   tv only  --
TOOLS    tv only  --
^        passed   up
RETURN   passed   ??
<        passed   left
ENTER    passed   select
>        passed   right
INFO     tv only  --
v        passed   down
EXIT     passed   back
RED      passed   red
GREEN    passed   green
YELLOW   passed   yellow
BLUE     passed   blue
TTX/MIX  tv only  --
P.SIZE   tv only  --
DMA      tv only  --
E.MODE   tv only  --
CHLIST   passed   livetv
SUBT     tv only  --
<<(rew)  passed   reverse
PAUSE    passed   pause
>>(ffwd) passed   forward
REC      ??       ??
PLAY     passed   play
STOP     passed   stop

RaspBMC dual card risk mitigation strategy

Recently the RC5 update came out for RaspBMC.  Unfortunately for me (and others) this update completely boned what was a perfectly functioning RC4.   It all started during the update process when my system got stuck in an endless loop of RaspBMC logo, XBMC time-out screen and install progress bar.  Even after a fresh install (ie loosing all my library database, custom keymaps, etc) it’s still horribly flakey – a scan to sync files with tvdb, etc causes the system to hang, the network drops out and the GUI freezes and gets covered in terminal text with clockwork regularity.

It must be said that this project is well and truly up the hobbyist end of the open-source community spectrum and quality control is not exactly robust.  It is after all basically one guy’s hobby putting it together (and what a great guy for doing it!).  But this doesn’t reduce the frustration when you go to use your media centre only to find it’s auto-updated itself into a flaming heap.  Yes, that’s right: auto-updates are turned on by default.

I can’t help but think that the responsible course of action would be for them to distribute the system with auto-update turned off by default and for the RaspBMC website to list prominently on the necessary hardware page a recommendation to run two SD cards – a primary and a test card.  Having just visited the local supermarket this is exactly the operating model that I plan to adopt.  This way the current system can be duplicated onto the test card, the update applied to it, it can be run in for a day or two and then if it all works okay it can be kept.  Should it all grind to an awkward halt then it’s super easy to simply swap the cards back like nothing ever happened.

I fully acknowledge that this project is still very much in the embryonic development stage, but users should be encouraged to treat it as such – and that involves treating updates with a high degree of skepticism until shaken down, to maintain a robust backup strategy and not to rely on the irreversible inbuilt auto-updaters.  Yet this isn’t the how it comes across in their documentation – if anything the opposite: the auto-updater has its praises sung and the files needed to install previous versions are not officially provided (I got my image file from a bloke on the forums!).

By officially encouraging the use of two cards (which let’s face it costs loose change) all the potential bad-blood from a premature code release is completely negated.  For me, if I manage to get one other user onto the dual-card system without having to find out the hard way then this post has been worth it.

RaspBMC: mapping Samsung remote

One of the great features of RaspBMC is the ability to control it using your existing TV remote when connected via HDMI.  It accomplishes this task by making use of CEC to pass control codes from the TV to the Raspberry Pi.

While most of the important buttons on my Samsung TV pass happily through to XMBC (such as navigation arrows, play, pause, stop, etc) one of the controls which is sorely missing is the ability to access the context menu.  Which means that every time I need to alter a setting I need to plug in a usb keyboard.  I would also like to be able to adjust the XBMC volume using the remote.

Thankfully XMBC is designed in such a way that you can set up your own custom keymaps to alter the behaviour of the existing remote buttons or add new ones.

The first step is to work out which of the buttons on your remote actually get passed through to the Raspi.  Not all buttons on a remote are CEC enabled, which seems to be at the whim of the TV manufacturer as is the name that each button appears as.  My volume buttons are not enabled so I want to remap Channel Up/Down to perform this function when video is playing.

If we connect to Raspi via SSH (using a terminal program such as putty) then we examine the status updates recorded in xbmc.log in response to each key press…

tail -F /home/pi/.xbmc/temp/xbmc.log

This then shows the name of each button (in this case I pressed the ‘green’ button).  The response was to bring up the Videos screen.

22:00:43 T:1182790720   DEBUG: CecLogMessage – key pressed: F3 (green) (73)
22:00:43 T:1182790720   DEBUG: PushCecKeypress – received key fc duration 0
22:00:43 T:1102835712   DEBUG: OnKey: 252 (fc) pressed, action is XBMC.ActivateWindow(MyVideos)

(You may find that key presses are not being logged.  If this is the case then you need to create /home/pi/.xbmc/userdata/advancedsettings.xml and add the lines <advancedsettings> <loglevel>1</loglevel> </advancedsettings>)

Then the final step is to make an entry in /home/pi/.xbmc/userdata/keymaps/remote.xml to bind the key to a new action (such as XBMC.ActivateWindow(VideoLibrary,MovieTitles).  The list of actions can be found the XBMC wiki (ButtonTranslator.cpp).

However things get more complicated with my Samsung remote because many of the buttons do not come up with their actual name…

12:10:10 T:1183839296   DEBUG: CecLogMessage – key pressed: channel up (30)
12:10:10 T:1183839296   DEBUG: PushCecKeypress – received key d2 duration 0
12:10:10 T:1075412992   DEBUG: OnKey: leftshift (d2) pressed, action is PageUp

Above is what happens when I press the Channel Up button.  From the above log you would expect this to respond to something like a <channel up> or <d2> tag.  But it doesn’t.  The tag you want is inexplicably <pageplus>.  The way I found this out was that this button already had a behaviour associated with it in /opt/xbmc-bcm/xbmc-bin/share/xmbc/system/keymaps/remote.xml, so I could trace it back.  However there are buttons on the remote that do pass CEC codes through but aren’t already defined with a behaviour and it seems at this point in time I have no way of finding out what their tag should be!

This is a real pain, because of all the buttons that pass through CEC only half of mine I can work out the correct tag for.  Grr!

So anyway my volume fix ends up looking something like this…

<keymap>
  <global>
  </global>
  <FullScreenVideo>
    <remote>
      <pageplus>volumeup</pageplus>
      <pageminus>volumedown</pageminus>
    </remote>
  </FullScreenVideo>
</keymap>

UPDATE: work-in-progress listing of codes