Debugging XBMC Plugins

I've been learning XBMC plugin development over the past few months.  I thought it would be a good time to review my remote debugging configuration.  When I had started setting up a debugging environment, I discovered the information available was fragmented and obsolete.

A helpful source is HOW-TO:Debug Python Scripts with Eclipse.  I will refer to it throughout.

Development Environment (IDE)

You can do a lot with just using gedit (with it's python syntax highlighting).  But when things get more complicated, you'll need a place to debug.  An IDE that I've used before, on Java and Perl projects, was Eclipse.  Eclipse has a PyDev plugin available, that can be easily installed through the Updates (Help...Install New Software), which is required to add Python integrated functionality to Eclipse.  Because I didn't have Eclipse installed on my particular current system, I decided to opt for downloading LiClipse instead.  It is "lightweight" and has PyDev already installed. You'll need a Python interpreter installed -- not an issue on most Linux systems.  XBMC also uses your native Linux Python interpreter.

Refer to section 2 in HOW-TO:Debug Python Scripts with Eclipse for setting up PyDev within XBMC.

Setup Workspace

I have all my XBMC plugins located in a particular development folder named development/xbmc.  I simply setup my workspace to this folder.  For each plugin, represented by single subfolder for each (such as XBMC-pluginname), I simply go to File -> New, PyDev Project.  Give the project the appropriate name (XBMC-pluginname), select Python for Project type.  Select Grammar Version 2.7.  For Interpreter, select Default. Click on the "Click here to configure an interpreter not listed".  In the upper right pane, click the Quick Auto-Config, which will configure an interpreter for you.  If you have multiple Python Interpreters installed, repeat until the required version is created.

Before clicking the Finish button, change the radio button to "Don't configure PYTHONPATH (to be done manually later on)".

Refer to section 3 in HOW-TO:Debug Python Scripts with Eclipse for more assistance.  This part of the Wiki is out-of-date, however.

Setup Pysrc (for remote-debugging)

If you want to remote-debug your plugin (that is step through your code while running), you will need to do some further setup.  First, you need to locate the pysrc library files that came with your PyDev install.  If you do a (find . | grep pysrc) from within your Eclipse install, you should find them located in plugins org.python.pydev_3... folder.  Mine were located at ./plugins/org.python.pydev_3.3.3.201401272005/pysrc/.

Next, you'll need to find the global library location for you Python interpreter.   You can do so by running the following:

python -c "from distutils.sysconfig import *; print(get_python_lib())"

My path was /usr/lib/python2.7/dist-packages.  Copy the pysrc folder into this noted folder (you'll need to be root).  

You'll also need to create an empty file called __init__.py within this pysrc folder ( /usr/lib/python2.7/dist-packages/pysrc).  This will allow XBMC transverse into it.

Modify Your XBMC Plugin

To enable remote-debugging to your application, you will need to add some code to your plugin (say into your default.py, below the import statements).  Code I've put in mine resemble this:

try:

    remote_debugger = addon.getSetting('remote_debugger')

    remote_debugger_host = addon.getSetting('remote_debugger_host')

    # append pydev remote debugger

    if remote_debugger == 'true':

        # Make pydev debugger works for auto reload.

        # Note pydevd module need to be copied in XBMC\system\python\Lib\pysrc

        import pysrc.pydevd as pydevd

        # stdoutToServer and stderrToServer redirect stdout and stderr to eclipse console

        pydevd.settrace(remote_debugger_host, stdoutToServer=True, stderrToServer=True)

except ImportError:

    sys.stderr.write("Error: " + "You must add org.python.pydev.debug.pysrc to your PYTHONPATH.")

    sys.exit(1)

except :

    pass

The code will look for the parameter "remote_debugger" and "remote_debugger_host" in your settings.xml file.  If neither is found, an exception will be thrown, and the debugging will be disabled.  This will allow you to maintain one version of your code.  You could use a constant variable instead, but then you'd need to set it somewhere.  I see others implementing a variable like REMOTE_DEBUG and then setting it True or False in the same class, but if you forgot to switch it to False, and push your code out, it'll fail if someone deploys it.  I found my approach elegant, as the debugger code will be inactive unless the user adds the following two lines to their settings.xml:

    <setting id="remote_debugger" value="true" />
    <setting id="remote_debugger_host" value="localhost" />

The remote_debugger_host allows you to use a remote system for debugging, rather than using the same machine.  This allows you to debug your plugin on a Raspberry Pi and debug it using your laptop.  If you are debugging on the same device (laptop running XBMC), then you can leave this as localhost.  Otherwise, change it to your IP of your debugging machine.

The above code was adapted from  HOW-TO:Debug Python Scripts with Eclipse .

Raspberry Pi for Debugging

Just like you setup pysrc earlier on your computer, if you want to run your plugin from a device, such as Raspberry Pi, to remote-debug, you'll need to copy the pysrc folder, found earlier, to your Raspberry Pi.  Follow the same steps under Setup Pysrc, copying the source folder from your computer with Eclipse or LiClipse installed, to your device.  In my case, my Raspberry Pi used the same dist-packages folder (so I copied to usr/lib/python2.7/dist-packages/pysrc).

You may need to add port 5678 to your computer's firewall to allow inbound connections from your debugging device.

Adding PyDev Debugger to your View

There are several ways of accomplishing this.  I prefer going to Window -> Customize Perspective, selecting Command Groups Availability and checkboxing "PyDev Debug".  This will add a PyDev menu with the buttons "Start Debug Server" and "Stop Debug Server" to my Eclipse menu.

Actually Doing the Remote-Debugging...

To start the debugger, I flip to Debug Perspective, and then click the Start Debug Server from PyDev menu.  In the Debug Server window, you'll see "Debug Server at port: 5678". 

Now you can open XBMC.  If you have the remote-debugger code added to your plugin AND have the remote_debugger and remote_debugger_host set in settings.xml, if you try to load the plugin in XBMC, it should try to communicate to the Eclipse debugger.  If it fails to connect to the debugger, it'll push a 110 Connection Failed to the xbmc.log file.  If you see a "You must add org.python.pydev.debug.pysrc to your PYTHONPATH" error, that means the pysrc isn't accessible on your XBMC device (did you add the pysrc folder to the dist-packages folder?  did you include an empty __init__.py  file within that directory?).

If it is working, XBMC should "halt" while your debugger is passed control.  In the Debug panel, you should see an unknown with MainThread show up.  This represents the session running on your XBMC device.  You can now step through the code using standard debugging techniques.  You can also simply "Resume" (F8) to continue running to completion the plugin.

Refer to HOW-TO:Debug Python Scripts with Eclipse for further advise on debugging.

Have fun :) 

cacheStreamer for XBMC [day 16 of 20-days-of-posts series]

Cache Streamer Video add-on for XBMC

Streams a file down to a local storage file, and streams while the file downloads.

Originally developed to fix a HTTPS streaming issue in XBMC on the Raspberry Pi.

Supports [Tested on]: All XBMC 12, 12.2, and 13 including Raspberry Pi, Linux, Windows, OS X, Android, Pivos, iOS (including ATV2)

Current Version: v0.1.0

• first public release

tvScheduler for XBMC [day 15 of 20-days-of-posts series]

A tv scheduler add-on for XBMC

A video add-on for XBMC that enables playback of videos that are listed in a Google Spreadsheet.

Supports [Tested on]: All XBMC 12 and 12.2 including Linux, Windows, OS X, Raspberry Pi Android, Pivos, iOS (including ATV2)

The plugin uses the Google Spreadsheet API 3.

Getting Started: 1) download the .zip file 2) transfer the .zip file to XBMC 3) in Video Add-on, select Install from .zip

Before starting the add-on for the first time, either "Configure" or right click and select "Add-on Settings". Enter your fully-qualified Username (including @gmail.com or @domain) and Password.

FAQ:

Current Version: v0.1.0

• first public release

My original First Raspberry Pi Model B lego case revitalized [day 12 of 20-days-of-posts series]

My original lego case design case was previously discussed.  Since then, I've integrated an all-in-one LED, IR receiver and power switch board, plugged into the GPIO.  I decided to take this time to drastically improve on the original case design.


Intention: To be used for various purposes including as an XBMC media player,airplay server/client, a ASTC to wifi converter box, etc.  Need for both ethernet and wifi and access to a keyboard/trackball.


Equipment:

• Raspberry Pi (model B -- memory: 512MB, 2 USB ports, ethernet)
• RemotePi Board (previously reviewed)
• class 10 SD card
• micro USB (for power, plugged into TV <-> raspberry pi)
• HDMI cable

Assumptions:

• possible need for VIDEO port
• possible need for AUDIO jack
• no need for access to the i/o ports (camera port, GPIO pins, etc)
• require a "window" for IR receiver
• require a "window" for the power LED

Like with most of my lego projects, I don't provide full schematics and block lists.  My opinion is that if you have unused lego that you can use for a project like this, you make use of what you have, improvising as you go.

Front-side view: 

Before:

After:

A big transformation on the front side of the case.  The IR receiver is no longer snaked along to this view-point.  Therefore, it is no longer the front-side.

The IR window and onboard Pi LED window is replaced with a smaller transparent block that glows and presents better than the original.  The window door is replaced with a much shorter pair of "flag" doors, providing access to the VIDEO and AUDIO jack, keeping them "tucked away" when not in use and not negatively impacting the functionality of the case while in use.

The front of the unit no longer curves up, shortening the base of the unit by 1 lego block size. The height has been drastically reduced from s 4 +1/3rd lego blocks to 3 blocks without affecting any functionality. The bottom 1/3rd lego block size is now self-re-enforced grey layer.  The second 1/3rd lego block size black layer is gone, now that the base has better structure from a single layer.

Right-side view:

Before:

After:

I placed a white window block where the power switch's onboard LED is positioned, that gives the unit a nice glow when lit.  I placed an inset blue window piece for IR window.  The IR range provided by the window is adequate enough to get at least a 45 degree angle using the remote.  I moved up the blocks for the micro USB power port to line up with the new port.  I also added some support around the SD card as it was previously hanging out of the system.  It is now protected from being hit (and damaging the SD card port).

Back-side view:

Before:

After:

I had to get rid f the original HDMI top-swing door.  It required 2 + 2/3 lego blocks height.  With the shorter height, it was not possible to accommodate the door.  These "flag" doors are starting to become a favourite of mine, as they stay on better and they have a smaller footprint, adjust easier, and don't distract.  When not connected to a monitor/TV (for headless operation), the doors are swung down to prevent dust buildup.

Left-side view:

Before:

After:

The top-swing door over the ethernet port was shortened to accommodate the new height of the case. The door allows the port to be tucked away when not in use.  It sits perfectly flush to the unit, and with a change in the door swing mechanism the door doesn't become flimsy when open (easily falls off).

The LED windows have been eliminated since they are visible through the front-side view.

The unit is depicted with a wifi dongle and a wireless lenovo multimedia keyboard/trackpad dongle.

(this keyboard, which I owned for 1-2 years prior to owning the pi, but had yet found not a single purpose for it.  Now I find the keyboard a pure necessity )

Top view:

Before:

After:

The original base size was 13 by 10 blocks.  The new one is slightly smaller with a 13 by 9 blocks.  Had I implemented an illuminated switch instead of the RemotePi board, I would of had to increase the length from 13 to 14 as I had in previous cases.

A push-button power switch is accessible from the top of the unit.  Pressing down will either turn on the Raspberry Pi or safely shut it down (and power it off).

The GPIO access doors are gone.  Since we are using the GPIO for RemotePi board, there is no need for them.  If I ever receive my ordered Raspberry Pi camera, I may open up access to the camera port.

RemotePi Board power IR switch for Raspberry Pi [day 11 of 20-days-of-posts series]

A power switch was omitted in the design of the Raspberry Pi to keep costs down.  There was no easy interface provided to add one either, but there are many different options.  I had previously tackled the original topic in a previous post, comparing a few options, including building your circuit.

I had previously reviewed several different Raspberry Pi switches.  A new one came to my attention that I placed an order for.  It is the RemotePi Board by MSL Digital Solutions.

At its core, it promises the same functionality has the other board solutions that intercept the micro USB power connector on the Raspberry Pi, which is to control the power on/off state of the Pi through a switch and through software.  But instead of intercepting the power flow through the micro USB power connector, it controls the power through the GPIO.  Instead of connecting your power to the micro USB power connector on the Raspberry Pi, you connect it to this board.  You then either toggle the power state by pressing the black button on the top, or better, you can use a IR remote to toggle the power.

And there lies one of the key differentiators.  For application use-cases such as a media player where you need an IR receiver, this board accomplishes that purpose as well.  I discussed how you could construct your own IR receiver setup on the GPIO in a previous post, and also talked about HDMI CEC in the same post, but one of the issues that remains in either the case of adding an IR receiver or using your TV's built in HDMI CEC support (if it has it), is that you can't power on or off your Raspberry Pi using either your Pi or TV remote.  Your solution options were either to always leave the Raspberry Pi on, have it automatically turn on when your TV is on (either by a power bar or plugged into the USB service port on your TV) or manually turn it on using a hardware switch or plug when you want to use your Pi.

I don't always watch all my media content through the Raspberry Pi (such as when I play video games, watch TV channels etc), so I resorted to using the illuminated switch bundled with my IR receiver that allowed me to keep my Raspberry Pi off, when not in use, and turn it on manually by pressing the switch when I wanted to watch some Pi content.  There were a couple times I wanted to be able to use my Logitech Harmony remote to turn on the Pi.  One of the benefits of this switch implementation is that it will use the IR remote's power button to toggle the power to the Pi.  The IR receiver on the board will also work like any standard /dev/lirc device, meaning that it could replace the IR receiver I had setup on my Pi -- that it was completely compatible with XBMC.

The switch and IR receiver is contained on a single logic board.  It has a connector port that plugs directly into the GPIO.  This wasn't a concern for me, since on my XBMC Raspberry Pi units, I only use the GPIO for two purposes -- hooking up a power switch and hooking up a IR receiver.  The direct connection to the GPIO eliminated some wiring that I needed to contend with with the IR receiver and previous power switch.  The board also came with a screw with some watches and nuts so that it could be securely mounted directly onto the mount hole on the Raspberry Pi.  The first releases of the Raspberry Pis (the model B 256MB "rev 1") don't have this mount point but the board is still usable without the mount..

I decided to integrate the board with my model B bedroom TV Raspberry Pi case.  I had reviewed the lego case I had constructed for that project in a previous post.  I had still not integrated any power switch into this unit, so I was eager.

To keep inline with the pros and cons list I provided for the other switch mechanisms, here are the lists:

Pros:

• very small
• may need some modification to your raspberry pi case, but otherwise fits within the existing case (doesn't extend out from the board's footprint)
• addresses the CLEAN SHUTDOWN and POWER OFF requirements fully
• no issues with provided switch script (for other switches, I had problems and I had to make customizations to the scripts provided by other offerings)
• fully integrated IR receiver that can be used to allow your IR remote to control XBMC
• everything fully assembled

Cons:

• expensive but it does save you cost from building your own IR receiver setup or USB IR receiver 

I took apart my case's right wall to accommodate the new higher-oriented micro USB port.  I would be revamping the case completely now that I no longer needed to snake my IR receiver around to an opening on the front of the unit, I could now also drop down the height of the case due to the same reason and I would need to accommodate the hardware button to accommodate the manual switch.

The instructions provided were very simple.  After I applied the screw and plugged in the board, I connected the micro USB power to the board's port.  Immediately I saw the built in power LED flash green and red momentarily to indicate the unit had power.  I then press and held the power switch button down for 15 seconds, at which time the LED blinked between red and green continuously, indicating that it was ready to read the IR remote command for the power button.  I used the Logitech Harmony power button that had been setup for the WD TV remote profile that I had setup previously on the unit's previous IR receiver.  It really doesn't even have to be a power button -- it can be any unused button.  The blinking stopped and I could then press that button to turn on the unit.

When the IR power-assigned-button is pressed, the board's onboard LED starts blinking green, while the Raspberry Pi turns on.  Everything booted up as it would regularly.  I didn't have to make any changes to my lircd.conf profile.  I started using the unit as I normally would.

The blinking -- which is more of a "pulsing" -- for up-to-one minute on startup and shutdown give an indication that the command was received and also indicates that the unit won't respond to subsequent power on/off requests from IR during that period.  This prevents accidentally sending a second power on/off command to the unit while it works on the initial request.  It also prevents "repeating" if the IR remote sends the same commands multiple times.  .

If you are implementing this as a new IR implementation (not replacing an existing setup), you'd need to setup a remote and lircd.conf.  I discussed how to do this in a previous post.

I had no problem using the onboard IR receiver with all my Harmony remote commands or with the WD TV remote that I keep around as a backup to control the unit when my Harmony remote is lost in the room-somewhere or is charging.

To power off, I pressed the power button again.  The board passes on all the IR signals received to the Raspberry Pi, including the one assigned to the power button, but it will start triggering a shutdown when the power-assigned button command is received.  It does this by the irswitch.sh script that is installed as part of the setup.  It closely resembles the safe shutdown script (switch.sh) that I discussed using with the other power switches.  The board's LED flashes red while the board shuts down the Pi.  It continues to monitor the Raspberry Pi's shutdown for up to a minute.  When the Pi is safely complete it's shutdown, the power is cut off (so the Pi becomes powered off), and the onboard LED turns off.  You can then use either the manual power button on the board or again the IR remote's power-assigned button to turn the Raspberry Pi back on.

The onboard LED proved to be a great asset to this power switch.  I no longer had to position the front-face position in my original lego case:



I retweaked the right-side of the case to become the new front-end of the unit.

The before:



The after:

I placed a white window block where the onboard LED is positioned, that gives the unit a nice glow when lit.  I placed an inset blue window piece for IR window.  The IR range provided by the window is adequate enough to get at least a 45 degree angle using the remote.  I moved up the blocks for the micro USB power port to line up with the new port.  I also added some support around the SD card as it was previously hanging out of the system.  It is now protected from being hit (and damaging the SD card port).

A closer view:

I revamped the top of the case to integrate the power button as well:

I review all the changes I made to my Raspberry Pi lego case for this board in this follow-on post.  In general, it is very easy to integrate the board into most cases as it doesn't change the footprint size of the Raspberry Pi.  The only customizations that are needed are:

1. hole on the top for the manual power switch,
2. relocation of micro USB power source in a higher position and
3. uncovering for IR and LED visibility.

Customizing your Raspberry Pi remote [day 7 of 20-days-of-posts series]

Yesterday I discussed how you could install an IR receiver on the Raspberry Pi so that you could use an IR remote to navigate XBMC.

Today I dig a little deeper into the configuration, settings and customization.

I assume your IR receiver is working (as described in the previous post).    We continue where we left off...

To create a configuration for a given remote, run the following:

1. sudo /etc/init.d/lirc stop
2. sudo irrecord -d /dev/lirc0 ~/lircd.conf

As part of generating lirc.conf, you'll be asked to enter a key name and then press that button on the remote so that it can read the IR signal and associate with that key.

To see a list of keynames, run irrecord --list-namespace .  Some very common ones are:

         KEY_HOME

         KEY_BACK   

         KEY_SELECT

         KEY_LEFT

         KEY_RIGHT

         KEY_UP    

         KEY_DOWN   

         KEY_REFRESH  

         KEY_FASTFORWARD     

         KEY_REWIND  

         KEY_PLAYPAUSE 

         KEY_INFO        

When prompted for a key name, you would enter something like KEY_HOME and then press the HOME key on the remote.  This would capture that input and the IR code associated with the key.  If you use an invalid key name or need to change it, you can do so by modifying the generated output (in this case,  ~/lirc.conf).

For a sample remote, I used a Western Digital TV (WD TV) player that I no longer use. and the generated output of that remote is as follows:
(download lircd.conf)

# Please make this file available to others
# by sending it to <lirc@bartelmus.de>
#
# this config file was automatically generated
# using lirc-0.9.0-pre1(default) on Sat Apr 13 23:25:54 2013
#
# contributed by
#
# brand:                       /home/pi/lircd.conf
# model no. of remote control:
# devices being controlled by this remote:
#
begin remote
  name  /home/pi/lircd.conf
  bits           16
  flags SPACE_ENC|CONST_LENGTH
  eps            30
  aeps          100
  header       8935  4503
  one           520  1709
  zero          520   606
  ptrail        524
  repeat       8935  2275
  pre_data_bits   16
  pre_data       0x219E
  gap          108035
  toggle_bit_mask 0x0
      begin codes
          KEY_BACK                 0xD827
          KEY_BOOKMARKS            0xF00F
          KEY_DOWN                 0x00FF
          KEY_ENTER                0x10EF
          KEY_FASTFORWARD          0x7887
          KEY_FAVORITES            0x08F7
#          KEY_FORWARD              0x7887
          KEY_HOME                 0x609F
          KEY_INFO                 0x58A7
          KEY_MENU                 0x58A7
          KEY_LEFT                 0xE01F
          KEY_NEXT                 0x807F
          KEY_PLAYPAUSE            0x50AF
          KEY_POWER                0x48B7
          KEY_PREVIOUS             0x40BF
          KEY_REWIND               0xF807
          KEY_RIGHT                0x906F
          KEY_STOP                 0x20DF
          KEY_UP                   0xA05F
      end codes
end remote

If you have a Logitech Harmony remote, life is even easier.  You can select almost any media player remote, push the settings to your Harmony remote, and then capture they keypresses like described in the above.  If you want to cheat, you could search for the remote setting for "WD TV" and then skip capturing the codes and just copy-and-paste the above lircd.conf as your own.  

If you didn't generate the lirc.conf in the correct location, or if you are copying it from a difference source, make sure you store it in /home/pi/ on your Raspberry Pi.

All you need to do now, is in Raspbmc Settings (under Programs), use the settings Enable Repeat Filter (enable/fill in dot), Enable GPIO TSOP IR Receiver (enable/fill in dot), GPIO IR Remote Profile select Custom (lircd.conf on pi's home folder).

Then either restart XBMC (you can kill -9 on the xbmc.bin process in a ssh session) or reboot the Pi, and once the Lirc service starts in XBMC, your remote should control XBMC.

We don't have to stop here.  We can further move onto some customization.

It might be handy, for instance, to associate a remote key to a function.  For example, there is no key set that would allow us to quickly access the Favourites Menu.  In actuality, we can associate almost any function in XBMC to a key on a remote (likewise can be done for keyboard, mice, and joysticks).

We can repurpose an existing key, such as KEY_HOME, which we will use for this example.  If you have a Harmony remote, you could create virtual keys fairly easy that would appear in the activity screen on the remote.  The "WD TV" device in Harmony actually contains a few such keys such as A, B and C.  You can look up any unusued key name in the keymap (running the irrecord --list-namespace that was ran earlier), and associate the IR signal to the key name and add it to your lircd.conf.  For simplicity, this example will simply repurpose the KEY_HOME.

On the Raspberry Pi, I will create a file /home/pi/.xbmc/userdata/Lircmap.xml .  I add the following entries to that file:

(download Lircmap.xml)

<lircmap>

 <remote device="devinput">    

<back>KEY_BACK</back>

<up>KEY_UP</up>

   <left>KEY_LEFT</left>

   <select>KEY_SELECT</select>    

<right>KEY_RIGHT</right>

   <down>KEY_DOWN</down>

   <stop>KEY_STOP</stop>

   <info>KEY_INFO</info>

   <skipminus>KEY_REWIND</skipminus>

   <play>KEY_PLAYPAUSE</play>

   <skipplus>KEY_FASTFORWARD</skipplus>

   <menu>KEY_HOME</menu>

 </remote>

</lircmap>

In  Lircmap.xml, I am associating my key names to functions in XBMC.  You can look up all the available function names from http://wiki.xbmc.org/index.php?title=keymap .  It appears they are case-insensitive (Play = play).  I can associate the keys to explicit functions.  Because you are using KEY_* names that are actually valid and common, these are mapped to their appropriate functions in XBMC by default.  Therefore, you could have stopped and not created this file, and still be able to use the keys to invoke common functions in XBMC.  You only have to create this file and start mapping keys once you have decided to reprogram their functions.  You can select any available function name (you cannot make up your own, but you can select an existing name and repurpose it).  We will select an unused <menu></menu> and associate the KEY_HOME to it as in <menu>KEY_HOME</menu>.

Finally, on the Raspberry Pi, I will create a file /home/pi/.xbmc/userdata/keymaps/remote.xml .  I add the following entries to that file:

(download remote.xml)

<keymap>

 <global>   

<remote>      

<menu>XBMC.ActivateWindow(Favourites)</menu>   

</remote> 

</global>

</keymap>

I invoke the XMBC.ActiveWindow function and pass it Favourites to open the favourites.xml in a Favourties menu.  There are a number of windows that can be opened to common function.  There are also a number of different functions that can be called.  Favourites does exist in XBMC (it is actually a Window ID type that automatically loads whatever is listed in favourites.xml).  There are also a bunch of different window IDs that you can do the same action on.  You could literally have a 400 key remote and still not have enough keys to satisfy all the functions and windows to call upon.

At this point, with the menu defined to the KEY_HOME in the Lircmap.xml and the menu defined with our custom action to open the Favourites Window in  remote.xml, we can either restart XBMC (you can kill -9 on the xbmc.bin process in a ssh session) or reboot the Pi, and once the Lirc service starts in XBMC, your custom key should perform the action of opening the Favourites menu.

The last time I have is troubleshooting.  If a key doesn't appear to be performing correctly or if you don't believe you've mapped it correctly, while in XBMC on the Raspberry Pi, ssh into the system and run irw. When you press keys on your remote to XBMC, the actions and key names invoked should appear in the ssh session.  This will quickly help identify the key name associated with the key.  If you press a key and it doesn't appear in the session, it means you haven't mapped it in the lircd.conf.