I currently have a MythTV setup which records free, over-the-air HD broadcast television using an HDHomerun tuner hooked to an antenna. It works wonderfully. However, I’ve been using Intel Atom systems hooked to the televisions, running MythFrontend to view the shows. I hate Intel Atom processors. Yes, they use hardly any power, but they are also terribly, frustratingly slow and feature poor.
I considered replacing my Intel Atom boxes with new AMD E-series chipsets from manufacturers such as Zotac, which are also very low-powered while performing far better than the Intel Atoms. But I instead chose to build a little system of my own using a Micro ATX form factor motherboard, and having integrated graphics that performed well enough for HD decoding.
Another factor was that I wanted a processor powerful enough to run a web browser or an RSS aggregator, which my Intel Atom processors could do, but only painfully. So I was left with a decision between the integrated graphics choices offered by Intel in their Ivy Bridge lineup, or AMD in their A-series APU’s. I needed a quad core at least, because I wanted to make one of the MythTV devices a combination backend and frontend, just to save some power.
The choice was a lot easier than I thought, once I looked into it. The AMD APU’s are, by far, the best choice, not only performance-wise, but cost-wise. In fact, for comparable systems the AMD APU and motherboard turned out to be less than half the price of the Intel Ivy Bridge solution, while offering more capabilities, and much, much, much better video performance. In fact, the video performance can’t hardly be compared.
It’s a little surprising, the marketing Intel has, that makes me feel funny choosing AMD for a new system. But it truly is, objectively speaking, the best choice in this situation, by any criteria. I’m actually impressed with what AMD is doing – they’re creating some very compelling hardware at a great price that isn’t going to win any benchmark performance awards from the talking heads, but that somehow manages to work much better and give you more, for cheaper, in many situations. It’s very interesting to me, what they might be up to now. It’s smart design, and I appreciate that.
So anyway, I went with the newest, latest and greatest APU from AMD, the A10-5800K “Trinity”. You don’t need a big separate graphics card with these, and yet they perform like you’ve got one — unless you’re doing some hard-core high-end gaming. Which I’m not with these multimedia systems. But I could, on lower settings, which was one of the reasons I chose the AMD APU’s — I’ve never had a system to game with on a big TV monitor…
And occasionally, maybe I might want to… (especially with Steam coming out with Linux support for their games) (yay!)
I also chose to get the Gigabyte GA-F2A75M-D3H motherboard for this AMD APU. Mostly because it was a bundle deal at NewEgg and had the HDMI output port that I wanted, and supported 1866 speed memory without special overclocking considerations. Apparently the APU’s like faster memory. I chose to go with the AMD Hudson D3 chipset motherboard instead of a D4, mostly because I didn’t need so many SATA3 ports. By the way, it’s crazy how many SATA3 ports you get with AMD systems any more. You’re lucky to find just a few on Intel consumer motherboards, and usually with 3rd-party chipsets that give you any more. That was another surprise for me. This board has 6 SATA3 ports internally, and that was more than enough for a 128G SSD as the boot device and a big green mechanical drive for storing the video.
Once I received the parts and looked at the motherboard box, I discovered that it supports 3 simultaneous monitor outputs. 3! I accidentally got a multi-headed board, and it turns out the AMD APU’s handle it just fine, too. I paid about $80 for this motherboard. I’m sorry to harp on about this, but you just can’t get this kind of goodness from Intel.
Anyway, now to the problem. I bought the latest and greatest from AMD’s APU line, the A10 series “Trinity” chips. I had heard in passing that AMD was doing well by Linux lately, supporting always-improving graphics drivers in their Catalyst system for Linux. There is also a Free Software X.org driver that supports AMD APU’s that works quite well and is continually improving. Unfortunately, not well enough for my use case. This is the same problem you experience with Nvidia hardware in Linux – if you need the great hardware-accelerated performance, you have to go with the closed, proprietary drivers.
I had been using Mythbuntu for handling my MythTV stuff. It’s a simple install, with minimal bloat, and well-integrated with various MythTV ecosystem components. With their last release, they decided to stay on the Ubuntu LTS release (long-term support), which I like, mostly because I don’t want my TV’s breaking every 6 months. But this means they don’t support my newest AMD APU.
So I thought, ok, this is maybe good. I can go with a full-on recent Ubuntu install and have a fully-functional system, and just use the MythTV packages there. After all, this AMD APU is a full-powered system, unlike those nearly useless Atom chips.
So I did it – installed the latest Ubuntu 12.10. And you know what? These little APU’s are fast! I couldn’t tell any difference from my far more expensive primary workstation, which also is using SSD’s. But alas, no sound output using the HDMI audio. The optical sound worked great, and of course the analog outs… but I want just one cable running to the HDTV, damnit. I installed the Ubuntu-packaged, proprietary AMD (ATI) drivers (the Catalyst drivers), but it didn’t give me HDMI sound output (but silky-smooth graphics!).
So, sitting back with hand on chin, it started to smell like an Alsa issue. The Linux kernel version Ubuntu was running, an early 3.5 series, just didn’t have support yet for the newest AMD A10 APU’s sound over HDMI, or perhaps the motherboard’s implementation… ? I wasn’t sure. But I was sure that it smelled like Alsa. And now that Alsa is part of the kernel itself, it meant a kernel upgrade. Should I compile my own in Ubuntu?
No! I should try Sabayon Linux instead. They claim to be all bleeding edge, based on Gentoo, with a quick and easy install. This was the perfect opportunity to try them out. Now, installing Gentoo is an exercise in fire and suffering, where you emerge strong and cleansed of all impurities. But Sabayon was corn syrup, gliding in fat easy! Seriously, I didn’t have to do anything but boot from the USB stick and hit install. And HDMI sound worked perfectly! They were running the last of the 3.5 series Linux kernel, so some wonderful man or woman must have coded in Alsa support. Many blessings all over you, whomever you are! The AMD Catalyst drivers were also available, and installed flawlessly.
Sabayon (Gentoo) even had a MythTV package that worked perfectly. It was running MythTV version 0.25, which is the same version Mythbuntu packages, so it connected just fine to my current MythTV server without any hassle. Sabayon gave me the higher-performing proprietary Catalyst drivers, a newer Linux kernel that has Alsa support for the HDMI audio, and a working MythTV frontend. Perfect, right? I’d found a pre-packaged setup that works flawlessly from a bleeding edge distribution that I’d never tried before. Right? Ugh. Wrong.
Unfortunately, something was crazy with the graphics overlays. As soon as I went into the MythTV setup to adjust the video to use the better video drivers, the settings menus within MythTV stopped working properly. You could select entries, but you never saw the screen where you could change settings – it was as if those settings screens were covered up by the menu you just selected from. Pure madness! I could no longer navigate the settings menu in MythTV – I even tried a couple re-installations, doing things differently. This is where I actually researched online, too, trying all kinds of changes with GLOverlays and all sorts of stuff in the xorg.conf – enabling and disabling all manner of arcane stuff that springs from the Catalyst drivers. (Nvidia is no better with all their arcane stuff, either). Oh, and I’m grateful for the arcane, too.
To make a long story short, I have a feeling after futzing about for a while that Sabayon’s bleeding edge X.org server version might be slightly ahead of what the latest Catalyst drivers can support. I can’t say that for certain, but it was my suspicion. So rather than jumping around from distribution to distribution, hoping to find the right combinations, I decided to just go with a solid distribution that was mostly there, and custom build the rest of it myself.
At first I thought I’d use Ubuntu, and just compile a newer kernel that has ALSA support the A10 APU’s (or Gigabyte’s) HDMI audio. But I don’t really want the damn thing upgraded every 6 months. So I turn to Debian. Ubuntu is built from Debian, and Debian has a few releases at once. Their current testing release is called Wheezy, and it’s mostly what Ubuntu is currently. But once Debian Wheezy is out, it’ll be a couple years before it gets a major upgrade, so my TV’s won’t break.
Since I’ll be compiling the Catalyst drivers myself anyway, and compiling the Linux kernel myself, and compiling MythTV myself (to get the latest release version 0.26), I can upgrade just these important parts any time I like, instead of a distribution doing it out from under me.
So I thought I’d document what I did to get a perfect MythTV setup working in Debian Linux for those who might like to as well. This is working in Debian Wheezy, which isn’t yet released (as of 11 Nov 2012). But they have beta install images you can download, which worked great for me. I put them on a USB stick and installed from that. You can get the Debian 7.0 (Wheezy) images from the Debian Installer developer’s website – just download the “netinst” image for the amd64 architecture. It’s at the beta3 version right now. Maybe you’ll be reading this later when it’s at beta4 instead. Or maybe wheezy has been released and you can download it from the main Debian site. The important thing is to get a Wheezy installer image. This is what works with things as they are today.
1. Make Your Install Media
For the output device (of=) make sure you use whatever device name you want to write the disk image to. In my case, my USB stick got named /dev/sdf – make sure you got yours right or you might overwrite your system disks!
wget http://cdimage.debian.org/cdimage/wheezy_di_beta3/amd64/iso-cd/debian-wheezy-DI-b3-amd64-netinst.iso
sudo dd if=debian-wheezy-DI-b3-amd64-netinst.iso of=/dev/sdf ; sync
Again, the URL might be different for you – this URL works for today. Just grab a wheezy install image. After this completes, you’ll have a USB stick that you can boot to, to install Debian Wheezy.
2. Install and Boot Debian Wheezy
Boot to the USB stick and install the system. I chose to install the standard desktop environment, using the full capacity of the SSD using LVM with all defaults. I also chose to format my big mechanical green drive as one big LVM partition formatted in ext4 with a mountpoint of /mnt/mythtv After the install, reboot into the new Debian Wheezy system. You should get GDM3 coming up just fine with the AMD A10 and Gigabyte motherboard connected via the HDMI cable. If you log in and check your audio devices, you’ll find that the HDMI audio doesn’t show up, though. A new kernel version with updated ALSA will fix this, though.
3. Compile your New Kernel
Debian Wheezy isn’t currently offering a 3.5 series kernel. I wanted it. You’ll need to download the source for it and compile it yourself. You don’t have any development environment by default, though. So you need to install the build system as well. I like using the text-based menu system to select kernel parameters, so I install ncurses as well. You can also install qt4-qmake along with qconf to get a GUI to select kernel parameters. We’ll build the kernel in /usr/src
apt-get install kernel-package libncurses5-dev qt4-qmake libqt4-dev qconf
cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.5.7.tar.bz2
tar -xjf linux-3.5.7.tar.bz2
ln -s linux-3.5.7 linux
Then, we’ll just take Debian’s default kernel parameters from their currently-installed kernel that we’re currently running, and make those our own for this new kernel build. This saves a lot of hassle. Of course you can go in and change around anything you want to after you make the xconfig. I left it pretty much the same as it was. Remember if you make any changes to save them….
cd linux
make mrproper
cp /boot/config-`uname -r` .config
make xconfig
After this you should have a nice, valid kernel .config file. Then it’s just a matter of compiling it, or rather compiling it while at the same time creating Debian packages for it, thanks to the kernel-package goodness that Debian provides. The CONCURRENCY_LEVEL environment variable allows concurrent compilation which normally greatly speeds up the process. It’s usuall set to the same number of CPU cores you’re using.
export CONCURRENCY_LEVEL=4
make-kpkg --revision=20121110 --initrd kernel_image kernel_headers
Make sure you put in the kernel_headers parameter, as you will need the headers when we compile the AMD proprietary ATI Catalyst drivers. I use the current date for the “revision” parameter. Then just install the newly compiled kernel and headers and reboot.
cd ..
dpkg -i linux-*.deb
reboot
4. Install Proprietary Drivers (or not)
Now, this Gigabyte motherboard has a couple devices that can benefit from having more proprietary firmware installed. This includes the Realtek NIC. You have to enable the Debian non-free repository to get them, if you like.
emacs /etc/apt/sources.list
You don’t have to use the emacs editor – you can use gedit or whatever your poison. Then just add on the contrib and non-free tags to the deb and deb-src lines for the normal archives as well as the security update archives, to make it look like this:
deb http://ftp.us.debian.org/debian/ wheezy main contrib non-free
deb-src http://ftp.us.debian.org/debian/ wheezy main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
deb-src http://security.debian.org/ wheezy/updates main contrib non-free
After you save that and get back to the shell, install the proprietary drivers. In my case with the Gigabyte board it’s this:
apt-get update
apt-get install firmware-linux-nonfree firmware-realtek
5. Install and Build AMD Catalyst Drivers
Now it’s time for the AMD Catalyst drivers. This is where it’s messy, and I’m telling you to do something horribly wrong and evil. But I don’t care. I know you want the easy way. These drivers don’t build very nicely in Debian, or any other Linux platform pretty much, except for Ubuntu. Because everyone uses Ubuntu and that’s what they pay attention to. What I’m doing here skips the normal Debian packaging, in the interest of just getting these closed source drivers in place. So you’ll have to remember to rebuild them any time you install a new kernel. Of course, since we’re using a custom kernel anyway, that’s no big deal.
You can download the most current Catalyst drivers directly from AMD. Put the zip file in /usr/src. We’ll then just run it…
unzip amd-driver-installer-catalyst-12.10-x86.x86_64.zip
chmod u+x amd-driver-installer-catalyst-12.10-x86.x86_64.run
./amd-driver-installer-catalyst-12.10-x86.x86_64.run --install
What a filthy, wicked thing. But reboot again… and when you log in, check your Gnome sound settings, and you should see an HDMI output device, and it should actually work now.
Some people say you need to create an /etc/X11/xorg.conf file before you’ll get the fglrx driver to load. You can do this with
amdconfig --initial
if you like. I didn’t until later, after I made some more adjustments with the amdcccl tool, which is much like the nvidia-settings tool.
6. Compile and Install MythTV from Source
Once you have the system running with the proprietary AMD Catalyst drivers, it’s time to compile and install MythTV. The current stable release is 0.26, and the source code is available from their site. Download it, and the plugins too, if you like, and place the tarballs in /usr/src.
Here we run into a lot more library dependencies. I would have loved to have found this information myself, to have made the process easier. But here it is for you, because you’re a wonderful person. Right? Well, if not, then you’re obligated to be now.
This is how you can build MythTV 0.26 from scratch on a Debian Wheezy system, to use the AMD Catalyst drivers. For nVidia it’s just a little different. Also, I’m using a -j5 during the make because the AMD A10 is a quad-core APU. Use something greater or lower if you have more or fewer cores. The following will bring in the necessary libraries, configure the MythTV build for some nice stuff, and install it to it’s default place (which is evil again, in the Debian Universe).
apt-get install libxinerama-dev libdbd-mysql-perl libmp3lame-dev libx264-dev libvpx-dev libxv-dev libxvidcore-dev libsdl1.2-dev libass-dev yasm uuid-dev libxxf86vm-dev x11proto-xinerama-dev libio-socket-inet6-perl libnet-upnp-perl python-mysqldb python-lxml python-urlgrabber libfftw3-dev libvdpau-dev libxml2-dev libavahi-compat-libdnssd-dev libcrypto++-dev gdb qt4-qmake qconf libqt4-dev build-essential
tar -xjf mythtv-0.26.0.tar.bz2
cd mythtv-0.26.0
./configure --enable-proc-opt --enable-libmp3lame --enable-libx264 --enable-libvpx --enable-libxvid --enable-sdl
make -j5
make install
7. Create the MythTV Database
Everything should be installed and ready now. The two main components of MythTV are the backend daemon, and the frontend systems that people actually watch. I had hoped this AMD A10 APU would be powerful enough to run both the backend and a frontend on the same box, and it turns out to be true. Even when it’s recording two channels at once, I can watch another recording at the same time with no problems whatsoever. I even tried it with a second frontend watching, and it worked flawlessly. Plenty of power.
The first thing to do is set up mythbackend. You’ll need a mysql server.
apt-get install mysql-server
The database schema required for mythbackend is located in the source tree we just compiled, in the database directory. Just cat it into mysql. You’ll also need a mysql user for the mythconverg database this creates, and to define privileges. I chose to leave it accessible to every host on my home network, with the default password. Am I naif? Masochistic?
mysql -p < database/mc.sql
mysql -p
grant all privileges on mythconverg.* to mythtv@"%" identified by "mythtv"
flush privileges
exit
If you’ve got another frontend in the house that you’ll want to use to watch TV or recordings, you should make sure that MySQL will allow connections from other machines. It’s one thing to set user/host privileges like we just did, but it’s another to tell the daemon itself what network sockets can established or not.
In Debian, MySQL is by default configured to not accept connections from anywhere else but localhost. To change this behavior only one parameter needs to be changed. Here I have it listen on every address the machine is.
emacs /etc/mysql/my.cnf
Or use gedit if you must. We shall not speak of other “editors”. Locate the line that says bind-address and change the localhost to a 0 dot-quad.
Find this
bind-address = 127.0.0.1
Change it to this
bind-address = 0.0.0.0
After making that change, restart MySQL. You could probably just reload it instead. I can’t be bothered to find out.
service mysql restart
And one last thing you need to do in Debian Wheezy’s variation of MySQL is to make sure timezone information is loaded directly into MySQL. MythTV now requires it to be there and it will complain, then die without it. I don’t know why they don’t just go with Postgres, by the way.
mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -p mysql
8. Create a MythTV User
You don’t have to create a special mythtv user, of course. But I like to separate out my robots from myself. It will also keep the configuration files isolated and neat in their own home directory place. We’ll also place him in appropriate groups for his access.
adduser mythtv
adduser mythtv cdrom
adduser mythtv audio
adduser mythtv video
9. Run the Backend Server
Go ahead and log into GDM3 (Gnome) as the mythtv user we created. Make sure to set your sound preferences to use the HDMI device for sound output. Open up a terminal and start the backend setup process
mythtv-setup
I won’t go into explaining the steps to set up MythTV here, since it’s pretty well documented at the MythTV website on their Wiki. After you get it set up, you can start the backend process by opening a terminal and running it. It will, by default, fork as a daemon.
mythbackend
10. Run the Frontend Server
Make sure you have the backend server running before you try running the frontend. Open a terminal as the mythtv user and fire it up.
mythfrontend
Again, check the MythTV website for detailed instructions. One thing in particular you should set is the sound settings – tell mythfronend to use the ALSA HDMI device for sound. Although you can use the Pulseaudio device as well, and get some great volume control, you’ll also experience buffer problems which will produce horrific static when you get a hiccup in the digital broadcast signal. Going directly through ALSA is best.
11. Make the MythTV Backend Start on Boot
You’ll most certainly want mythbackend to start on system boot, without you having to do it. Otherwise you might miss some television recordings. I’ll include my init script here, which works just fine on Debian Wheezy. We’ll call the startup script mythbackend. You’ll need to do this as root.
cat > /etc/init.d/mythbackend
#!/bin/sh
### BEGIN INIT INFO
# Provides: mythbackend
# Required-Start: $all
# Required-Stop: $local_fs $syslog
# Default-Start: 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts the MythTV backend
# Description: starts mythbackend using start-stop-daemon
### END INIT INFO
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
# LOCATION=/usr/local/bin
DAEMON=$(which mythbackend)
NAME="mythbackend"
DESC="MythTV Backend"
test -x $DAEMON || (echo "mythbackend is not in $PATH or it is not executable" && exit 1)
set -e
USER=mythtv
RUNDIR=/var/run/mythtv
LOGPATH=/var/log/mythtv
ARGS="--daemon --logpath $LOGPATH --pidfile $RUNDIR/$NAME.pid"
EXTRA_ARGS=""
NICE=0
if [ -f /etc/mythtv/mythbackend ]; then
. /etc/mythtv/mythbackend
fi
ARGS="$ARGS $EXTRA_ARGS"
mkdir -p $RUNDIR
chown -R $USER $RUNDIR
case "$1" in
start)
echo -n "Starting $DESC: $NAME"
## For those with firewire this will reset things before the backend starts.
## Should replace with keep_dct_alive.sh script at some point.
# firewire_tester -R
# firewire_tester -B -p 0 -n 0 -r 10
# firewire_tester -B -p 0 -n 1 -r 10
# firewire_tester -B -p 0 -n 2 -r 10
start-stop-daemon --start --pidfile $RUNDIR/$NAME.pid \
--chuid $USER --nicelevel $NICE --exec $DAEMON -- $ARGS
echo "."
;;
stop)
echo -n "Stopping $DESC: $NAME "
start-stop-daemon --stop --oknodo --pidfile $RUNDIR/$NAME.pid \
--chuid $USER --exec $DAEMON -- $ARGS
echo "."
;;
restart|force-reload)
echo -n "Restarting $DESC: $NAME"
start-stop-daemon --stop --oknodo --pidfile $RUNDIR/$NAME.pid \
--chuid $USER --exec $DAEMON -- $ARGS
echo "."
sleep 3
start-stop-daemon --start --pidfile $RUNDIR/$NAME.pid \
--chuid $USER --nicelevel $NICE --exec $DAEMON -- $ARGS
echo "."
;;
*)
N=/etc/init.d/$NAME
# echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
echo "Usage: $N {start|stop|restart|force-reload}" >&2
exit 1
;;
esac
exit 0
Do a control_d to get out of that, of course. Then just make it executable and tell the system to run it at boot time.
chmod ugo+x /etc/init.d/mythbackend
insserv -v mythbackend
12. Update the Program Guide Daily
You’ll certainly want to have up-to-date program guide information. So you can run mythfilldatabase to pull information in from SchedulesDirect whenever you like. I decided to do it every 12 hours.
Just set up a cron job to kick off whenever, running as the mythtv user. Debian makes this pretty easy – a single line. Make sure you put in both of those “>” symbols and not just one! As root, do
cat >> /etc/crontab
8 5,17 * * * mythtv mythfilldatabase --quiet
End that with a control_d remember. After you do this, every day at 8 past the hour, at 5am and 5pm, mythfilldatabase will run as the mythtv user to update your schedule information.
In Closing….
So yes, there you have it. This is the systems level stuff you need to create a media server from scratch using MythTV on an AMD A10 APU. The details of MythTV itself are better left to the MythTV documentation.
One last point of concern is the remote control. I like using my Android device to control it. You can enable network remote control in your mythfrontend general settings. The Android app I use for it is Mythmote.
But if you’re using an infrared remote control, like one of my frontends is, you’re probably going to want to use lirc to gather the IR signaling data. A hairy mess. Ugh, I suppose I should include some notes about it.
Configuring Lircd for an MCE Remote Control
This is just some quick notes, and not really a guide. One of my frontends is using a USB IR receiver that accepts signals from a Windows MCE remote control. Setting up the Lirc daemon can be a headache. This is only done where mythfrontend is running, and you want an IR remote control. Here are the basics, but only for a MCE remote!!
Lircd takes signals and translates these numerics into human-looking commands. You need two mapping files for Lircd and MythTV. One mapping file (the Lircd one) maps these numeric codes into human-looking commands, and this file goes in /etc/lirc. The other file maps these human-looking commands into mythfrontend commands, which makes it look like your remote is controlling movement and commands in MythTV.
One problem is that when your IR remote sends, say, a down arrow, it can also think it’s a keyboard typing a down arrow, with the way that the lirc kernel modules are set up. This results in double key presses for any button that has a corresponding keyboard button. So you need to disable the kernel’s interpretation of lirc events that are not related to the mceusb kernel module. This is best accomplished by adding a line to /etc/rc.local up above the “exit 0″ line.
echo lirc > /sys/class/rc/rc0/protocols
This will disable all kernel interpretations of lirc events, except for what the lirc daemon is defined to deal with, effectively eliminating double entry.
You then need an lircd.conf file to be placed in /etc/lirc that defines your mceusb remote’s key codes and maps them to human-understandable commands. This is the one I’m using:
begin remote
name mceusb
bits 16
flags RC6|CONST_LENGTH
eps 30
aeps 100
header 2667 889
one 444 444
zero 444 444
pre_data_bits 21
pre_data 0x37FF0
gap 105000
toggle_bit 22
rc6_mask 0x100000000
begin codes
#seen on HP Pavilion dv3t remote --Tim Mann, 3 Nov 2009
Media 0x00007b7f
PlayPause 0x00007b91
#unused by HP remote
KEY_BLUE 0x00007ba1
KEY_YELLOW 0x00007ba2
KEY_GREEN 0x00007ba3
KEY_RED 0x00007ba4
Teletext 0x00007ba5
#ba6 - bae unused
BA6 0x00007ba6
BA7 0x00007ba7
BA8 0x00007ba8
BA9 0x00007ba9
BAA 0x00007baa
BAB 0x00007bab
BAC 0x00007bac
BAD 0x00007bad
BAE 0x00007bae
KEY_RADIO 0x00007baf
Print 0x00007bb1
#bb2 - bb4 unused
BB2 0x00007bb2
BB3 0x00007bb3
BB4 0x00007bb4
KEY_VIDEO 0x00007bb5
Pictures 0x00007bb6
RecTV 0x00007bb7
KEY_AUDIO 0x00007bb8
KEY_TV 0x00007bb9
#bba - bbf unused
BBA 0x00007bba
BBB 0x00007bbb
BBC 0x00007bbc
BBD 0x00007bbd
BBE 0x00007bbe
BBF 0x00007bbf
#bc1 - bca unused
BC1 0x00007bc1
BC2 0x00007bc2
BC3 0x00007bc3
BC4 0x00007bc4
BC5 0x00007bc5
BC6 0x00007bc6
BC7 0x00007bc7
BC8 0x00007bc8
BC9 0x00007bc9
BCA 0x00007bca
KEY_EJECTCD 0x00007bcb
SlideShow 0x00007bcc
Visualization 0x00007bcd
#bce - bcf unused
BCE 0x00007bce
BCF 0x00007bcf
#bd1 - bd7 unused
BD1 0x00007bd1
BD2 0x00007bd2
BD3 0x00007bd3
BD4 0x00007bd4
BD5 0x00007bd5
BD6 0x00007bd6
BD7 0x00007bd7
Aspect 0x00007bd8
Guide 0x00007bd9
LiveTV 0x00007bda
KEY_DVD 0x00007bdb
#NoGap
KEY_BACK 0x00007bdc
KEY_OK 0x00007bdd
KEY_RIGHT 0x00007bde
KEY_LEFT 0x00007bdf
KEY_DOWN 0x00007be0
KEY_UP 0x00007be1
#NoGap
Star 0x00007be2
Hash 0x00007be3
#NoGap
KEY_AGAIN 0x00007be4
KEY_NEXT 0x00007be5
KEY_STOP 0x00007be6
KEY_PAUSE 0x00007be7
KEY_RECORD 0x00007be8
KEY_PLAY 0x00007be9
KEY_REWIND 0x00007bea
KEY_FORWARD 0x00007beb
#NoGap
KEY_CHANNELDOWN 0x00007bec
KEY_CHANNELUP 0x00007bed
KEY_VOLUMEDOWN 0x00007bee
KEY_VOLUMEUP 0x00007bef
#NoGap
More 0x00007bf0
KEY_MUTE 0x00007bf1
KEY_HOME 0x00007bf2
KEY_POWER 0x00007bf3
#NoGap
KEY_ENTER 0x00007bf4
KEY_CLEAR 0x00007bf5
#NoGap
KEY_9 0x00007bf6
KEY_8 0x00007bf7
KEY_7 0x00007bf8
KEY_6 0x00007bf9
KEY_5 0x00007bfa
KEY_4 0x00007bfb
KEY_3 0x00007bfc
KEY_2 0x00007bfd
KEY_1 0x00007bfe
KEY_0 0x00007bff
end codes
end remote
You’ll also need a file that lives in your mythtv user account for your frontend system. This file is ~mythtv/.mythtv/lircrc which maps those lirc mappings above into corresponding MythTV commands. Mine is here, yours may be different, depnding on your remote.
begin
prog = mythtv
button = KEY_1
config = 1
end
begin
prog = mythtv
button = KEY_2
config = 2
end
begin
prog = mythtv
button = KEY_3
config = 3
end
begin
prog = mythtv
button = KEY_4
config = 4
end
begin
prog = mythtv
button = KEY_5
config = 5
end
begin
prog = mythtv
button = KEY_6
config = 6
end
begin
prog = mythtv
button = KEY_7
config = 7
end
begin
prog = mythtv
button = KEY_8
config = 8
end
begin
prog = mythtv
button = KEY_9
config = 9
end
begin
prog = mythtv
button = KEY_0
config = 0
end
begin
prog = mythtv
button = KEY_BACK
config = Esc
end
begin
prog = mythtv
button = KEY_HOME
config = M
end
begin
prog = mythtv
button = Guide
config = S
end
begin
prog = mythtv
button = More
config = I
end
begin
prog = mythtv
button = KEY_VOLUMEDOWN
repeat = 1
config = [
end
begin
prog = mythtv
button = KEY_VOLUMEUP
repeat = 1
config = ]
end
begin
prog = mythtv
button = KEY_CHANNELUP
repeat = 3
config = Up
end
begin
prog = mythtv
button = KEY_CHANNELDOWN
repeat = 3
config = Down
end
begin
prog = mythtv
button = KEY_UP
repeat = 3
config = Up
end
begin
prog = mythtv
button = KEY_DOWN
repeat = 3
config = Down
end
begin
prog = mythtv
button = KEY_LEFT
repeat = 3
config = Left
end
begin
prog = mythtv
button = KEY_RIGHT
repeat = 3
config = Right
end
begin
prog = mythtv
button = KEY_PLAY
config = P
end
begin
prog = mythtv
button = KEY_OK
config = Return
end
begin
prog = mythtv
button = KEY_ENTER
config = Return
end
begin
prog = mythtv
button = KEY_MUTE
config = |
end
begin
prog = mythtv
button = KEY_REWIND
config = <
end
begin
prog = mythtv
button = KEY_FORWARD
config = >
end
begin
prog = mythtv
button = KEY_RECORD
config = R
end
begin
prog = mythtv
button = KEY_STOP
config = Esc
end
begin
prog = mythtv
button = KEY_PAUSE
config = P
end
# Use for backwards commercial skip
begin
prog = mythtv
button = KEY_AGAIN
config = Q
end
# Use for forward commercial skip
begin
prog = mythtv
button = KEY_NEXT
config = Z
end
begin
prog = mythtv
button = KEY_TV
repeat = 3
config = ALT+L
end
# Toggle subtitles (closed captions)
begin
prog = mythtv
button = Teletext
config = T
end
begin
prog = mythtv
button = KEY_BLUE
config = W
end
begin
prog = mythtv
button = KEY_YELLOW
config = Alt+F7
end
begin
prog = mythtv
button = KEY_GREEN
config = O
end
begin
button = Power
prog = irexec
repeat = 0
config = sudo /usr/sbin/hibernate-ram
end
Bye Bye
Ok, that’s all from me on this for now – I’m sick of writing! I hope this helps someone wanting to set up MythTV on the new AMD A10 APU’s – or really anyone looking at what’s required for an up-to-date MythTV install.
Now, there is a Debian multimedia repository that has a MythTV compiled, but if you add that repository, it also comes with a lot of other stuff, and some of that stuff has been claimed to overwrite the standard Debian stuff. So I steer clear of it.
Best of luck!