Category Archives: MythTV

Google Chromecast

I managed to get my hands on a Google Chromecast at the weekend. Many thanks to Mike Carew for bringing one back from the US for me via Dale.

Having unpacked the stick I plugged it into my TV and plugged the usb cable in to power it. At first nothing happened and the little notification light on the device stayed red. but replugging the power cable it jumped into life. The instructions directing me to http://www.google.com/chromecast/setup, I had to do this in the Chrome browser and on my Windows laptop as there is no setup app for Linux at the moment (There is a config app for Android, but this is only available for US users at the moment)

When I got to the point where I had to configure which WiFi network the chromecast should connect to there was a problem as my router’s SSID was not showing in the list. It took a couple of minutes for me to remember that I had set my router to use channel 13 as it’s normally lightly used. The reason it is lightly used is because in the US you can only use channels up to 11. A quick change of channel later and the network showed up in the list.

The next part is the only bit that is not as slick as it should be. The Chromecast was fully configured but when I tried to use one of the apps (I’ll talk about those in a moment) it would not show a Chromecast available to send data to. The problem was that my router had done it’s usual trick of walling each of the separate WiFi device from each other, this feature can be called a few things but the most common seams to be apisolation. In a place with shared WiFi like a coffee shop or hotel this is good as it stops people snooping on or attacking your machine, in the home environment this may not be suitable and in this case very much unwanted. I had run into this problem before as one of my MythTV frontends is on WiFi and I had changed the settings to allow WiFi cross talking but the router seams to forget the setting pretty quickly, my usual trick was to reboot my router if I needed to log into it from my laptop to fix things. This was going to become a real issue with the Chromecast. After bit of digging I found a forum post about how to tweak the settings via the telnet interface so quickly ran up an expect script to do it when needed.

#!/usr/bin/expect

set timeout 20
set name SuperUser
set pass ###########

spawn telnet 192.168.1.254

expect "Username : "
send "$namer"
expect "Password : "
send "$passr"
expect "{SuperUser}=>"
send "wireless mssid ifconfig ssid_id=0 apisolation=disabledr"
expect "{SuperUser}=>"
send "saveallr"
expect "{SuperUser}=>"
send "exitr"

This gets called by the script I’ve got bound to a button on my remote driving LIRC that changes the input on my TV from RGB used for MythTV to the HDMI socket used by the Chromecast which ensures my network is always setup properly. I really shouldn’t have to do this but O2 Wifibox III I have is not the best.

Once I’d got all that out of the way time to start actually using this thing for what’s made for. Out of the box there is support for the Chromecast baked into the latest version of the Android YouTube app, Google Play Music, Google Play Movies and Netflix app. I don’t have a Netflix account at the moment so I tried out the other 3.

YouTube app

When the YouTube app finds a Chromecast on the local network it adds the little cast icon to the Action bar. When you tap on this it displays a pop-up to all you to select the Chromecast (if you have more than one on the network) and then rather than play the video on the devices screen they are played on the TV. Play/Pause and volume control are available on the device. One other really nice feature is that the Chromecast maintains a queue of videos to play so you can add to the queue from your phone while it’s playing the current video, in fact if you can do this from multiple devices at the same time. This means you can take it in turns with your mates to see who can find best cat video.

Google Play Movies
Much like YouTube Google Play movies lets you play content on the Chromecast. I had rented a copy of Mud the week before getting hold of my Chromecast so I watched this on the TV rather than on my Nexus 7. The only odd part was that I had downloaded a copy to the device and it would not let me watch it via the Chromecast without deleting the local copy.

Google Play Music
The music app works as expected, showing the cover art on the screen while it plays the tracks. Because it streams tracks directly from the cloud if you are working through a playlist and hit a track that you have added directly to the storage on the phone then it will refuse to play even if you have pushed a copy of the file to Google Music’s cloud storage.

Away from applications on your Android device there is a plugin for the Chrome browser which allows you to share the content of any tab on the large screen. I need to have a look at using this for giving HTML5 based presentations.

There is a API for interacting with the Chromecast and and I’m going to have a look at writing an app to push MythTV recordings so I can replace one of my MythTV frontends. First impressions of the API make me think this shouldn’t be too hard if I can set up the right transcoding.

Over all I’m pretty impressed with the Chromecast and I’m still debating if I should ask my folks to bring me another one back as they are out in the US at the moment.

TV Scrobbling

Having seen Dale Lane’s work with VDR to build something similar to Last.FM for the TV he’s been watching, I’ve been looking to see if I could do the same with MythTV.

MythTV 0.23 has shipped recently and with it came a new event system. Having had a quick look at the feature for this it looked like it would be a good starting point for this. The following events looked like they may be able to provide what I needed.

  • Playback started
  • Playback stopped
  • Playback changed

To use events you specify a command to run when each fires. You can set these up with the mythtvsetup command. As well as specifying a command you can also pass arguments, these arguments are passed using the same tokens used for the MythTV job system. The following is not the full list, but should be enough to do what I’m looking for.

  • %TITLE% – Title
  • %SUBTITLE% – Episode subtitle
  • %CHANID% – MythTV channel id
  • %DESCRIPTION% – The blurb from EPG
  • %PROGSTART% – The listed started time for the programme
  • %PROGEND% – The listed end time for the programme

There is also an option to add a command that fires on every event which you can also pass a %EVENTNAME% argument, this is very useful for debugging event ordering. Not all of the events support all of the arguments as the data is not relevant.

After a bit of playing I managed to get most of what I needed, but there where a few problems

  1. No way to tell the difference between watching recorded and live TV
  2. No way to tell when you change channel when watching live TV
  3. No way to tell when one live programme ends and a new one starts with live TV

I raised a bug in the MythTV tracker (#8388) to cover the first 2 (since the 3rd one didn’t occur to me until I got a bit further). Which the guys very quickly added. So there is now a LiveTV Started event fired when a frontend starts watching live tv followed by a Playback Started event with the details of the programme. I’ll raise a ticket for the last one and assuming I can get sign off from the boss I’ll see about submitting a patch to add it in. In the mean time with a little extra work I can infer the programme change from the Record Started and Record Finished events.

Acting on the events

So with all these events which may be reported on either the backend or frontend it’s looking good for another messaging solution. Luckily I already broker up and running for my home power monitoring and security setup. So now I just needed to run up a script or two to publish the events and a consumer with a state machine to act on them.


#!/bin/sh
#
# playStarted.sh %TITLE% %SUBTITLE% %DESCRIPTION% %CHANID%

/home/mythtv/bin/sendMessage TV/watching/start “$1/$2 ($3) on $4″

mythtvsetup events screen

Where sendMessage is a small script that publishes the second argument to the topic in the first. The other end is Java JMS application that keeps the state machine up to date and update the database when a show ends. Dale was kind enough to send me his database schema, so the data should look the same.

What next

Now I’ve got my data logging to a local database I need to come up with a front end to present it all. Next time I get 5mins to chat to Dale when we are both in the office I will see if I can borrow some of his code and if he wants to look at if we can build a site where we can all share what we’ve been watching?

Along with the events for the internal workings of the front and backends there are 10 user configurable events that can be bound to key presses, assuming I can find a spare button on the remote it should be possible to bind one of these to something like Favourite.


Resources

Using Emprex 3009URF III Vista MCE Remote with MythTV

I recently got my hands on a new Acer Aspire Revo R3610, the plan is to use this as a second MythTV frontend in the bedrooom (I’ve still got to find a suitable TV to hang it on the back of). To go with this I needed a new remote control so I don’t need to have a keyboard and mouse plugged in, I had a bit of a search round online and found the Emprex 3009URF on Amazon, it looked like it would be perfect for what I needed. As well as having all the buttons I wanted it also uses RF rather than IR so no need to have the USB dongle in line of sight.

When it arrived I plugged it in and it showed up as 2 separate keyboards, each with about half of the buttons. This wasn’t a major problem as both where seamlessly merged by the Linux HAL keyboard layer and I was planning on wrapping the input with LIRC anyway. What was a problem was that for a few of the buttons I was not getting any key events. The missing buttons where:

  • The Big Green Start Button
  • Most of the menu buttons (TV, DVD, Music, Photos …)
  • Teletex
  • Red, Green, Yellow & Blue

Kernel work

I could have lived with out most of these apart from the Teletext and the colour buttons as these are use by the DVB-T service here in the UK to access the interactive content.I started to have a bit of hunt round online and found that there was already code in the Linux Kernel to support similar remotes. I was just about to start writing my own extention to support this one when I came across a patch that had been submitted about 2 week earlier. Details of the patch can be found here. There is some discusion between the submitter (Wayne Thomas) and the maintainer of the HID code (Dmitry Torokhov) saying that Dmitry would like to remove all the code that provides support for these types of remote now it was possible to achive the same thing with configuration files and udev. I followed the link about how to set up udev, but was unable to get even the “unkown” responses when running the monitoring program.

Given that I could not get the alternative to work it looked like the quickest way to get full support for the remote was going to mean applying the patch. Since the HID code is built into the Kernel I couldn’t just build it as a module to load into an existing Fedora Kernel, I was going to have to rebuild the whole thing. Rather than mess about pulling a raw source tree I decided to let rpmbuild do the heavy lifting since this would mean I ended up with a kernel that was a close as possible to what I already had. I downloaded the src rpm with yumdownloader. Yumdownloader doesn’t actually install the src rpm package so you need to then actually install the package


# yumdownloader kernel
# rpm -ivh kernel-2.6.31.12-174.2.22.fc12.src.rpm

The install will create a rpmbuild directory tree. This is used to do the compiling and packaging when the rpm is built using the rpmbuild command. The tree looks like this:


	rpmbuild
	   |-BUILD
	   |-BUILDROOT
	   |-RPMS
	   |-SOURCES
	   |-SPECS
	   |-SRPMS

The source tar file and all the patch files end up in the SOURCE dir and the rpm spec file goes in the SPECS dir. Applying the patch is a 2 step process. Firstly we need to down load the patch file from patchwork site listed above,I saved that in to the SOURCE dir in a file called btc-remote.patch. Secondly we need to update the spec file to ensure
that the patch is applied. This requires adding 2 lines, one to identify the file with the patch and one to actually apply it.


...
Patch16570: futex-handle-user-space-corruption-gracefully.patch

Patch16580: partitions-use-sector-size-for-efi-gpt.patch

<span style="color: blue">Patch16590: btc-remote.patch</span>

%endif

BuildRoot: %{_tmppath}/kernel-%{KVERREL}-root
...
# enable IR receiver on Hauppauge HD PVR (v4l-dvb merge pending)
ApplyPatch hdpvr-ir-enable.patch
# tell usbhid to ignore all imon devices (sent upstream 2009.07.31)
ApplyPatch hid-ignore-all-recent-imon-devices.patch
<span style="color: blue">ApplyPatch btc-remote.patch</span>

# Add kernel KSM support
ApplyPatch linux-2.6-ksm.patch
ApplyPatch linux-2.6-ksm-updates.patch
...

I have created another patch to add these lines as I expect to have to apply this next time Fedora ships a new Kernel. I have submitted a Bugzilla to ask for this patch to be included in future releases. So with patch in the right place and the right bits in the spec file the rpms are built by executing the follow command from the rpmbuild dir


# rpmbuild -bb SPECS/kernel.spec

And remove the Fedora build package then install the new one with:


# yum erase kernel-2.6.31.12-174.2.22.fc12
# yum --nogpgcheck localinstall RPMS/kernel-2.6.31.12-174.2.22.fc12.i686.rpm

LIRC

After rebooting the system to the new Kernel all the buttons now work fine. Now rather than go throw all the applications mapping the keys to the required functions I chose to use LIRC to map the key presses to the functions. LIRC has a dev/input module that will take standard /dev/input/event devices as input. First we need to
stop the HAL layer from grabbing the devices and adding them to the normal keyboard inputs. Put the following in a file called 10-ignore-emprex in /etc/hal/fdi/preprobe


<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
<device>
 <match key="info.product" contains_ncase="'BTC USB MCE Cordless Remote">
    <merge key="info.ignore" type="bool">true</merge>
 </match>
</device>
</deviceinfo>

Now we need to make sure we can indentify the /dev/input/event entries that map to the remote even if the order changes on boot. To do this we can use the udev rules. Looking in /proc/bus/input/device for the “BTC USB MCE Cordless Remote”, there will 2 entries looking a bit like this:


I: Bus=0003 Vendor=046e Product=5578 Version=0111
N: Name="BTC USB MCE Cordless Remote Control."
P: Phys=usb-0000:00:04.0-6/input1
S: Sysfs=/devices/pci0000:00/0000:00:04.0/usb2/2-6/2-6:1.1/input/input7
U: Uniq=
H: Handlers=kbd event7
B: EV=1f
B: KEY=837fff 2ff2b7 bf004444 0 0 1 f84 8a37c000 667bfa d941dfed 9e0000 0 0 0
B: REL=40
B: ABS=1 0
B: MSC=10

From this we can see that currently one of the 2 event sources is bound to event7, using this information udevadm tool a signature for the device that can be used to map the event devices to unique names.


# udevadm info -a -p $(udevadm info -q path -n /dev/input/event7)
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

  looking at device '/devices/pci0000:00/0000:00:04.0/usb2/2-6/2-6:1.1/input/input7/event7':
    KERNEL=="event7"
    SUBSYSTEM=="input"
    DRIVER==""

  looking at parent device '/devices/pci0000:00/0000:00:04.0/usb2/2-6/2-6:1.1/input/input7':
    KERNELS=="input7"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="BTC USB MCE Cordless Remote Control."
    ATTRS{phys}=="usb-0000:00:04.0-6/input1"
    ATTRS{uniq}==""
    ATTRS{modalias}=="input:b0003v046Ep5578e0111-e0,1,2,3,4,k71,72,73,74,77,80,82,83,85,86,87,88,89,
8A,8B,8C,8E,8F,90,96,98,9B,9C,9E,9F,A1,A3,A4,A5,A6,A7,A8,A9,AB,AC,AD,AE,B1,B2,B5,B6,CE,CF,D0,D1,D2,D5,
D9,DB,DF,E2,E7,E8,E9,EA,EB,100,162,166,16A,16E,178,179,17A,17B,17C,17D,17F,180,181,182,185,18C,18D,192,
193,195,1A0,1A1,1A2,1A3,1A4,1A5,1A6,1A7,1A8,1A9,1AA,1AB,1AC,1AD,1AE,1B0,1B1,1B7,r6,a20,m4,lsfw"
...

Using this and the instructions from the How to write udev rules I built the following file /etc/udev/rules.d/99-emprex.rules


KERNEL=="event[0-9]*", ATTRS{name}=="BTC USB MCE C*", ATTRS{phys}=="usb-0000:00:04.0-6/input0", SYMLINK+="input/rfremote0"
KERNEL=="event[0-9]*", ATTRS{name}=="BTC USB MCE C*", ATTRS{phys}=="usb-0000:00:04.0-6/input1", SYMLINK+="input/rfremote1"

This adds 2 symlinks to the /dev/input directory called rfremote0 and rfremote1. Using these 2 instances of lircd can be started to read both sets of inputs and pass them to the applications. To bind the lircd instance you need to start one with –listen and one with –connect as follows:


# lircd --driver=dev/input --device=/dev/input/rfremote0  --pidfile=/var/run/lirc/lircd0.pid --listen
# lircd --driver=dev/input --device=/dev/input/rfremote1  --pidfile=/var/run/lirc/lircd1.pid  --connect=localhost:8765

Once these 2 instances are up and running irw can be used to test the input and also to build the .lircrc file


# Play
begin
prog = mythtv
button = KEY_PLAY
config = Return
end

# Stop
begin
prog = mythtv
button = KEY_STOPCD
config = I
end

# Escape/Exit/Back
begin
prog = mythtv
button = KEY_BACK
config = Esc
end
...
begin
prog = xine
button = KEY_PLAY
repeat = 3
config = Play
end

begin
prog = xine
button = KEY_STOPCD
repeat = 3
config = Stop
end

begin
prog = xine
button = KEY_BACK
repeat = 3
config = Quit
end

Now we are all good to go.

Resources