Using an MCE Remote with Mythbuntu

As I chronicled in a previous post, I've been using MythMote on my (Android) cell phone to serve as a remote control for my MythTV installation (running on Mythbuntu) when watching recordings  or live TV. For the most part this works fine, but there are little inconveniences associated with it, so I decided it was time buckle down and get one of my (many) remote controls to do the job. As it happens, I have Windows Media Center infrared receiver attached to the machine via USB drive, so the associated remote control was the logical choice.

I took the better part of a day to get it working, so I'll chronicle here the things I learned. Everything here is specific to MythTV running on some version of Linux, and much of it may require adjustment if MythTV is not installed on Mythbuntu, Ubuntu or maybe Linux Mint or Debian.

Ignore LIRC

As with any of my MythTV adventures, I started by consulting Google. It turns out a lot of the information out there is obsolete if you have a remotely recent operating system. Many (most?) of the posts I found discussed how to work with Linux Infrared Remote Control (LIRC), an add-on package for Linux. The catch is that infrared remote support is baked into recent kernels, so you don't need LIRC unless you want to use certain extended capabilities that it apparently provides. I don't know what they are, and I don't need them.

One Ring to Control Them All

Get to know the ir-keytable command, which will be your friend through all this.  Running it (with no options) in a terminal told me that my system understood that I had an MCE receiver attached (on /dev/input/event3, as it turns out ... yours may differ). Running

ir-keytable --device /dev/input/event3 --test

then let me test which key events were detected when each button on the remote was pressed.

BIOS Nonsense

This led to the first "minor" problem: according to ir-keytable, none of the buttons on my remote were registering. The LEDs on the remote and receiver both lit with each button press, so the receiver was "hearing" the remote; it just wasn't being believed by the system. Further consultation with Google led me to this post, which suggested that the problem lies in how some BIOSes support USB 3. The IR receiver was plugged into a USB 2 hub, and I don't have anything attached to the machine via USB 3 (I'm not even sure it has a USB 3 jack), but whatever. I rebooted, got into the BIOS editor, found the setting for USB 3 support (every damn BIOS seems to hide it in a different place, so I can't tell you exactly where to look), and turned it off, then booted back into Mythbuntu. This achieved a partial success: ir-keytable in test mode could see button presses! That's the good news. The bad news is that only a few were interpreted correctly.

Remapping the Buttons

The next step is to remap the buttons on the remote. The drill is to map buttons to the keys you would use if you were controlling MythTV with a keyboard. An important note here is that I'm only concerned with "playback" controls, not with controlling operating system menus or other applications. Here are some helpful links for that.

• The MythTV wiki Keybindings page lists keyboard keys associated with various operations (e.g., "P" for pause/resume playback). Keep this handy as a reference.
• "HOWTO: Get MCE USB remote working in Ubuntu without using LIRC for MythTV or Kodi (xbmc)" is a blog post with detailed, step-by-step instructions. Use this as your main guide. I will say that I deviated a bit here and there. In particular, the author has you generate the default button mapping and save it directly its final destination. This is the line
  
  sudo ir-keytable --read --device=/dev/input/event10 > /etc/rc_keymaps/myrc6_mce
  
  in his post. I found it much easier to write the file to the desktop, edit it there, experiment until I got it right, and only then move it to /etc/rc_keymaps. (The move requires superuser rights; editing on the desktop does not.)
• "MythTV: Use All Buttons of Your Remote Control - Without LIRC" is another handy post on the same subject. In particular, it has a table at the end of all possible key codes, which you may find useful as a reference (to tell, for instance, that the escape key is KEY_ESC rather than KEY_ESCAPE).

My Remapping

There was some trial-and-error getting to a mapping I liked, but ultimately I was successful. The "HOWTO" blog post identifies an issue with key codes greater than 255 (those with three digit hexadecimal codes). Apparently X11 does not like them. I found, however, that some of the two digit key codes did not work as specified, either, and had to be remapped to other two digit codes. My remote is an RC6 type (the first of the two black ones shown here -- although I'm in the US, not the UK or AU). Reproduced below are just the key mappings I changed in the "myrc6_mce" file.

scancode 0x800f0400 = KEY_0 # was KEY_NUMERIC_0 (0x200)
scancode 0x800f0401 = KEY_1 # was KEY_NUMERIC_1 (0x201)
scancode 0x800f0402 = KEY_2 # was KEY_NUMERIC_2 (0x202)
scancode 0x800f0403 = KEY_3 # was KEY_NUMERIC_3 (0x203)
scancode 0x800f0404 = KEY_4 # was KEY_NUMERIC_4 (0x204)
scancode 0x800f0405 = KEY_5 # was KEY_NUMERIC_5 (0x205)
scancode 0x800f0406 = KEY_6 # was KEY_NUMERIC_6 (0x206)
scancode 0x800f0407 = KEY_7 # was KEY_NUMERIC_7 (0x207)
scancode 0x800f0408 = KEY_8 # was KEY_NUMERIC_8 (0x208)
scancode 0x800f0409 = KEY_9 # was KEY_NUMERIC_9 (0x209)
scancode 0x800f040a = KEY_BACKSPACE # was KEY_DELETE (0x6f)
scancode 0x800f040d = KEY_M # was KEY_MEDIA (0xe2)
scancode 0x800f040e = KEY_F9 # was KEY_MUTE (0x71)
scancode 0x800f040f = KEY_I # was KEY_INFO (0x166)
scancode 0x800f0410 = KEY_F11 # was KEY_VOLUMEUP (0x73)
scancode 0x800f0411 = KEY_F10 # was KEY_VOLUMEDOWN (0x72)
scancode 0x800f0412 = KEY_UP # was KEY_CHANNELUP (0x192)
scancode 0x800f0413 = KEY_DOWN # was KEY_CHANNELDOWN (0x193)
scancode 0x800f0414 = KEY_RIGHT # was KEY_FASTFORWARD (0xd0)
scancode 0x800f0415 = KEY_LEFT # was KEY_REWIND (0xa8)
scancode 0x800f0416 = KEY_P # was KEY_PLAY (0xcf)
scancode 0x800f0418 = KEY_P # was KEY_PAUSE (0x77)
scancode 0x800f0419 = KEY_SPACE # was KEY_STOP (0x80)
scancode 0x800f041a = KEY_END # was KEY_NEXT (0x197)
scancode 0x800f041b = KEY_HOME # was KEY_PREVIOUS (0x19c)
scancode 0x800f0422 = KEY_ENTER # was KEY_OK (0x160)
scancode 0x800f0423 = KEY_ESC # was KEY_EXIT (0xae)
scancode 0x800f0426 = KEY_S # was KEY_EPG (0x16d)
scancode 0x800f046e = KEY_P # was KEY_PLAYPAUSE (0xa4)
scancode 0x800f0481 = KEY_P # was KEY_PLAYPAUSE (0xa4)

 

Stuttering

Update 12/28/16: The one issue I discovered with the remote was a tendency for button presses to be counted twice (occasionally, not always). This can be moderately annoying when running through menus or trying to pause/resume and terribly annoying when trying to fast forward or reverse.

Fortunately, the solution is simple, and hinges on the fact that the button presses are being treated as keyboard input. In Mythbuntu's main menu, navigate to Settings > Accessibility > Keyboard > Slow Keys. Select the check box for "Use slow keys" and set the "Acceptance delay" slider to something around 100 ms. The menu location may vary with other distributions, and you may need to tinker with the delay. Caveat: This will also affect typing on your keyboard. If you are a "hunt and peck" typist, the impact may not be too bad. If you are a touch typist, it can get really annoying, possibly more annoying than the remote button stutter.

Port Forwarding in Mythbuntu

My MythTV setup recently broke in an "interesting" way, and the fix I came up with is a bit involved ... so be warned, what follows is a major kludge.

Setup

Before explaining the pathology (and fix), I need to describe the setup. I have Mythbuntu installed on a PC whose only function is to serve as a digital video recorder (DVR). The PC connects to my home WiFi LAN, but the connection is occasionally unstable. I'm not sure if the problem lies with the USB WiFi modem, a driver, or some obscure setting.

Both the lone MythTV back end and the lone MythTV front end run on the PC, with the back end configured to use a static IP address. When watching recordings, I use MythMote on my (Android) phone as a remote control. MythMote connects to the back end via WiFi. Whatever the issue is with the WiFi connection on the PC, it has generally not affected MythMote.

Problem

I booted the machine one day and discovered that two recordings scheduled for the previous night had not occurred. Moreover, the front end was repeatedly telling me that the back end was off line ... even after I restarted the back end. Apparently the WiFi connection had flaked out (despite the network being up and the IP address being valid). With the MythTV box off line, the front end could not communicate with the back end, even though they're on the same machine.

Solution

A DVR that cannot be depended upon to record is not much of a DVR, so the top priority was to eliminate the reliance on the uncertain WiFi connection. I switched the IP address for the back end to the localhost address (127.0.0.1). As long as the PC manages to wake up in time, the back end should (hypothetically) start and record.

The one problem with this change is that it effectively disconnects MythMote. The answer to that is port-forwarding, which I implemented as follows:

1. Download and install the rinetd package from the Canonical repositories.
2. Edit the configuration file (/etc/rinetd.conf) to forward traffic on the static IP address to localhost. More specifically, I added the following forwarding rule (editing the file as root):
   
   

   192.168.1.68 6546 127.0.0.1 6546

   
   This forwards incoming traffic on port 6546 (the port used by the back end) at address 192.168.1.68 (the fixed IP address assigned to the MythTV machine in my LAN) to the same port on the local host address (where the back end is now listening).
3. The installer adds the rinet daemon to the set of programs that load automatically at boot. In my case, it showed up in /etc/rc1.d. Unfortunately, even though the daemon started, it failed to redirect MythMote traffic until it was restarted from a terminal. I suspect that it was loading before something else when it needed to load after that something else, though I have no idea what the something else was. My next step was to delete the line that automatically loads it at boot. On my box, this meant running
   
   

   sudo rm /etc/rc1.d/K20rinetd

   
   
4. I then created a two-line script to manually run the daemon:
   

   #!/bin/bash

   gksudo /etc/init.d/rinetd restart

   The specific name for the script (I used restart_rinetd.sh) and location are unimportant. I probably could have used the "start" command rather than the "restart" command, but this works (and maybe defends against the possibility that the daemon is already running but for some reason not connecting). I made the script executable with
   
   

   chmod +x restart_rinetd.sh

   
   
5. Finally, I set the script up to start whenever I log in. Starting from the Applications menu (the main menu in Mythbuntu), I navigated to Applications > Settings > Session and Startup > Applications Autostart, clicked the Add button, typed in a rather arbitrary name and description, and used the file chooser to locate and select my new script file. After that, it was OK, Close and restart the machine to test it.

Result

So far, at least, it works. When the machine boots up, I'm presented with a password input box. Whether I respond or not, the back end starts, so timed recordings should still work even if I'm not using the front end at recording time (and therefore not present to answer the password challenge). Once I supply my password (and sit through a small but harmless delay recognizing it), I'm into the front end, and MythMote is able to connect and function properly.

Update: That was stupid of me. The rinetd program can be executed by any user, not just root, so the use of gksudo (and ensuing password entry) was utterly pointless. I edited gksudo out of the script, and now startup works as it originally did: the back end and front end both start automatically, and I wind up in the front end without any intervention on my part.

Although I only have one front end (on the same machine), this should hypothetically allow someone to use the 127.0.0.1 address for the back end and still connect a remote front end, provided that they can figure out a way either to answer the password challenge or to get the script to run with root privileges without needing a password. One possibility (which I have not tested, since I don't have a remote front end) would be to have a script on the remote front end machine connect to the back end via ssh and start the daemon.

HDMI Audio in Mythbuntu

My adventure replacing my old Mythbuntu box with a new one continues. It's been working for a while now, in terms of waking when it should, recording and replaying shows. Yesterday's immediate concern was sound. The PC hooks to my TV via an HDMI cable. While both live TV and recordings viewed through MythTV worked fine (including sound), applications run outside MythTV (such as VLC) had no sound.

As usual, Google was both my friend and my enemy -- it found lots of results for all of my search queries, most of which sent me off chasing wild geese. For some reason, Application > Settings > Settings Manager in Mythbuntu does not provide anything to configure sound, and installing the unity-control-center package did not remedy that. (I wonder if they block it to prevent users from configuring something that conflicts with the MythTV audio settings, which you set when configuring the MythTV front end?) I ran alsamixer and unmuted S/PDIF, but that did not fix things.

I did notice at some point that the configuration for ALSA (the sound system) at the operating system level seemed to default to PulseAudio. I read somewhere that MythTV, which uses ALSA, might kill the PulseAudio service to avoid conflicts with ALSA. That suggested either creating a configuration file for ALSA that avoids PulseAudio or configuring PulseAudio properly. I tried the latter and it worked. The steps were:

1. Install the pavucontrol package from a repository.
2. Run pavucontrol in a terminal.
3. In the Configuration menu, choose the correct output device (in my case, "HDMI").
4. Exit, cross fingers, reboot and test.

The fix may not be perfect. It works -- both MythTV and the VLC player (run from the desktop) have sound -- but I now get system error messages when I exit MythTV, which I was not getting before. The error messages are not specific (something unnamed apparently crashed), and I haven't poked through the logs. So far, the errors have not coincided with an perceptible loss of functionality, so they're just an annoyance. I can't be positive they are due to the sound fix, but they started immediately after it.

Remotely Mounting a USB Drive

As I try to retire an old PC running Mythbuntu in favor of a new replacement, I continue to learn things about Linux ... with a gun to my head, as it were.

Without getting into the gory details, I can no longer work directly on the old PC -- I can't get a functioning display. I can, however, connect either by SSH terminal session or remote desktop. Once I get my recordings and database off the old box and onto the new one, I'm going to wipe the operating system, install something like Linux Mint, and then donate the old PC to anyone looking for a slightly noisy space heater.

The problem is moving the 300+ GB of stored recordings. I picked up a 1 TB Western Digital My Passport Ultra USB hard drive to use both for back and for file transfer. The trick was getting the bugger to mount without a direct connection. Using a remote desktop, I could see that Mythbuntu created a drive icon on my desktop, needing only to be mounted. Unfortunately, all that double-clicking the drive to open it, or right-clicking and selecting mount, got me was a message that I was lacking the authority to mount the drive. This is probably a consequence of remote connections having restricted permissions.

The answer proved to be mounting the drive (as root) from the command line -- once I found the key information on how to do so. It's actually quite painless when you know how. What follows was all done in a remote terminal. The first step was to run

sudo mkdir /media/passport 

to create a landing spot for the drive. (Feel free to substitute a different name for "passport".) Next, to get the particulars about the drive, I ran

sudo fdisk -l

(that's an "el", not a "1"), obtaining the following poop (omitting the parts about other drives):

Disk /dev/sdb: 1000.2 GB, 1000170586112 bytes
255 heads, 63 sectors/track, 121597 cylinders, total 1953458176 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x50dfffc7

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048  1953458175   976728064    7  HPFS/NTFS/exFAT

The key takeaways here, from the last line, are that the system sees the device as /dev/sdb1, and that it has an NTFS format (which I already knew from the packaging, which charitably assumes you're buying it for a Windows PC). Following the aforementioned directions, I ran

sudo mount -t ntsf-3g /dev/sdb1 /media/passport

and she was good to go. For FAT drives, refer to the instructions linked above.

Waking Up is Hard to Do

(Apologies to Neil Sedaka for the weak pun in the title.)

In the continuing war of man (me) against machine (my new Acer PC, which I'm configuring as a Mythbuntu PVR - see my last post), I've spent a full day trying to get the box to wake on a BIOS real-time clock alarm, so that MythTV can convince it to wake up when a recording is scheduled. The battle took so long because two things needed to be set correctly, and I kept getting stuck on incorrect combinations (this one right, that one wrong; vice versa; both wrong) while spending huge amounts of time searching the web and beating my head against the wall.

I copied a couple of time tested shell scripts from my previous Mythbuntu box, one that sets the BIOS alarm to an arbitrary time (used by MythTV to schedule actual recordings) and another that simply sets up an alarm for five minutes in the future (useful for testing). Before trying them out, I reviewed the official ACPI Wakeup wiki for MythTV. One of the first things it suggests is looking in the kernel log to make sure the BIOS supports ACPI wakeup (although I think pretty much all modern BIOSes do). In the log, I found the good news that the BIOS supports alarms up to one month in advance and this bit of seemingly bad news: "System wakeup disabled by ACPI".

I nonetheless followed the directions on the wiki for tweaking the shutdown script (under "Disable hwclock updates", although the tweak for Ubuntu does not so much disable them as reassert the alarm time after doing them). I ran the wake-in-5 test, and it failed.

Next, I got into the BIOS and checked the power settings. My BIOS has a "Deep Power Off Mode" (enabled by default) and a "Power on by RTC Alarm" feature (disabled by default). According to the BIOS help, the latter works only if you also disable the former. With "Deep Power Off Mode" disabled and "Power on by RTC Alarm" enabled, I was able to schedule a wakeup call for a fixed time either on a give day of every month (e.g., the 15th) or every day of the month. Neither is what I want -- I want to wake up only when there is something to record -- but at least I was able to confirm that the machine could wake on its own.

I'll skip a lot of gory details here, since they pertain to wasted effort. I was doing a lot of reboots during my experiments, and I noticed that one of the system logs was showing about five hours and change between reboots when actually they were minutes apart. Since I'm in the US Eastern time zone (GMT-5), I suspected that some confusion between local time and UTC (a five hour difference) was going on. Eventually I came to look in /etc/default/rcS, where I found the setting "UTC=no", telling the operating system that the BIOS was using local time. That seems to be the default setting, since my desktop PC has it as well. The BIOS on the Acer, however, was using UTC. I changed "no" to "yes", and I think that has fixed the five hour bumps. By itself, however, it did not fix the wakeup problem.

It turns out that having "Power on by RTC Alarm" not only schedules fixed wakeups I don't want, it also blocks the system from setting any other wakeup calls. This is covered in the "Fussy BIOS" section of the ACPI Wakeup document. So I went back into the BIOS, disabled "Power on by RTC Alarm" (but left "Deep Power Off Mode" also disabled), rebooted and ran the five minute wake-up test successfully.

The next step was to program the machine to wake and record a show ... which it did not do. So I went back, followed the directions for Configuring MythTV Automatic Wakeup and Shutdown (following directions -- what a concept!), and it seems to be working now.

Configuring wakeup/shutdown included setting up MythWelcome, which I had planned to do in any case. The directions are very clear and well-written, including explanations of one or two less obvious bits. There is one thing on the page that I find a bit confusing, though. In two different locations, the instructions call for you to exit MythWelcome by starting a terminal (F12 key) and then running a command to kill it. MythWelcome has a pop-up menu (accessed via the 'M' key), and one of the choices on that menu is to exit MythWelcome. It's both easier (much less typing) and a bit more natural/graceful, so I'm not sure why the instructions have you do it the hard way. In any case, I used the menu to exit, and things worked correctly.

Mythbuntu and USB WiFi

I'm in the (slow, painful) process of configuring a new PC to act as a video recorder. This post contains some notes on how I got it connected to my home WiFi network.

First, a note to self/strong suggestion to others: before screwing with anything that is likely to cause reboots, go into Applications > System > Mythbuntu Control Center > Startup behaviors and uncheck the box that starts the MythTV front end automatically at boot. Turn that back on only after all configuration agony is behind you. This is particularly important with the keyring nag (below), in which the front end started (and wiped out my access to the nag) before I could type the password, and then promptly froze the system.

The machine came with a flavor of Windows, but I immediately downloaded the latest version of Mythbuntu, burned the ISO file onto a DVD (using Brasero), and installed it on the PC, wiping away any vestige of Windows. I then rebooted and tried to configure Mythbuntu (but I'm pretty sure I will need to redo that later).

The PC comes with onboard Ethernet (one jack) but no WiFi. I will spare you the gory details (and myself the painful memories) of three failed attempts to add a USB WiFi adapter. Let's just say there were compatibility issues.

I finally ordered an Edimax EW-7811Un adapter. The Edimax is incredibly small, even more incredibly cheap (about a quarter the cost of some of the adapters I tried), and is advertised to be compatible with most Linux systems. With the power off, I plugged it into a USB slot and booted the new PC.

Oops. No network connection. Running lsusb in a terminal showed the Edimax device, but Settings > Network Connections showed two Ethernet connections and no WiFi connections. I don't think either of the "Ethernet" connections was the Edimax, but if it was, that was unhelpful, because my home LAN is secured (meaning the PC needs a password to get on it).

So I unplugged the Edimax. The Settings > Network Connections application still showed two Ethernet connections. I deleted both, not needing the onboard one and thinking the other was spurious. Big mistake. My external TV tuner is a Hauppauge WinTV-DCR, which MythTV mistakes for an HDHomeRun Prime (close enough). The first connection (which I eventually restored), eth0, was indeed the onboard Ethernet adapter. The second connection, eth1, was actually the Hauppauge tuner (even though it is coming in via a USB cable and not into an Ethernet jack). I wasted a lot of time unsuccessfully trying to install a channel lineup before it finally dawned on me that MythTV could not talk to the tuner because I had disconnected it. Fortunately, restoring the connection fixed that.

With the PC rebooted (and Settings > Network Connections showing no connections at all), I plugged in the Edimax. This time, the system immediately gave me a notification that a secured WiFi network was available. Back in Settings > Network Connections, I added a new connection, set it to WiFi, filled in my home LAN's SSID, set the security to "WPA & WPA2 Personal" and filled in the network password. Just like that, I had working WiFi.

To finish (hah! I should be so lucky) the job, I further edited the connection and made the IP address (obtained by running ifconfig in a terminal, and confirmed by looking at the status screen for my network modem) static, with mask 255.255.255.0 and gateway 192.168.1.254. I got those values by connecting my (Linux Mint) laptop to the WiFi network and running route -n in a terminal.

Next problem: on every reboot or log-in, I was nagged to type in a password to unlock the default keyring. (The correct password is my login password.) This was more than just annoying; it was fatal, as the front end would start without waiting for the password and then frequently freeze the system. Failure to unlock the keyring also seemed to keep the machine from gaining access to the WiFi network (at least I think that was the culprit). The solution I found was as follows:

1. Unlock the bleeping keyring so that I could connect to WiFi.
2. Install the "Passwords and Keys" application using the Ubuntu Software Center. (Seems to me this should be installed by default, even if the installation is purely a networked backend server.)
3. Go to Applications > Settings > Passwords and Keys, and right-click the Default keyring entry.
4. Select "Change password" and enter the current (login) password as the "old" password.
5. Leave the new password blank (horrors! -- a major security hole!) and finish.

After a restart, the bloody keyring nag was gone and the machine connected to my WiFi LAN.

After all this, I found that I could ping outside servers by IP address but not by name. My LAN uses a (now obsolete?) 2Wire wireless DSL modem. Turns out I had to go back to Settings > Network Connections, edit the WiFi connection, and enter the gateway address (192.168.1.254, same as before) in the field for DNS servers. With that, I finally had a useable WiFi connection (which has survived a few reboots).

Sadly, there is still a lot of configuring to do.

Mythbuntu: The Upgrade from Hell

I foolishly let Mythbuntu update to version 14.04 overnight a few days ago. The installer ran into problems (which I could not decipher) regarding updating the MythTV database. I let it upload two separate bug reports and did my best to soldier on. When the installation was finally over, the back end would not load, which means it was doing a pretty good impression of a (software) brick.

I got a message telling me that the database schema was several versions out of date, and instructing me to run either mythtv-setup or mythbackend in order to update the database. I tried both (from a console) and both failed (with mythtv-setup trying to start mythbackend). Eventually, I discovered the first (of multiple) problems.

Problem 1: Time zone data

Somewhere along the line I got a message that MySQL, the database program used by MythTV, was lacking time zone data. I followed some instructions I found, and fixed it by running the command

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -uroot -p mysql

supplying a password when prompted. After that, I was able to run mythtv-setup and mythfilldatabase. Apparently mythtv-setup automatically updated/fixed the database.

Problem 2: Security PIN

In mythtv-setup (general settings) I discovered that the security PIN was blank. According to the prompt, that will prevent any front end from connecting to the back end. Per the prompt, I changed it to 0000, allowing all front ends to connect. (I only have one, on the same machine as the back end, so that's fine.)

The IP address for the back end was correct, but since I have no remote front ends, I changed both the local and master addresses to 127.0.0.1. That was probably unnecessary, but I mention it just in case it had any unintended effect. [Update: In hindsight, I realized that might interfere with my using MythWeb to program recording schedules from other devices on my home LAN, so I switched both the local and master addresses back to the machine's static unrouteable IP on the local LAN, with no harm done.]

Problem 3: No Back End Service

Even after successfully running the setup program, the front end still could not connect to the back end .. because the back end was not running ... because it failed silently every time it was started. The good news was that I could start the back end manually (running mythbackend in a console), after which the front end could connect. It came as quite a relief to see that recordings, channel information and recording schedules had all survived the upgrade. Still, you can't do scheduled recordings very effectively is someone has to log in and start the back end manually each time.

Fortunately, I was able to get help from Thomas Mashos in the Mythbuntu Community on Google+. I could start the back end manually because my personal MythTV configuration file (~/.mythtv/config.xml) survived the upgrade intact. The system configuration file (/etc/mythtv/config.xml, also symlinked to /home/mythtv/.mythtv/config.xml) must have been replaced by what amounted to a placeholder. The host, user name and database name fields were empty; the password field was filled in incorrectly (or maybe that was the correct password for a null user access a null database on a null system?). I edited those four entries to match my config file and (woo-hoo!) the back end resumed playing nicely.

Problem 4: No Sound

Once the back end was running, I played back part of a saved recording to verify that things were working okay. The good news was that the video played fine. The bad news was that there was no audio. This turned out not to be limited to MythTV: I couldn't get the system to make sounds, period. (In contrast, the system had no trouble getting me to make sounds. Very, very aggravated sounds.)

I searched hither and yon on Google, and discovered that a nontrivial number of users have (or had) sound problems, many of them as a result of the upgrade to Mythbuntu 14.04. I've lost count of the number of options I tried, including purging the alsa-base, linux-sound-base, pulseaudio and pulseaudio-module-X11 packages (all at the same time), reinstalling them (I even deleted the archived copies and forced the package manager to download them again), and of course rebooting.

Eventually I stumbled on a fix (woo-hoo!). I had previously poked around in the ALSA mixer (by running alsamixer in a terminal) and unmuted the obvious suspects. I gave it one more try, disabling Auto-Mute Mode (because the last thing I want right now is something muting the sound again) and playing with settings I didn't understand. It turns out that unmuting both "S/PDIF" and "S/PDIF Default PCM" restored the sound. I have no idea what they stand for, let alone why they were muted. From aplay -L, I can see that they're associated with my NVidia graphics card (which also handles sound). So are eight bazillion other things, and I'm not sure why this one is special.

Problem 4.5: No Sound After Reboot

One might hope that unmuting the two settings above would be a permanent fix. Not quite. After a reboot, "S/PDIF Default PCM" remains unmuted but <sigh>"S/PDIF" finds itself muted again</sigh>.

In alsamixer (in a terminal), I unmuted both, then ran sudo alsactl store to store the correct settings and added alsactl restore to /etc/rc.local, which should hypothetically be run each time the system boots (but not, I believe, during reboots). The command works fine from a terminal, but after a full shutdown/start I find S/PDIF once again clobbered; so either /etc/rc.local is not running or, more likely, it restores the correct sound settings before the evil program that's muting S/PDIF gets executed.

Just for grins, after a reboot (and without restoring the ALSA settings, i.e., with a silent PC), I went into MythTV's audio setup menu. It showed a sizable number of options that all mentioned the correct NVidia card and matched what I saw when I ran aplay -L. The default choice produced no sound. I switched to a different setting (from "dmix" to "front", as I recall), ran the sound test and it worked. Unfortunately, while the setting survived a reboot, sound did not. So I tried again, switching to "ALSA:iec958:CARD=NVidia,DEV=0", and that setting works. It has survived three restarts, so I'm a cautiously optimistic that my long ordeal (most of two days chewed up fixing this) is finally over -- pending the next upgrade, of course.

Problem 5: [update] no MythWeb

After posting this, I discovered that MythWeb was not running. This turns out to be a known bug, due to a difference in the Apache versions used by Mythbuntu 14.04 and its predecessor. The fix specified in the bug report, which I repeat here, worked and MythWeb now runs as expected.

$ sudo rm /etc/apache2/
$ sudo dpkg-reconfigure mythweb
$ sudo /etc/init.d/apache2 start

Mythbuntu Remote Access Commands

My Mythbuntu box is accessible within the house via WiFi (using a nonrouteable address), and I sometimes like to program recordings remotely. For the most part, this is very straightforward using the MythWeb web interface. I just point a browser at the server ... usually. The MythWeb interface is both straightforward and rather comprehensive.

The only catch is that, while the browser can always find the MythWeb service, sometimes MythWeb cannot talk to the MythTV back end. I have no idea why the connection works some times and fails other times. Sorting that out is for another day. Fortunately, the problem is easily fixed using shell access, since SSH is enabled (by default, I believe).

For future reference (since I will forget them, probably within the next hour), here are the only commands I seem to need in the SSH shell. These may be somewhat specific to Mythbuntu, so anyone using a different version of MythTV be warned: Your Mileage May Vary.

• sudo service mythtv-backend [start | stop | restart] to start/stop/restart the back end (when it gives MythWeb the cold shoulder);
• sudo mythshutdown --shutdown to shut down the server remotely after I'm done playing with it.

Mything Channel Issue Resolved (?)

I just resolved an issue with my Mythbuntu/MythTV installation. At least I think I resolved it ... I'll post the details here in case it helps anyone else.

Symptoms

MythTV lets you watch TV directly, with the ability to pause shows (say, while you are either preparing a beverage for consumption or, ahem, recycling one already consumed). You can tune up and down with arrow keys on your remote and select a channel. MythTV superimposes on the screen information about each channel (id/call sign, current program, signal strength, ...) as you tune around. Tuning displays only channels known to the electronic program guide that you configured, in effect skipping channels you do not have ... usually ...

In my case, MythTV would let me scroll to channel 16 (which it labeled TBS) or 15 (WGNAMER), but when I selected either one the tuner would crash, taking me back to the MythTV front-end interface.

Setup

I get my TV via cable from Comcast, although I'm not sure that's entirely pertinent here. I subscribe to Schedules Direct (henceforth "SD") to get EPG data, which I feed both to MythTV and to Freeguide, running on a different PC, so that I can plan my week's viewing. SD lets me setup and edit multiple lineups, and it knows the Comcast lineup for my area. To reduce the amount of data downloaded each time I grab listings, I edited out (disabled) most of the available channels, since I pretty much never watch them, and certainly never record them. (If I do want to watch one, the Comcast cable box will still list it.)

Root Problem

I'm pretty sure that, at one time, WGN and TBS really were on channels 15 and 16 respectively, and I had them enabled (on my active channel list) at SD. Somewhere along the line I disabled them at SD, and somewhere along the line Comcast moved them to channels 95 and 66 respectively. Apparently, though, the old numbers somehow got "stuck" in the channel lists of both Freeguide and the built in channel "grabber" in MythTV. So when I logged into the SD web site to inspect my channel lineup, the correct channel numbers were listed (and marked as disabled), but when I looked in Freeguide or (gulp) tuned manually in MythTV, the old channel numbers were there.

Solution (?)

Reloading the EPG data did not good on either MythTV or Freeguide until I edited my SD lineup and re-enabled both WGNAMER and TBS. After doing that, I reloaded the listings in Freeguide (which now showed the correct channel numbers) and then reloaded the listings in MythTV. I'm not sure it was necessary, but just to be safe I opened a terminal on the Mythbuntu box and did the reload manually, running 'mythfilldatabase --do-channel-updates' to ensure that channel numbers, as well as program content, were updated. Then I went into the MythTV front end, selected 'Watch TV', and verified that the correct channel numbers were displayed.

Apparently it required an edit of the channel lineup at SD to get things unstuck.

MythTV: No More Midnight Confessions

With a tip of the hat to the late Rob Grill and The Grass Roots ... (video)

I previously reported finding my Mythbuntu PC, used strictly for recording TV shows, up and running occasionally when no recording was scheduled. Further investigation revealed that phantom wakeups always occurred at midnight UTC, and only when nothing was scheduled. (If a recording was scheduled later in the week, the PC would sleep through midnight UTC without problem.) I've finally identified (and fixed) the problem, and it has nothing to do with MythTV.

The BIOS (a somewhat dated Phoenix Award Workstation BIOS) contains a flag in the power settings labeled "Resume by Alarm", alongside entries "Date (of Month)" and "Time (of Day)". The "Resume by Alarm" setting was enabled, while the "Date (of Month)" and "Time (of Day)" settings were zeroed out. I don't recall enabling the "Resume by Alarm" setting, but the machine originally came with Windows Media Center (home version) installed, and it's possible WMC requires "Resume by Alarm" to be enabled.

The instructions for setting up ACPI wakeup in MythTV mention "fussy" BIOSes for which one might need to disable real-time clock (RTC) alarms in order to let MythTV wake the system. In my case, it was not necessary -- wake-up went fine -- and so I assumed, as it turns out incorrectly, that my BIOS is not "fussy". It also seemed to me (again, incorrectly) that in order to have the system wake from power-off when an alarm went off, one would need "Resume by Alarm" enabled.

The problem is that "Resume by Alarm" and the adjacent date and time features are designed for specifying a recurring alarm (e.g., wake at 8:27 AM on the 20th of each month, until the alarm is cleared) and (here's the kicker) "Date (of Month)" equal zero means not that there is not scheduled alarm but rather that the PC should wake at the specified "Time (of Day)" every day of the month. Since "Time (of Day)" was 00:00 and the BIOS uses UTC, this meant wake at midnight UTC every day, unless a different alarm (for an as yet unrecorded program) was set. When the last scheduled recording was done, the BIOS went back to wake-daily-at-midnight mode.

The fix was simply to disable "Resume by Alarm". Alarms set by MythTV still work, and now when nothing is scheduled, nothing happens.

Phantom Recordings Vaporized

As I mentioned in my previous post, a rather odd problem with network ports and IPv6 addressing broke my Mythbuntu installation. I've since confirmed that the fix I reported is working. At one point during the breakdown I tried to record an episode of the TV series "Perception" title "Kilimanjaro". When the recording failed, I rescheduled it ... once. That somehow led to approximately 1,100 entries for "Kilimanjaro" in the list of recorded shows, all with a size of either zero or one byte. Not only did that clutter the list, it significantly slowed  MythTV's display of the list, not to mention some other functions. The phantoms had to go.

I knew that MythTV stores all sorts of records in a MySQL database. A bit of searching turned up this post, which told me what I needed to know: that I could delete entries from the recorded table without breaking the database. So I installed MySQL Navigator, pointed it at the mythconverg database, and got to work. The database name, user id and password (along with host name and port) are all stored in ~/.mythv/config.xml. Once into the database, I ran

select * from recorded

to get the lay of the land, then

select count (*) from recorded

to get the total number of entries and 

select count (*) from recorded where subtitle = 'Kilimanjaro'

to get the number of phantom entries. The point of this was not just to satisfy my curiosity; I wanted to be sure that my next query would not delete everything. The third select helps me confirm that my "where" clause will do the right thing. (I tend to be cautious when deleting or updating database records.) Finally, it was time to do the deed:

delete from recorded where subtitle = 'Kilimanjaro'

nuked the phantom entries.

(As a quick sidebar, learning SQL, and specifically the MySQL version, has paid dividends for me over the years. For anyone doing operations research software development, whether personal or professional, and for anyone doing web development, it's a great investment of time.)

Deleting entries in the recorded table does not delete any actual recordings, and I wanted to be sure that there were no files associated with the phantoms. I also wanted to make sure that there were no live TV recordings sitting around. (The recorded table also showed a 10 second live recording from the day that I installed Mythbuntu and tested its functionality. That entry was another phantom, which I deleted.) So I went to check the directories where MythTV stores files. I started by looking in obvious places, to no avail. I then did a web search, which provided several widely differing answers, some specific to Mythbuntu and some generic for MythTV, and all of them wrong! So it was back to manual search. For the record, I found the files under /var/lib/mythtv (live recordings in the livetv directory, taped shows in the recordings directory).

Mythtery Solved?

Previously, I described a problem with my Mythbuntu installation that developed suddenly on August 24 (meaning that the system worked fine from installation this past May through August 23, then stopped working on the 24th). The symptom was a failure by the front end (and by the Mythwelcome application) to connect to the back end. It seemed possibly to have something to do with using IPv6 rather than IPv4, specifically on the wireless LAN connection. I won't repeat all the gory details but instead refer you to the previous post (if you care).

To understand both the problem and what appears to be the solution (knock on virtual wood), you have to know a bit about my setup. I have a PC dedicated to recording and replaying TV. The front and back ends of MythTV are both on that box. The box has three network connections:

• eth0 is a built-in (and unused) Ethernet port;
• eth1 is a Hauppauge WinTV-DCR external TV tuner, connected via USB; and
• wlan0 is a wireless network adapter, connecting the PC to my home WiFi network (I have DSL service with a DSL modem that also serves as gateway and WiFi router).

After wearing out Google trying to find solutions, I came across something that made me think that turning off both Ethernet ports would resolve the problem. I'm not sure why it would, given that error messages in the back end log typically referred to problems with wlan0, but I gave it a try. In a sense it worked: with both Ethernet ports disabled, the front end had no problem talking to the back end. Unfortunately, disabling eth1 meant that the back end could not see the tuner card, so it would dutifully wake the PC at the designated time and try to record a show, but fail miserably (and silently). Disabling just eth0 was not enough; the front end and back end were again not on speaking terms.

After more adventures with Google, including the discovery of a proposed workaround in this bug ticket, I found a combination of things that seems to have worked. On three successive reboots the front end has been able to converse with the back end, I have been able to schedule recordings, and the PC can see the tuner. I've yet to actually record something, but I'm cautiously optimistic.

I don't know if all the following steps are necessary, and I'm not going to experiment further unless the system breaks again. What I did was:

• disabled IPv6 as described in the bug ticket (which, from experience, was not sufficient in and of itself);
• assigned the wireless connection on the PC (wlan0) a static IP address within the range supported by my DSL modem;
• ran the back end setup program and changed the IP address of both local and master back ends (which are the same in my case) to that static IP address; and
• changed the IPv6 settings for both eth0 and eth1 from "automatic" to "ignore".

I have no problem with having to disable IPv6; it's not as if my home WiFi network is going to run short of addresses with IPv4. I don't know why the last step was necessary given the first step, but from experience it was. I don't know if the first step is necessary given the last step. Basically, my answer to any question about this (after being stripped of expletives) is "I don't know". I just hope the fix holds up.

That leaves me with one mildly annoying problem. During the period where the front and back ends were not communicating, MythTV failed to record a few scheduled programs. One of them appears in the list of recorded shows with a size of 1 byte. This by itself is not the issue. What's annoying is that it appears in the list 1,100 times! Or at least it did: I've gotten it down to a bit over 1,000 by manually deleting the entries one at a time. I'm hoping there's a clever and much more efficient way to get rid of the rest. Ordinarily I'd crank up the MySQL command client and run a delete query on the database, but the MythTV database has quite a few tables, I'm not sure what all I would have to delete, and I really don't want to mess up the database.

A MythTV Mythtery

... with apologies to the late Robert Asprin for stealing one of his puns.

My Mythbuntu installation abruptly decided, starting around August 24, to malfunction. The system is set up to boot straight into MythTV, meaning that the back end server starts automatically at boot, Mythwelcome starts automatically, and Mythwelcome in turn starts the front end automatically. The back end and front end are on the same box, with IPv4 address 127.0.0.1 and IPv6 address [::1]. The box is connected to my home wireless network (DHCP address). The PC also has an Ethernet card that is not connected to anything (and has not been since before I installed Mythbuntu).

Things worked fine for several months, but starting four days ago I observed the following symptoms after a boot:

• The front end generated an error message: "Could not connect to the master backend server. Is it running? Is the IP address set for it in mythtv-setup correct?"
• A Python script (sendProfile.py) would attempt to send a bug report and would itself crash with "Failed to connect to backend at 127.0.0.1:6543" (which should be the correct address).

The script crash message would only occur once, but the first message repeated every two seconds or one keystroke until I managed to fight my way out of the front end. Once I got into Mythwelcome, the same error would pop up with the same dogged determination until I exited Mythwelcome. If you've ever fought with a Microsoft system message that just won't let go, it's deja vu all over again.

I checked the back end configuration, and it was correct (127.0.0.1, [::1]). Interestingly, running through the configuration program would temporarily solve the problem (until the next boot) or break things totally. Success apparently occurred because the configuration program forces you to shut down the back end (which it restarts when you exit configuration). Failure occurred occasionally (but not always) because the initial shut down apparently did not succeed, and after I exited the configuration program I wound up with two separate mythbackend processes.

Anyway, for what it's worth, I discovered that if I exited the front end and killed the back end with sudo kill -9 <process id>, the back end would automatically restart, the front end would be able to connect to it, and all would be fine ... until the next boot.

Looking in the back end log file, I found that prior to the 24th there would be messages saying the backend was listening on TCP [::1]:6544 or TCP 127.0.0.1:6543, which was as it should be. From the 24th onward, the corresponding messages would mention TCP [fe80::218:37ff:f32b:100d%wlan0]:6544 (or 6543), with a failure message if it was after a reboot (success if it was after my kill -9 ministrations), or TCP [fe80::20d:feff:fe7e:455b%eth1]:6544 (or 6543) with apparent success, not that it did me any good. My best guess is that the change was prompted by my installing a system update, since I certainly did not touch any configuration files, or anything else, directly.

Solution? NO!

Various web searches turned up nothing useful, until I stumbled across a post from someone encountering a similar but different problem running MythTV on Windows. The cure for him was to disable his Ethernet adapter. So I changed the settings for the eth0 and eth1 interfaces on my system so that (a) they don't automatically try to connect and (b) users do not automatically have access. After a reboot, everything appeared to work. After a second reboot (I have a suspicious nature), it still worked. I'm tentatively declaring victory, but I hope someone fixes this (without breaking something else) in a future update.

Update: Boy, was that ever a mistake! Everything looked fine, until I recently discovered that nothing was recording. The PC woke on time, Mythwelcome showed the correct information for upcoming recordings, there were no error messages (until I looked in the logs) ... but when the time to record a show came, the backend experienced an error and the show went unrecorded. Midway through an afternoon of log parsing and repair attempts, I discovered that MythTV could no longer see my external tuner card (a Hauppauge WinTV-DCR that MythTV thinks is an HDHomeRun Prime). The tuner communicates via a nonrouteable local IP address, and even though it plugs into a USB port, it apparently counts as one of the Ethernet ports (probably eth1, but I'm not certain about that). When I set both interfaces to turn on manually and restricted them to root access, I guess I effectively disconnected the tuner card. Oops!

Update 2: I may have fixed it. Details are posted here.

Minor Device Mysteries

I have a couple of mildly annoying, though thankfully not crippling, issues with computing devices. Honestly, the fact that I cannot figure them out (the mental itch I cannot scratch) devils me more than the issues themselves. Interestingly, they may both turn out to be sleep disorders.

MythTV

I have a PC running Mythbuntu and dedicated to recording and playing back TV shows. I've written about it before (click "MythTV" in the label cloud, bottom right, if you're curious), including setting it up to wake from a G3 (unpowered) state to record shows or capture program database information. As I mentioned in an earlier post, neither of these works correctly. I find that I have to reload the database manually, and I occasionally find the PC waking for no apparent reason. The latter always seems to happen at 8:00 p.m. local time, which (I think not coincidentally) is 0000 GMT. I'm not positive, but I suspect it only happens when the MythTV front end is showing no scheduled recordings. Initially, I thought this was when MythTV was going to grab program data, but when the PC starts at 8:00 pm (and no recording is scheduled at that time), I check the MythTV front end, and it says that MythTV is idle (which the more detailed information provided by the back end confirms).

Instructions for setting the BIOS alarm clock (see the ACPI Wakeup document for MythTV) specify that the alarm should first be cleared, as the following line from the setwakeup.sh script illustrates:

echo 0 > /sys/class/rtc/rtc0/wakealarm      #this clears your alarm.

I'm left wondering if some script is writing a zero to wakealarm after the last scheduled recording takes place, and if this somehow translates into a (persistent) wakeup call for midnight UTC.

Update: I've fixed this; details are here.

Android

I have a Toshiba Thrive tablet, which by and large has served me well. For months after Android 4 ("Ice Cream Sandwich", also known as "ICS") came out, the Thrive stubbornly remained on Android 3 ("Honeycomb"). A week or so ago, Toshiba finally rolled out the update to ICS.

I'm not sure what all the hoopla about ICS was, but I suspect the improvements most important to me (if any) are under the hood. The user interface got new icons (woo-hoo) and a feature to unlock the device using facial recognition (except this did not make it into the Toshiba version). There's now rather usable handwriting recognition built in, but only on the Google search page in the Google browser (another woo-hoo). You can now close apps by swiping them out of the list of running apps, which is a nice feature.

I use an iGo Stowaway portable Bluetooth keyboard (no longer listed on iGo's web site, so I suspect it's been discontinued). It worked fine before the upgrade, but after I installed ICS I started running into problems where the Thrive would not recognize the fact that I was typing on the keyboard (but did tell me, in the Bluetooth settings, that it was seeing the Stowaway and treating it as an input device). Eventually I deleted and paired the Stowaway, and that seems to have reduced the frequency with which it is ignored ... but not eliminated the problem completely.

The more annoying issue, though, is battery life. Google "android ics battery life" and you quickly discover that a variety of people, on a variety of devices, are complaining that their battery life has decreased greatly since installing ICS. In my case, I'd guess that it is roughly halved, although that's a very subjective estimate. (Yes, I believe in the importance of analytics. No, I haven't bothered to track this, at least not yet.) Some people have issues with their screens not turning off, but that is not the problem on the Thrive. The power indicator should blink when the Thrive is in sleep mode, and with Gingerbread and then Honeycomb it did so consistently. With ICS, sometimes it does, sometimes it does not (meaning the power light stays on, even though the screen does go dark). Either way, a surprising amount of the charge drains when the device is sleeping (about 25% over ten hours). So I have to be diligent to recharge early and often.

I just checked the battery settings. (This is another plus for ICS: it give more detailed information about the battery. Now if I could only find out how to interpret it ...) The Thrive had been on battery for 16:44 (all times here are hours:minutes -- ICS gives seconds as well, but that's rounding error to me). It was down to 72% of full charge, so 28% bled off while it was sleeping. According to the battery info, Android OS accounted for 75% of battery use. Drill down, and then turns into 1:26 for "CPU total" and 5:44 for "Keep awake".

Now I have the device in airplane mode when it sleeps, so the WiFi and Bluetooth should both be off. Why the "keep awake"? Is this because I have antivirus (Avast, which I happily endorse) installed? Is it because I did not shut down all possible apps before sleeping it? Do Google Reader or the Google Play Store try to keep the device awake when there is no Internet connection and it's supposed to be sleeping?

I guess I'll have to try to remember to clean out all running apps before I put it to sleep tonight, and see if that affects battery life.

Update: Apparently running apps are not the culprits. I shut down everything I could last night (antivirus, for one, being excluded) and let the Thrive sleep. After 15.5 hours on battery, 26% of the charge drained. Battery use by Android once again dwarfed use by anything else, and the ratio of keep-awake time to CPU cycles was 4.5:1.

MythTV Wakeup

My MythTV installation remains a work in progress, but it is coming along. (For other installments in this saga, click "MythTV" in the label cloud at the bottom right of this or any post.) One source of confusion has been the wake-up feature, which I think I've got partially licked.

Instructions for configuring MythTV to wake the PC when a recording is scheduled can be found several places, including here. Following a similar but slightly different set of instructions (whose location I've since forgotten), I tested my BIOS, created the setwakeup.sh script and tested that, configured both the back end and mythwelcome, and then scheduled some test recordings.  The setwakeup.sh script worked fine when run (with administrator privileges) from a command prompt, but I found that the PC woke up at times it was not supposed to, and failed to wake up when recordings were scheduled.

Long story short, the key was in the mythwelcome setup (accessed from a terminal via mythwelcome --setup).  There is a field labeled nvram-wakeup Restart Command, and for some reason it was populated by default.  The instructions on the MythTV wiki state that this must be blank, and they're not kidding.  Clearing this field at least partially fixed the wake up issues.  MythTV now wakes the PC (from an S5 state, i.e., powered off) via a BIOS alarm and successfully handles scheduled recordings.

Two wakeup issues remain:

• I find the PC booted and running at times when nothing is scheduled (and I have no indication why it powered up); and
• the back end is supposed to wake the machine between 0200 and 0500 local time to download program listings, but that appears not to be happening, at least not regularly.

Update: I fixed the first problem (unscheduled boots). Details are posted here.

MythTV and the Phantom Soundtrack

I previously reported that, having installed Mythbuntu 12.04 and a Hauppauge WinTV-DCR 2650 (and with Comcast as my cable provider), I was getting a spurious soundtrack on one channel (ABC).  When I tested the setup by watching live TV through it, ABC was showing "Spiderman 3", and I was hearing the dialog in Spanish.  It turns out that was the only time I heard Spanish.  Thereafter, whenever I tuned to channel 3 (ABC), the audio was an FM station continuously broadcasting the local weather (?!).  All other stations had the expected audio track.

After considerable poking around, I still don't know why I'm hearing the weather station (or why it was the Spanish dub of Spidey 3 that one time), but I have identified a pattern and a workaround.  It turns out that a random sampling of the stations I tune in (which form a proper subset of the stations available through my Comcast subscription -- my channel list excludes stations I never watch) put them into four categories:

1. some have a single audio track;
2. some have two audio tracks, with no sound on the second track;
3. some have two audio tracks with the same contents on both tracks (at least same to my ears -- if one is higher quality than the other, I'm not detecting it); and
4. ABC (only) has two audio tracks with that weather station on the second track (except, apparently, when it's something else).

In all cases the first audio track has the correct (for me) contents.  Apparently MythTV defaults to the highest numbered track (which is fine for cases 1 and 3) but is smart enough to avoid an empty track when it sees one (so no problem with case 2), which just leaves me with the single instance of case 4.  I don't know if a given station always falls into the same category, or whether in cases 2 and/or 3 the contents of the second track change if, for instance, a movie that has been dubbed into another language is showing.  (Anyone know if any of the "Star Trek" franchise movies have been dubbed into Klingon?)

The pop-up menu (triggered by the 'M' key on the keyboard or the 'Menu' button on the remote) has a submenu to control audio during playback, and for ABC I can use that to switch to the first track.  It's a mild annoyance, but nothing serious.  Searching online yielded other concerns about MythTV defaulting to the highest numbered track, but no solutions other than manually switching.  So for now, at least, I will just have to live with switching audio tracks whenever I replay a recording of an ABC show.

Installing Mythbuntu with WinTV-DCR

A few years back, I bought a tower PC with Windows Vista Media Center (home version) and a tuner card built in.  I've used it almost exclusively as a personal video recorder. For a variety of reasons, Vista has increasingly gotten on my nerves, so I finally bit the bullet and replaced it with MythTV.  The process has taken much longer than I expected, partly due to dopiness on my part, partly due to sketchy instructions here and there (or presumptions that I know things I do not). Herein I chronicle some of the details in case they'll help anyone else. It will be a long post, as it was a long process.

I should note a few more things about my equipment before diving in. I am a Comcast cable customer. I run the incoming cable through a splitter, with one connection to the TV (flat-screen HD) through a set-top cable box and the other to the tuner card in the PC. The PC has an NVidia graphics card (the precise model is, I think, irrelevant) that connects to the TV via an HDMI cable.

The tuner in the PC can only capture analog channels (NTSC), and Comcast is moving more and more channels to digital. So part of the motivation of trying out MythTV was that I needed to install a new tuner in any case. After a little online shopping, I settled on a Hauppauge WinTV-DCR (model 2650), a dual-tuner CableCARD receiver that connects to the PC via USB. The 2650 is not explicitly recognized by MythTV, but according to multiple success stories by other people, you can falsely identify it as an HDHomeRun Prime and it will work fine with MythTV.

As I've mentioned more than once, I run Linux Mint on various PCs and laptops, so I initially thought about installing Mint on my PVR machine and then adding MythTV. A couple of things I read online about complications, coupled with the  discouraging thought of downloading a potentially large number of dependent packages via my slow DSL line, caused me instead to download Mythbuntu 12.04 (at the office, where speeds are much greater) and burn an ISO image to a DVD. Mythbuntu is basically Ubuntu with things deemed inessential to a media server stripped out and MythTV added.

My initial thinking was to run Mythbuntu from the DVD, give it a test drive, then install it alongside Vista long enough to confirm that I liked it and to move my existing recordings over. Fortuitously, I took the precaution of copying almost all the recordings to an external hard drive before beginning the experiment. (The "almost" refers to one two-hour recording, approximately 5.3 GB, which could not be copied to the external drive. The issue was not lack of space; apparently the file was too large for the file system -- which might be FAT; I can't recall -- on the drive.)

Like other Ubuntu-based distributions, including Mint, you can boot from the CD or DVD, try out the system, and optionally install it. The test drive is useful to determine whether Mythbuntu correctly identifies and has drivers for your keyboard, mouse, display, network connections etc. In my case, this all worked fine, including installation of the NVidia proprietary drivers. For what it's worth, my keyboard and mouse are wireless, through a hub connect by USB. There was no problem with either of them.

I expected also to test MythTV itself, but as it turns out that cannot be done booting from the DVD. MythTV is a client-server system, so it comes with two parts, a front-end (client) and a back-end (server). You can test MythTV's front-end with a preexisting back-end, but if (like me) this is your first foray into MythTV, you will not have a back-end installed. No back-end, not test.

There was nothing for it but to install Mythbuntu. Mythbuntu initially gave me a screen with three choices, the first being to install alongside Vista. I chose that and took the default choice for disk partitioning. Shortly thereafter, Mythbuntu informed me that one of the partitions (it was not clear which; possibly the swap partition) was too small at the size it had selected itself and that I should back up and make it bigger. So I backed up and got what looked like the "how do you want me to install it" dialog again. Apparently I paid insufficient attention when I clicked the top choice, because this time the top choice was to wipe the old system and install just Mythbuntu. When I realized what it was doing (almost immediately) I ejected the DVD (the only way I could find to stop it), then reinserted the DVD and tried to restart the installation ... only to be told that the hard drive now had no system on it. To paraphrase Captain Keith Mallory, my "bystanding days" were over and I was "in it now up to [my] neck". A full install was on.

Thereafter, installation of Mythbuntu was quick and painless. There were 89 MB of updates awaiting me, which I deferred while I worked on the TV part. Physical connection of the WinTV was trivial (power cord, USB to the PC, attach the cable, insert the CableCARD).  The installation screen lets you select an IR remote if you have one. I do, left over from Media Center, and selecting the standard Media Center remote worked ... for a while ... more about that below. The WinTV comes with its own remote, but I thought it would be easier to stick to the MCE remote (to which I'm used) rather than figure out how to get the WinTV remote to work.

For the video device, I selected the NVidia driver. There were a couple of drop down boxes to configure "TV-Out". I wasn't sure whether that was necessary, but I figured probably not; the prompt starts "If you would like to configure TV-Out". So I stuck with the default settings, which seems to have worked.

MythTV itself started, and suddenly the mouse was gone.  My first thought was "how the heck do I navigate", but the keyboard arrow and tab keys worked fine. I later discovered this is a design feature, not a bug. When you are in a MythTV window, there is no mouse cursor. MythTV expects you to navigate via the remote. I wish I'd seen that somewhere before I launched into the installation, but no harm done. The remote worked fine to advance, retreat, select and cancel. At least it worked for a while (more to come).

In the video setup menu, I clicked the hi-def test button. It downloaded a 70+MB HD movie clip and played it successfully in the TV ... other than a lack of sound. The setup wizard theoretically allowed me to configure sound. I chose ALSA, but no joy. So I tried various other ALSA settings in the list (specifically those that mentioned NVidia), along with clicking the rescan button, and had no luck.

After a bit of searching, I exited MythTV, opened a terminal, and ran aplay -L, which showed me default:NVidia as a recognized sound device. That's what I'd hoped for, so I ran sound-test -Ddefault:NVidia -c 2 -t sine and heard tones in both of the TV's built-in speakers. (Sidebar: without the -t sine argument, you get "pink noise", which to me sounds like a bad connection.)

I then went back to the sound configuration screen in the front-end, and lo and behold the choice had changed, on its own, to ALSA:dmix:CARD=NVidia, DEV=0, and sound was working in MythTV. Maybe I forgot to try that one, or maybe my tests in the terminal somehow made the device more visible (?).

To configure the video source, I followed these instructions with minimal difficulty. I've had an account with Schedules Direct for a while, so my channel lineup was already configured. The one hiccup was that clicking Fetch channels from listing source repeatedly failed to do anything, until I realized that the CableCARD was not firmly seated in the receiver slot. (Paul slaps himself a few times.)

Pairing the device required a call to Comcast, in which I needed to give them three pieces of data: the card's serial number; a host ID, and a device (data) ID. The serial number was on the receipt I got from Comcast, but where to get the other two things? The back-end settings have a menu for Capture Card, in which I selected HDHomeRun Prime for each of the two tuners, and was given addresses for them and an IP address (on my home network, so a nonroutable address). This turns out not to be what Comcast wants. When you install the WinTV in Windows 7, the information is magically provided to you, but where would I find it in Mythbuntu? After a bit of searching, I indirectly stumbled on the answer. That IP address in the Capture Card screen was for a web server built into the WinTV. I opened that in a browser and it handed me the necessary information, including the serial number, on a silver platter. I called Comcast and in fairly short order had the card authorized (although they warned me it could take 45 minutes for the card to download all the channel information it needed).

Somewhere in the middle of this process I turned off the PC and went out to dinner. When I returned and booted the PC, the IR remote no longer worked! That's happened a second time as well. When I first observed this, I wasted considerable time searching for the source of the problem, playing with various remotes, and looking in the wrong places for where I could reconfigure it. (System > Control Center > Infrared is where I select the remote.) The lsusb command, run in a terminal, failed to show the remote being attached. As it turns out, unplugging the receiver's USB cable and then plugging it back in fixes the problem. I think I ran across some tweaks one can make in system files to eliminate the need to do that, and I will definitely research that tomorrow. I can't picture having to reseat the remote cable every time I wake the computer.

I have not yet tried to record anything, nor to import my Windows recordings, so there will probably be a follow-up post. Meanwhile, there are two pressing issues. One is fixing that bug with the IR remote. The other is to figure out why the first channel in my cable lineup (which happens to be ABC) is showing programming dubbed in Spanish (?!). All the other channels coming through the WinTV tuner are in English, and the one that is dubbed when viewed through the tuner is in English when viewed through the cable box.