Software Wine-Tasting

June 8, 2015 2:14 pm

In the software world there is a term, "dogfooding," (shortened from "eating your own dog food") which describes the act of a team / company using the very software they build--usually as a critical part of their daily work.

That is, if you're the GMail team and you want to produce the best GMail service you can, you want your software developers, designers, managers, etc. all using GMail on a daily basis.  This will expose them to rough edges that need to be improved and the raw exposure will hasten the work to fix issues.  It also serves to show confidence in the product.  You might be suspicious of the quality of GMail if you heard that all the people that work on the product use something else.

This is all well and good for the kind of software that your own team can use on a daily basis.  But what if your software isn't an email client, or an instant messenger, or a music player?  The software I spend my time building is not software that I have any reason to use.  The customers/users are a specialized group of people.

I was having a technical discussion today with a group of software developers on this subject.  We recognized that dogfooding our software didn't make any sense in our environment, but it did make sense to sit down with our users and observe how they use the software and what seems to be confusing or slowing them down.  I described this process as "wine-tasting."  We're not consuming the product, we merely sample it in small quantities to try and understand it better.

So there you have it: if you can't dogfood your software, you should at least by wine-tasting it.

Tech Museum

April 11, 2015 12:54 pm

Heather's been feeling a little uneasy about the new family organization.  So on April 1st I took the day off and we went down to the Tech Museum in San Jose for which Mike and Tina gave us a gift certificate for Christmas.

Heather had a blast.

We started with the requisite Chick-Fil-A, since one was in the area.  As we pulled in to the parking lot Heather began exclaiming, "I love Chick-Fil-A.  We're so close I can almost taste it!"  And as soon as we walked in, "This is the best day ever!"

IMG_20150401_120704So the trip started off good.

At the Tech Museum she liked playing with the infrared camera:

IMG_20150401_134349And anything she could put her hands on, which was pretty much everything:

IMG_20150401_140418The downside of the visit was that the place was crawling with school groups with little to no supervision.  Nothing particularly bad, but every exhibit was therefore swamped and trying to get a chance to play with it was difficult at times.  But, after about 2:30 when all the school groups left it was quite nice.  Heather got a chance to have the robot artist draw her picture:

IMG_20150401_143934And the spelling robot wrote her name in blocks:

It was fun. We'll have to go back sometime.

Tidy Media Center

July 4, 2014 2:06 pm

I got annoyed that every time I needed to adjust cables behind the media center it was a disaster back there.  So I finally took some time to get it all cleaned up (this was before our trip to Texas, catch-up posts coming soon now that we're home).

Tidied up media center cablesPower bricks are zip-tied to the back of the unit, common-run cables are zip-tied together and hung across hooks.  Extra slack is zip-tied up, with enough left to pull the unit away from the wall when needing to access things.  Much nicer looking.

Ubuntu 14.04 + XBMC 13 (or KODI) + Intel NUC i3

May 12, 2014 2:54 pm

For additional clarity and to help search engines the specific versions involved are: Ubuntu 14.04 codenamed "Trusty Tahr", XBMC 13 codenamed "Gotham", and an Intel NUC i3 model number D34010WYK.

As a preface, I'm doing this work while XBMC 13 is on beta 4; but I don't expect the general process will change much by the time it gets to final release.

Update: This all still works with KODI 14 as well; just change instances of "xbmc" for "kodi".  Including things like "xbmc-standalone" -> "kodi-standalone"

Update NUC's BIOS

What with the introduction of UEFI I'm not sure whether we should call this step a BIOS update, a UEFI update, or a firmware update; but that's what I did first.  I grabbed the latest firmware from Intel (version 25) and flashed it onto the NUC.  Glad to see Intel used a sane process.  Just grab the .BIO file and put it on a USB flash drive.  Upon boot, hit F7 and navigate to the BIOS Flash Update Tool.

Why didn't I just use XBMCBuntu?

[Sigh] As of this writing XBMCBuntu for Gotham beta 4 gave me a lot of issues.  First, for unknown reasons, I couldn't get the installer loaded to a flash drive using the standard Ubuntu "Startup Disk Creator."  When it came time to install the bootloader I kept getting "Uncaught Exception" and something about an invalid version string "Trusty".  I tried using UNetBootin, but it still took a few tries before I had a flash drive with a properly imaged XBMCBuntu on it.

Then I discovered that unlike the Ubuntu 14.04 image, the XBMCBuntu image (based on 14.04) doesn't support UEFI.  So I had to get into the UEFI settings to enable legacy booting.  Once I got the installer running I discovered that not only did the USB image not support UEFI booting, the installer didn't support UEFI installation (again, the standard Ubuntu 14.04 image works just fine).

So by this point I was annoyed and frustrated with XBMCBuntu and decided to go the plain Ubuntu 14.04 route and install and setup XBMC myself.

Installing Ubuntu 14.04

I'm not going to cover the process of actually installing Ubuntu 14.04--that's covered in far more detail in plenty of other places on the Internet.  Things of interest for the NUC specifically is that by default the installer determined it needed to use a UEFI install and did the correct thing without any intervention on my part.  I did, however, change the partition sizes myself as I installed to a USB flash drive rather than to a traditional hard drive.

After installation I needed to remove unwanted applications that would serve no purpose in a media center application.  Things like an office suite, email client, chat client, etc.  I didn't try to do a thorough cleaning, but just hit the obvious stuff:

> sudo apt-get remove libreoffice-common thunderbird empathy

I then did some performance tuning to account for running my system off of a USB flash drive.  I followed information from here: http://beastie.cs.ua.edu/cs150/configuration.html:

  • Change drive mounts to use "noatime" (in fstab)
  • Use a RAM disk for tmp files (also in fstab)
  • Reduce synching to the flash drive

Installing XBMC 13 (Beta 4)

I was installing from Beta 4 so I used the "unstable" PPA:

> sudo add-apt-repository ppa:team-xbmc/unstable

But you'd want to go directly to the stable PPA at this point:

> sudo add-apt-repository ppa:team-xbmc/ppa

And then:

> sudo apt-get update
> sudo apt-get install xbmc

NOTE: These repositories are the only thing (I think) that didn't change name with KODI.  So still use team-xbmc for the PPA, but when doing the install you would use "sudo apt-get install kodi".

Configuring the XBMC session for ALSA

Now comes the fun part of trying to figure out how to get XBMC, Pulseaudio, and ALSA to play together the way I wanted them to.  XBMC 13 does finally let XBMC play acceptably with Pulseaudio by default which is nice for a lot of people; but it does not support passthrough for either DTS HD-MA or Dolby TrueHD.  And since one reason I was upgrading from a Raspberry Pi to the Intel NUC was to get my full HD 7.1 channel audio working correctly I didn't like that option.

After messing around with pasuspender (pulseaudio suspender) and not getting things working, I finally went with a custom XSession script.  99% of the time this machine will boot straight to XBMC and stay in XBMC.  I didn't need to make this work properly while running XBMC inside of a normal desktop session.

So my script kills pulseaudio (allowing XBMC to utilize ALSA) and runs XBMC, once XBMC exits it restores pulseaudio.

I created a file in my home directory called xbmc_custom_session_starter

> nano ~/xbmc_custom_session_starter

containing this:

#!/bin/bash
# Kill PulseAudio so XBMC will use ALSA for proper passthrough support
echo autospawn = no > ~/.config/pulse/client.conf
killall pulseaudio
# Start XBMC
xbmc-standalone
# Restore Pulse Audio
rm ~/.config/pulse/client.conf
pulseaudio --start

And make it executable:

> chmod +x ~/xbmc_custom_session_starter

Now we need to create a custom XSession entry to use this script instead of just starting xbmc directly.  In /usr/share/xsessions there should be a file called XBMC.desktop there already.  We'll add our own (the existing one will get overwritten when you update XBMC, so don't modify it in place).

> sudo nano /usr/share/xsessions/XBMC_Custom.desktop

Copy this into the file, setting the correct home directory path for the xbmc_custom_session_starter script we just created:

[Desktop Entry]
Name=XBMC With ALSA
Comment=This session will start XBMC Media Center
Exec=/home/kyle/xbmc_custom_session_starter
TryExec=/home/kyle/xbmc_custom_session_starter
Type=Application

Now, from your regular desktop, if you logout you should be able to change your session to "XBMC With ALSA".  You do this by clicking the little icon just above the password box on the right hand side.

After going through the XBMC settings and turning on audio passthrough my receiver correctly shows 7.1 channel DTS HD-MA when playing that type of source audio.

Refresh Rate

I originally had configured XBMC to match the refresh rate of the display to the source.  This would switch the TV to use 24 frames per second when watching movies filmed at 24 frames per second (rather than leaving the TV at 60 frames per second and cramming 24 frames into every 60 refreshes).  However, there is a well known audio lag bug in XBMC when you do this, so for the moment I've disabled the option until I have a chance to investigate using a audio delay compensation for only 24 fps video (as described here http://forum.xbmc.org/showthread.php?tid=127006).  FYI, this is often referred to as the "24p audio sync bug."  The "24p" meaning 24 frames per second, progressive scanning.

Update: I was able to get this working acceptably by following information to set the audio delay to 175ms.  However, in XBMC 13 the remote would stop working when the refresh rate changed so I didn't use it.  With KODI 14 that bug has been fixed so now I'm using this.  In the advancedsettings.xml (described below) I included the following block:

<!-- Work around 24p audio sync bug -->
  <video>
    <latency>
      <refresh>
        <min>23</min>
        <max>24</max>
        <delay>175</delay>
      </refresh>
    </latency>
  </video>

Some Advanced Setttings

Also, I added an "advancedsettings.xml".  This allowed me to turn off the XBMC splash screen, hide the ext4 filesystems "lost+found" directories from XBMC's media scanners and set the specific memory cache for network streams to improve streaming stability.  The advancsedsettings.xml only exists if you create it.  Mine looks like this  (located in your home directory under .xbmc/userdata; now .kodi/userdata):

<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
  <splash>false</splash>
  <video>
    <excludefromlisting>
      <regexp>lost\+found</regexp>
    </excludefromlisting>
    <excludefromscan>
      <regexp>lost\+found</regexp>
    </excludefromscan>
    <excludetvshowsfromscan>
      <regexp>lost\+found</regexp>
    </excludetvshowsfromscan>
  </video>
  <network>
    <cachemembuffersize>15728640</cachemembuffersize>
  </network>
</advancedsettings>

Getting the NUC's IR working

I've been using an original Xbox DVD dongle ever since I started running XBMC on the original Xbox (I bought a USB to Xbox controller adapter cable at some point when I stopped using the original Xbox).  One great benefit of doing so has been that my Onkyo universal remote includes the proper codes for the Xbox DVD dongle and so everything worked very cleanly without needing additional remotes kicking around (1 remote, yay!).

The NUC, however, has an IR receiver built in, so I wouldn't need to use the trusty dongle any longer.  But that meant I would need to get something working with my Onkyo remote and preferably without changing anything regarding which button does what and without making too much of  a mess out of my configuration.

Over the recent past there has been some change that has resulted in LIRC modules being brought directly into the Linux kernel.  This has caused all manner of confusion about how you're supposed to configure and interact with LIRC.  I can't say I fully understand the change or surrounding confusion, but I managed to get a working solution without installing LIRC explicitly.

In order to get my solution in place I borrowed a lot of information from tutorials like http://forum.xbmc.org/showthread.php?tid=101151 and http://forum.xbmc.org/showthread.php?tid=170372.  And many other forum posts and websites which I can't remember.

First, there is apparently an issue with the NUC's IR receiver itself and Linux.  I took the instructions for my solution from here: http://intelnuc.blogspot.com/2014/01/getting-ir-receiver-work-with-haswell.html  But modified them since that post is for OpenElec.

I created a file in my home directory called init_ir_receiver.sh:

> nano ~/init_ir_receiver.sh

Paste in the following:

#!/bin/sh
modprobe -r nuvoton-cir
echo "auto" > "/sys/bus/acpi/devices/NTN0530:00/physical_node/resources"
modprobe nuvoton-cir

And make it executable:

> chmod +x ~/init_ir_receiver.sh

Then add that script to rc.local:

> sudo nano /etc/rc.local

At the bottom of the file before the line reading "exit 0" add the following (with the path adjusted correctly for your home directory, or wherever you decided to put the init_ir_receiver.sh script).

/home/kyle/init_ir_receiver.sh

I spent quite some time figuring out how to get my remote keys mapped to the correct actions for XBMC under the LIRC-in-kernel setup.  I'm not going to describe the process I went through, you can find most of that process in the 2 links I provided at the top of this section.

The end result is an rc_keymap file specifically for my Onkyo RC-764m remote control using the Xbox DVD remote code (33003) which controls XBMC the same as it did using the original Xbox DVD dongle.

I created a file under /etc/rc_keymaps called onkyo_rc-764m_nec_33003

> sudo nano /etc/rc_keymaps/onkyo_rc-764m_nec_33003

Which has the following content:

# table onkyo_rc-764m_nec_33003, type: NEC
# Using Onkyo Remote Code 33003
# Code mappings match same buttons when using Original Xbox Dongle Remote Code
# ScanCode LIRC_KEY # Remote button text
# LIRC_KEY is modified to get correct action in XBMC using LIRC-in-kernel fake-keyboard actions

0x2d2d3a KEY_I #Display
0x2d2d59 KEY_LEFT #Left
0x2d2d5a KEY_RIGHT #Right
0x2d2d47 KEY_UP #Up
0x2d2d48 KEY_DOWN #Down
0x2d2d4a KEY_C #Guide/Top Menu -- Context Menu
0x2d2d4b KEY_ESC #Prev CH/Menu
0x2d2d45 KEY_BACK #Return
0x2d2d56 KEY_O #Setup -- Codec Info
0x2d2d58 KEY_ENTER #Enter
# UNUSED 0x2d2d4f #Audio
0x2d2d35 KEY_COMMA #Skip Left
0x2d2d34 KEY_PERIOD #Skip Right
0x2d2d32 KEY_R #Rewind
0x2d2d33 KEY_F #Fastforward
0x2d2d31 KEY_P #Play
0x2d2d38 KEY_SPACE #Pause
0x2d2d39 KEY_X #Stop
0x2d2d3b KEY_1 #1
0x2d2d3c KEY_2 #2
0x2d2d3d KEY_3 #3
0x2d2d3e KEY_4 #4
0x2d2d3f KEY_5 #5
0x2d2d40 KEY_6 #6
0x2d2d41 KEY_7 #7
0x2d2d42 KEY_8 #8
0x2d2d43 KEY_9 #9
0x2d2d44 KEY_0 #0
# UNUSED 0x2d2d4e #+10
# UNUSED 0x2d2d46 #CLR
# UNUSED 0x2d2d7c #Search
# UNUSED 0x2d2d7d #Repeat
# UNUSED 0x2d2d7f #Random
# UNUSED 0x2d2d7e #Play Mode

The format of each line, if it's not clear, is (the IR keycode recognized by the NUC) then (the LIRC keycode to activate, which XBMC will respond to) then as a comment [meaning after the # symbol] (the text of the button on the remote control itself).

Many examples will talk about the LIRC keycode and then how to configure the XBMC's remote or keyboard mapping files to respond to the LIRC keycodes.  I bypassed this extra step by instead matching my LIRC keycodes to the expected XBMC behavior in the default mappings.

In order to activate this keymapping I modified the init_ir_receiver script we created above to look like this:

#!/bin/sh
modprobe -r nuvoton-cir
echo "auto" > "/sys/bus/acpi/devices/NTN0530:00/physical_node/resources"
modprobe nuvoton-cir
ir-keytable -c -p NEC -w /etc/rc_keymaps/onkyo_rc-764m_nec_33003

The call to ir-keytable configures the IR receiver to respond to the keymapping correctly.  Of course we also need to install ir-keytable:

> sudo apt-get install ir-keytable

Fixing Tearing

With the configuration up to this point I was experiencing some tearing.  A common solution for NVidia graphics is to disable the X server's "backing store."  This also appears to fix some issues with the NUC as well.

Some information from the XBMC Forums here: http://forum.xbmc.org/showthread.php?tid=193201 and from AskUbuntu.com here: http://askubuntu.com/questions/450593/how-do-i-eliminate-screen-tearing-on-14-04-and-xbmc-with-nvidia-331.

Both links suggest the root cause is a bug in libsdl which presumably will get fixed at some point.  Lots of sources say to modify /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf; but that file will be overwritten during system updates.  Instead you want to copy that file to /etc and then modify it there (which works for me):

> sudo mkdir /etc/lightdm/lightdm.conf.d
> sudo cp /usr/share/lightdm/lightdm.conf.d/50-xserver-command.conf /etc/lightdm/lightdm.conf.d/50-xserver-command.conf
> sudo nano /etc/lightdm/lightdm.conf.d/50-xserver-command.conf

This will open the file in nano to edit; change the file to read:

[SeatDefaults]
# Dump core
xserver-command=X -bs -core

Now you should just need to reboot to clean up the tearing issues.

Wrap Up

At this point I have XBMC working they way I want it, it's just a matter of doing the within-XBMC configuration for things like media sources, plugins, etc.

For me, I also installed Flexget and Transmission to monitor for and download things automatically.  Lots of tutorials out there if you do some searching.

Logitech Media Server (SqueezeBox Server)

I also run Logitech Media Server (Squeezebox Server) for the house from this machine.  That required using LMS 7.8 as the 7.7 line is incompatible with Ubuntu 14.04.

To enable access to the LMS 7.8 software repository we need to add it as a source to /etc/apt/soures.list (unlike XBMC, there isn't a Ubuntu PPA for this).  We'll be adding the "unstable" repository which is where 7.8 currently lives.  If that changes you'll want to change this source line to match.

> sudo nano /etc/apt/sources.list

And at the top of the file add:

# Logitech Media Server / Squeezebox Server
deb http://debian.slimdevices.com unstable main

We want it at the top so that when we install the software it finds it first from this source and not somewhere else

With that done we can install Logitech Media Server:

> sudo apt-get update
> sudo apt-get install logitechmediaserver

Unfortunately, the unstable branch updates regularly and each update seems to reset all the settings in the software (maybe I'm just missing something, resetting preferences is not a normal thing for software updates in general).  So I had to hold/lock the version so that doing "apt-get upgrade" wouldn't automatically include logitechmediaserver.  You can do hold/unhold with:

> sudo apt-mark hold logitechmediaserver
> sudo apt-mark unhold logitechmediaserver

Configuring EyeFi Server

I also use this machine as an EyeFi server which automatically copies files from Jess' camera to here so she doesn't have to muck around with removing the SD card from the camera and copy pictures around and making sure they're organized properly.  I ended up using this version which works well enough: https://github.com/dgrant/eyefiserver2

The installation process for this eyefiserver code is entirely manual.

You need to copy each file to the correct directory on your system.  At least the code repository has the correct directory hierarchies, you just need to match them.

Copy the /usr/local/bin/eyefiserver.py file to your /usr/local/bin directory and make it executable.
Copy the /etc/eyefiserver.conf file to your /etc/ directory and update it as necessary.  Copy the /etc/init.d/eyefiserver file to your /etc/init.d director and make it executable

Then make it run on startup by using update-rc.d (you can probably do this using rc.local like I did above for the IR init script, but this works for sure):

> sudo update-rc.d eyefiserver defaults
> sudo update-rc.d eyefiserver enable

And with that my system was complete and running the way I needed and wanted.

The only details left is to try and figure out a good workaround for the 24p audio bug, trying to get NetfliXBMC working, and looking into a bug where remotes and keyboard stop working when the refresh rate changes (currently not an issue since I disabled refresh rate changes because of that audio bug).

I also need to spend a little time researching remote delay/repeat options.  It's not horrible, but how button presses are interpreted is a little different than it was with the old DVD dongle and it would be an improvement to clean it up a little bit.

Mechanical analog computers

March 21, 2014 1:47 pm

ArsTechnica has a great article about the mechanical analog fire-control computers used in the navy and how they work. I think it's fascinating that people thought up these clever combinations of simple machine concepts. It makes me want to dig out my Kinect set and try to make a simple mechanical computer contraption...maybe I will!

http://arstechnica.com/information-technology/2014/03/gears-of-war-when-mechanical-analog-computers-ruled-the-waves/

The videos on the second page are definitely worth watching if you have even a passing interest in how simple machines with no electricity can compute mathematical functions.