Weekend Project: Setting up MythTV on Fedora 18

Preface/Motivation

I have had a Windows 7 based media center PC sitting in my living room for the last few years.  Its primary function was to run Windows Media Center, where it recorded and played TV shows using a Ceton Infinitv4 CableCARD tuner, and played back music and videos from rips of my DVDs. 

It has always worked well enough that I wasn't driven to throw it out the window, but over the last year or so it  began to act up.  It was taking longer and longer to become responsive after a cold boot (something like 10 minutes at the worst,) and even starting Media Center was a four or five minute ordeal as it hung with a spinning blue circle, presumably trying to access the file server sitting next to it.  And over the past couple of months it started freezing, blue-screening and even hard-locking under load, indicating some kind of hardware issue. 

The computer was put together in 2007 as my main workstation, and had an Athlon-X2 5200+ with 6 gigs of RAM and two 320G Seagate hard drives.  Since then it's made a transition to a media center PC, as I use my laptop for most of the work I have to do.  Since the system has been so unstable, and because I'm no longer a poor college student, I decided it was time for an upgrade.  Of course, a hardware upgrade means that my Windows installation has a pretty good chance of falling on its face and never recovering.

I've been using Fedora exclusively on my laptop, and decided that I wanted to try to switch to a Linux-based solution for my media center setup as well.  I really didn't feel like going through the Windows 7 re-install/endless upgrade dance after updating the hardware.  And although Windows Media Center always mostly worked, it was never overly impressive.  Windows Media Center always seemed like a second-class citizen to me.  It was quirky, hung a lot, never seemed to get any updates, and its future is pretty bleak considering Windows 8 doesn't include it at all.  I also did some preliminary research on the capabilities of mythtv with my tv tuner, and it looked like it was possible to do everything I was doing with Windows Media Center with mythtv.  So Fedora 18 it was, and my little weekend project took shape.

Disclaimer

This is not a step-by-step setup guide for MythTV.  Plenty of those already exist on the web, and I'm not nearly knowledgable enough to write my own.  This is a description of what I managed to set up with my new PC build, the gotchas I ran into along the way, all written from my recollection after the fact.  Hopefully it can fill in some gaps in the available online documentation, and give an insight into what it's like for a somewhat savvy user to set up a mythtv based media center.

New Hardware

The new system I'm setting up has the following:
- Intel i7 3770K
- Asus Maximus V Formula motherboard
- 32G Corsair Vengence DDR3 RAM
- Radeon HD 6450 (fanless)
- 850w Corsair PSU
- 128G OCZ SSD
- 2x 320G Seagate Hard Drives
- Ceton InfiniTV4 CableCARD PCI-e tuner
- USB Windows MCE Remote Receiver

Setup

Fedora Installation

Installing Fedora 18 was pretty straightforward once I got the new system put together.  I booted the Desktop Live image off of USB, and immediately clicked the Install to Disk option in the startup dialog.  I was happy that I got an opportunity to see the new Anaconda installer UI, and I really like where they're going with things.

The only hang-up I had was in the disk partitioning screen.  I managed to figure out how to get Anaconda to use a standard layout using ext4 (no LVM or brtfs) but the option to preview the partition layout seems to be gone.  I decided to trust it anyway.  It assigned 500M to /boot, 50G to /, and the rest to /home, which I'm happy with.  The rest of the installation was uneventful, and after reboot and going through firstboot I had a working Fedora 18 system.

Hardware Setup

Fedora doesn't enable TRIM support by default on SSD hard drives.  To do so, go into /etc/fstab, and add "noatime,discard" after "defaults" for all of the entries that are partitions on your hard drive (/, /boot, /home, and swap)

Mythtv uses a local disk as a buffer for live tv viewing, for pausing and rewinding live tv.  I didn't like the idea of it being on my SSD, so I set up one of my hard drives to auto-mount under /media/localstorage.  This hard drive happened to perform a similar function under my Windows setup (it just held TV recordings,) so I created a fstab entry using the UUID (found with blkid.)

Software Installation

I did a system upgrade to install all of the updates, then installed mythtv, mysql, the @development-tools group, and kernel-devel and kernel-headers. 

Ceton kernel driver

Ceton provides a Linux driver for their tuners on ther support site.  I downloaded the source, and followed the installation directions in the README.  The ctn91xx_* devices showed up in /dev, and everything seemed just peachy.

GOTCHA!
Ceton provides a udev rule that forces their devices to show up in a subfolder of /dev, /dev/ceton.  It does this by changing the NAME attribute.  Unfortunately, Fedora's udev doesn't  allow for changing the NAME of block devices, so a warning is printed and the devices are created in /dev.  Annoying, but an easy fix.  You can change NAME="ceton/%k" to SYMLINK="ceton/%k" in /etc/udev/rules.d/98-ctn91xx.rules.  This will cause udev to create the devices in /dev, and provide symlinks to them in /dev/ceton.  This is important: as I found out later, mythtv is hard-coded to look in /dev/ceton for the ctn91xx devices.

After the ctn91xx module is installed and loaded, you should see that NetworkManager has a new Ethernet interface, and its IP address will be on the 192.168.200.xxx subnet.  At this point navigating to 192.168.200.1 in a browser will show the Ceton card's web interface.

Mythbackend

Now it was time to set up the mythbackend.  Following the directions on MythTV's website, I set up the MySQL database.  Then I enabled it using systemctl enable mysqld.service, and starting it using systemctl start mysqld.service.

The next step was to run mythtv-setup and set up each of the categories.

Under the General tab, the only change I had to make was to switch the local and master backend IP addresses from 127.0.0.1 to the IP address of the machine.


Under Capture Cards, I set up four individual cards using the Ceton Cablecard tuner card type.  Each has an ip address of 192.168.200.1, and a card number of 0.  The four capture cards each have tuner numbers from 0 to 3.


The video sources is the next menu option to work with.  I added a new video source using the SchedulesDirect DVB service (and forked over some cash for a subscription).  This service lets you pull down all of the channel listings and guide information for your area.

Under Input Connections I selected each tuner and chose the Schedules Direct video source.  Then I selected Fetch Channels from Listings Source to get a valid channel list for each tuner.  I didn't adjust any of the rest of the settings.

Finally, under Storage Directories, I selected each of the available groups and entered a file path for storage.  I selected a path in my /media/localstorage mount set up earlier so that the storage and caching won't happen on my SSD.

GOTCHA!
If you're going to be running mythbackend as a system service (e.g. systemctl start mythbackend.service), then that process is going to be launched under the "mythtv" user.  As such, all directories under Storage Directories need to be writable by the "mythtv" user.  Once you decide where you'd like mythbackend to store its files, you'll want to use chown and chgrp to assign ownership of the storage directories to the mythtv user and group.  If you'd like your login user to be able to edit and remove files, you can add your user to the mythtv group.

After everything was done, I set mythbackend to start on boot using systemctl enable mythbackend.service, and started it using systemctl start mythbackend.service.  Then I ran mythfilldatabase, which pulled tv listings from SchedulesDirect without any issues.

There's definitely a lot of other stuff you can adjust in here in terms of recording and transcoding profiles.  It's ok to ignore this stuff as everything is getting set up, but I'll definitely be digging into it after basic TV viewing is working well.

Mythfrontend

With mythbackend running, I can start mythfrontend and hopefully watch Live TV.  I got the TV working, but there wasn't any sound...

GOTCHA!
My PC is hooked up to a 5.1 channel receiver via HDMI for audio and video.  The video part obviously works fine, but audio wasn't.  I tried to open the sound settings and set the default output device to the radeon HDMI output, but there was no entry in the devices list.  It turns out that the radeon driver disables HDMI audio by default.  After adding "radeon.audio=1" to the kernel's bootargs, the device showed up in the list of output devices, and audio output started working properly. Yay!  To make this permanent, I edited /etc/default/grub and added to the end of the list of bootargs.

Remote xbmc

Feeling smug with my problem solving skills, I decided to push my luck and try to set up xbmc on my laptop to stream live TV.  I fired up xbmc, went to the settings->Live TV, and enabled live tv.  Then I enabled the mythtv addon as the livetv provider, and configured it with the IP address of the backend.  After doing so, I was faced with a bunch of pop-ups complaining that connecting to the PVR server failed.

GOTCHA!
Now I'm on a remote computer, so I need to open up some firewall ports on the backend system to connect to mythbackend and mysql.  Fedora 18 uses a new firewall-config program instead of system-config-firewall, so I had to figure out how to open up some ports in the new program.  First, I selected the "home" zone, and switched the Current View dropdown to Persistent configuration.  I clicked on the "Ports" tab, and added 3306 (mysql,) 6543 and 6544 (mythbackend.)  For the "home" group settings to work, the network interface for my LAN needed to be set to use the "home" group.  After going to Options->Change Default Zones of Connections, I selected my network interface and switched the firewall zone under the General tab to "home". 

After setting the firewall properly, xbmc pulled the channel list from mythbackend, and the Live TV options worked!  Hooray, now I can watch Iron Man 2 on FX in the kitchen while I'm cooking dinner!

Conclusion

The mythbackend with mythfrontend/xbmc setup is already light years beyond the capabilities Windows Media Center provided.  I can watch, record, and transcode live TV, and now I can stream it to remote PCs and use multiple frontend clients.  Unfortunately, setup was still a little bit bumpy.  I'm not sure a newbie could have figured all of this out inside of 6 hours.

I'm excited to play with the functionality I've thus far skipped over (tv recording and automatic transcoding, commercial skip, etc.), get my MCE remote working, and maybe see if I can get an xbmc frontend running on my raspberry pi.

The internet is being Comcastic again...

Comcast^W Xfinity has a strange policy when it comes to line maintenance.  They have roving maintenance teams that drive around at night checking for sources of line noise and other interference that can potentially degrade the service on a node of subscribers.  This in and of itself isn't a big deal, network maintenance is obviously an important task, especially with an infrastructure as large and diverse as Comcast has.  The real issue is how they go about "fixing" problems they find.

In the dead of night, the maintenance team will track down lines that are spewing noise into Comcast's plant.  This noise is typically from shoddy cables, loose connections, etc.  Once they track down an especially noisy line, they'll install a one-way filter, or "trap," onto the house's service.  This trap serves to allow cable signals in to the home, and block all outgoing traffic, sort of like a one-way filter on communications.  So things like cable TV service work fine, but two-way services like on-demand and internet give up the ghost.  Once the maintenance team installs the trap, they leave.  That's it.  No tag on your door, no notes on your account, nothing to indicate that Comcast has been there and crippled your service.

So if you haven't figured out yet, this recently happened to me.  After a few hours of futility trying to reset my cable modem, I called in to Comcast's customer service, and dutifully went through the unplug-and-reset-your-cable-modem script with the operator.  After a while, the operator realized that there were no signs of life from my modem (because it had been cut off from the world) and decided the best course of action would be to send out a tech.  On Monday.  Oh, did I mention this was Friday evening?  That's right, the maintenance truck had been out in the wee hours of Friday morning, and by the time I got home from work Friday evening, the cable modem was blinking furiously trying to connect to the mothership.  Oh well, a weekend without the internet isn't the end of the world, but it sure cut in to my plans of accomplishing anything.

I snuck out of work Monday to meet the tech at my house, and he tackled the problem pretty quickly.  Once he found the trap on the line, he proceeded to test the lines in my house.  Pretty much all of the ends had to be replaced, along with a wall panel, an old splitter, and several of the longer cables in the house.  He explained the disconnect between the maintenance teams and the rest of the world, and once the line noise was within range he re-connected the house to the outside world and all was right with the universe.

For three weeks.

I woke up to the cable modem blinking furiously again.  This time, aware of the drill, I walked outside and found the cable service box on the side of the house.  I took off the lid and there were a couple of lines with big filters and bright orange tags indicating that the filters shouldn't be removed until a tech came out again.  So I called again, they scheduled another visit, and another tech came out.  I told him I'm getting used to this drill, and he told me that these maintenance teams will spot check houses that they previously cut off, ostensibly to keep an eye on the techs.  He tested all the lines in the house again, and one crappy 6' RadioShack cable later the line noise was back within acceptable parameters.

The most aggravating thing about this experience is the fact that Comcast will cut off your internet (and VOIP if you have it) service suddenly and without notice in the middle of the night, and leave no indication that they've been there other than an orange tag in a closed box (that probably should have been locked.)  You're left to call tech support, who also have zero idea that there's been a maintenance team roaming the area, and will try to walk you through all of the basic connection troubleshooting steps for 20 minutes before sending a tech out.  Some kind of door tag or other indication of their visit would have been greatly appreciated.  The fact that they can cut off your service and leave you without recourse for three days (over a weekend) is also alarming.  You can potentially be without phone and internet for an entire weekend.  But you're still paying for service, and you're also paying $20 extra every time a tech has to visit.

I'm thinking it might be time to kick Comcast to the curb and try the local competing cable provider...

Flash 11 specfile Fedora

Flash 11 is in public beta, and seems to address some of the issues the old 64 bit flash plugin was having with new versions of glibc (if you're not familiar and have some time on your hands, see RHBZ 638477.)

The "installer" is basically a tree of pre-built binaries, desktop files, and icons, with no makefile or install script.  I'd much prefer to keep track of these files and have an easy way to uninstall them later, so I came up with a quick and dirty spec file for the 64-bit release.  I'm not redistributing the RPMs, but you can build them for yourself with my spec file at:

http://richmattes.com/flashplayer.spec

Hopefully someone finds it helpful.  And if you're running 32 bit Fedora, it should be trivial to modify the spec to grab the 32 bit tarball.

This spec file is provided AS-IS, with no warranty or support.

rosjava setup on Fedora 15

After the announcement of the rosjava stack for android devices, I decided to bite the bullet and finally familiarize myself with ROS.  I have been looking for a way to periodically transmit my phone's GPS coordinates to a remote server for a project I'm working on, so I figured I'd try that as my first project with rosjava.

I've been following the directions at http://code.google.com/p/rosjava/wiki/Welcome to install the rosjava stack on my Fedora 15 x86_64 system.  Unfortunately, there are a few gotchas that aren't outlined in the documentation:

1) If you have an x86_64 installation, you'll need some i686 libraries for the android SDK.  Luckily, Fedora supports installing libraries from multiple architectures side-by-side very well.  You can install the required libraries using the following command:

sudo yum install ncurses-devel.i686 zlib.i686 glibc.i686 libgcc.i686 ncurses-libs.i686 libstdc++.i386

2) Before you run "ant dist" to build rosjava, you'll likely have to edit the ant property files.  This is for two reasons: the location of your SDK installation may not be detected, and the target android API may also be wrong.  You can add a build.properties to the following directories:

rosjava/android/library
all subdirs under rosjava/android/tutorials/

containing the following text:
target=android-10
sdk.dir=/path/to/your/android-sdk-linux_x86

You can modify the target for your desired API version (I found a more detailed explanation of these levels at http://sagistech.blogspot.com/2010/05/android-sdk-error-unable-to-resolve.html).

3) There's a missing directory in the build tree that ant seems to need, a simple "mkdir rosjava/android/library/libs" should suffice.

Now you should be able to run "ant dist" as per the directions and build rosjava.

Kinect driver for Player

Better late than never right?  I've just committed a driver for the Kinect to the Player SVN, based on the libfreenect library from the openkinect project.  I've actually been sitting on this driver for a while, but it looks like the libfreenect API has finally stabilized enough that publishing a driver is warranted.  Features of the driver include

• On the fly resolution adjustment for both the video and depth images
• On the fly control of downsampling/heatmap display output for the depth image
• Accelerometer and Tilt motor support

Pointcloud and LED support are still absent from the driver, patches welcome!

New Player tutorials & Guile driver

Last night I hashed out the Driver Capability and Driver Property stubs on the Player wiki.  They now contain some explanation of what both features are, and some example code to implement both features on the driver and client sides.  Both of these features are quite compelling, and go a long way to help deal with run-time driver configuration using Player.

Another exciting new Player contribution: Paul Osmialowski recently contributed a Guile driver to allow Scheme-like scripting from within a Player driver.  The driver is well-documented, and he was also kind enough to complete a writeup on the wiki.

The Fedora 15 Robotics Suite

With Fedora 15's release imminent, I'd like to take the time to talk about the Fedora Robotics Suite.  As some of you may have noticed, the Fedora Robotics Suite is a new feature for Fedora 15 and it is already showing up as a bullet point in many reviews of the Fedora 15 alpha and beta releases.  In an effort to elevate this feature past 'neat-sounding bullet point,' I'll do my best to explain the motivations behind the feature and give a preview of what's in store for future Fedora releases.

What is it?
The Fedora 15 release notes have this to say about the Robotics Suite:

Fedora 15 now includes the Robotics Suite, a collection of packages that provides a usable out-of-the-box robotics development and simulation environment. This ever-growing suite features up-to-date robotics frameworks, simulation environments, utility libraries, and device support, and consolidates them into an easy-to-install package group. Visit http://fedoraproject.org/wiki/Robotics for more details.

In a nutshell, the Fedora Robotics SIG has been working hard over the past few releases to create a fast and easy way to dive into robotics development, for newbies and seasoned developers alike.  The first visible result of this effort is the Fedora Robotics Suite, a package group that brings together many different robotics related libraries to make it as easy as possible for developers to use Fedora in their robotics projects.

Why is the suite needed?
The open-source robotics scene is diverse, consisting of vast amounts of independent libraries and frameworks that can be used for all kinds of robotics tasks.  Unfortunately, the robotics develpment community is small enough that even some of the largest and most well-known software packages are still "niche" packages in the scope of a large Linux distribution, often with only a handful of developers upstream. These factors add up to several problems that the Robotics Suite aims to alleviate:

• Software is difficult to configure and install.  This is mostly a problem for users who aren't familiar with Linux development and are diving in headfirst.  A short visit to many small projects' mailing lists can tell you: if the configuration and installation process for a software component is complex, or the process isn't well documented, new users can be put off by the hurdle of getting their software environment set up, long before any development can take place.  Our goal is to streamline the process by doing the hard work for you in the context of robotics-related software.
• Software has too many dependencies.  Many robotics-related programs have critical dependencies on small or fledgling libraries that otherwise have little use to the Linux community in general.  For example, the Point Cloud Library (currently under review) depends on the cminpack, flann, and eigen3 libraries.  We want to make sure all of these are available with Fedora to spare the users the time-consuming process of finding, building, troubleshooting, and installing all of these small dependencies.
• Software doesn't build properly with Fedora's system libraries.  Fedora leads the way in software versions with the latest and greatest packages from upstream.  Often, developers of smaller libraries are only testing their packages against the set of libraries on their own machine, and may be oblivious to build errors resulting from newer system libraries.  The Robotics SIG encounters these errors during packaging and updates and works with upstream to correct the issues.

Basically we want to extend the benefits of pre-packaged software to the robotics community, and in the process make Fedora the distribution of choice for robotics developers.

What's in the suite?
As noted at http://fedoraproject.org/wiki/Robotics, the Robotics Suite currently includes several large-scale robotics frameworks and simulators, including Fawkes, Player, Stage, and the RoboCup Soccer Simulator.  The Robotics Suite also consists of many specialized libraries like libphidget and libkni that interact with sensors and actuators, libraries like mrpt and openni that implement specialized algorithms for things like motion planning and image processing, and IDEs like Eclipse and Arduino to make code development easier.


What's next?
The Robotics Suite is a big milestone for the Robotics SIG, but we've got plenty of grand plans for future Fedora releases.  We'd like to create an official Robotics Spin for future releases to make it even easier to sample and use the Robotics Suite, in the home or the classroom, without having to go through the whole install process.  We are also sponsoring a Google Summer of Code student to create educational robotics software for new users that takes advantage of the packages available in the Robotics Suite.  Finally, we're always hard at work packaging new and interesting robotics-related software for the Fedora community.