Incorrect Program Listings in MythTV

I've been using MythTV as a personal video recorder (PVR) since 2012, and for the most part I have been quite satisfied ... but there have definitely been adventures. You can type Mythbuntu or MythTV in the blog search box to see a litany of posts about things that did not work as expected (or at all) (or threatened to implode the universe) and fixes I found. Today's post is a two part adventure regarding program listings.

I have an account with Schedules Direct, which lets me download XML files containing program listings for my cable provider. I access it from two different machines. On my main PC, I have FreeGuide, an open-source TV guide program, installed. Once a week I download the latest listings and use FreeGuide to decide what I want to record during the coming week. On the PC that acts as my PVR, I have MythTV set up to download the same files from Schedules Direct when I tell it to refill the program database, which I again do once a week when programming that week's recordings.

The first part of today's adventure has been going on for a long time. When programming the week's recording schedule, I would occasionally run into discrepancies between the two machines. That is, in certain time slots FreeGuide would report one program and the listings on the PVR would report a different program, even though both were working from identical downloaded data files. When this happened, the listings in FreeGuide were invariably correct and the listings on the PVR incorrect. The obvious workaround was to use the FreeGuide listings, but that meant that when I wanted to record a program that FreeGuide said was there and the PVR said was not, I had to set up a manual recording rule, which is doable but somewhat inconvenient.

Eventually I figured out what was going on (probably with the help of considerable googling). I download 14 days of listings at a time from Schedules Direct, on both machines. Since I do this weekly, there is a one week overlap between the previously downloaded data and the newly downloaded data. FreeGuide replaces the old listings with the fresh download, but apparently MythTV only downloads the second week of data to its database and ignores the first week of the new download. The discrepancies occurred when the contents of a time slot in the overlap week changed between downloads. FreeGuide went with the newer data, but MythTV went with the older (incorrect) data.

I confirmed this by setting up a two line script on the PVR to let me download schedule data manually and overwrite the old data. The script is:

#!/bin/sh
mythfilldatabase --dd-grab-all

Note the option -dd-grab-all, which signals that all 14 days are to be downloaded and added to the database, updating any existing data. Running this from a terminal eliminated the inconsistencies between machines.

This brings me to the second part of today's adventure. I normally update the listings on the PVR machine by choosing the menu option to grab EPG (electronic program guide) data from the MythWelcome user interface. That was set up, back when I first installed MythTV, to run mythfilldatabase without any optional settings. I wanted to update that setting to add the -dd-grab-all option. The problem was, I could not find where to make the change. I did some googling (of course), and every post I found led to the same solution posted in the MythTV wiki: run mythtv-setup; go to the "General" section, and within that to the "Program Schedule Downloading Options" section; then use the second of the six settings there ("Guide Data Program") to set up the program or script to download the guide data. That sounds simple enough, but when I run mythtv-setup and go to that section only the first entry (the toggle for automatically updating listings) is present. The other five are nowhere to be found. I'm pretty sure they were there when I first installed MythTV, but they do not show up when I run the setup program on a machine that has already been configured. Possibly I need to run setup as a different user (the MythTV account "owner"?).

Anyway, I found a simple solution. The PVR machine runs MythWeb, a web interface to MythTV. I use MythWeb to program recordings from my main PC. It also has the ability to access settings (by clicking the button whose icon shows a key and a wrench). In the settings editor, I picked the button labeled "MythTV" and did some serious scrolling. Fortunately the settings are in alphabetic order. The one labeled "MythFillDatabasePath" has the path to the mythfilldatabase program. I added the --dd-grab-all option there, clicked the "Save" button at the bottom of the page, and that (hopefully) fixes the problem. Time will tell.

Further Adventures with MythTV

I've documented various travails getting MythTV (specifically, via the Mythbuntu Linux distribution) to behave as expected and play well with my hardware. (If you want to see them, you can click the MythTV link in the tag cloud on the lower right, or use the search box.) Unfortunately, I've been stuck on an old version, unable to upgrade safely, for a while. The problem was likely the BIOS. Assorted kernel updates made waking up to record shows dicey at best, so I froze the machine on a now rather dated kernel ... when meant sticking to a rather dated version of Mythbuntu as well.

I finally got around to buying a new PC (HP Pavilion) to be my PVR. In the meantime, development of Mythbuntu has apparently ceased, so I decided to install Linux Mint (the same operating system I have on my desktop and laptop) and then install MythTV on top of that. What I thought would be an afternoon's work stretched out over four days or so, due to a combination of BIOS adventures (starting with disabling "SecureBoot" and convincing the BIOS to let me boot from the DVD drive ... which I somehow had to do twice) and my natural ineptitude. I mistakenly thought that having a working MythTV installation on the old machine, from which I could copy various settings and scripts, would make installation smooth sailing. Going into the process, my expectation was that moving the backend database from the old machine to the new one would be the sticking point. It turned out that was the one step that went (fairly) smoothly.

In this post, I'll document a couple of issues and how I sorted them out.

First issue: No sound

Watching TV is considerably less fun when you have no sound. Both the old machine and the new one were/are connected to my TV via an HDMI cable, and after a bit of fuss sound worked on the old machine. I have no idea why the new machine put up  more of a fight, but I suspect it has something to do with using Mythbuntu versus Mint and which sound components each installs by default.

At any event, I found a couple of blog posts that, between them, got me over the hump:

• Fix No Sound (Dummy Output) Issue In Ubuntu With SND HDA Intel

• No sound on Mythbuntu/optiplex frontend SOLVED

I have an old post of my own relating to the same problem (HDMI Audio in Mythbuntu), but the symptoms on the Mythbuntu box were a bit different, so I'm not sure how helpful it would be on Mint (or any other distribution).

Second issue: Being bugged for a password

I swear that this never happened on Mythbuntu, so it surprised me when it happened on Mint. On both machines, I use the MythWelcome program as the gateway to the front end, and the Mythshutdown application to set wake-up times for scheduled recordings and shut the machine down (either automatically when idle for a specified time, or manually by clicking the shut down button in MythWelcome). On the new machine, shutting down from the MythWelcome menu resulted in a prompt for the root password. Back end use of mythwelcome did not produce a visible password request, but also did not work as expected. I suspect it might have been trying to ask for a root password in a non-graphical context (nowhere to display the password prompt). On the old machine, it just worked with no intervention on my part.

It turns out I was missing a file. The MythTV installation process on both machines created a "mythtv" user group and added my account to it. What was missing was an addition to the sudoers file -- or, more precisely, a file parked in the /etc/sudoers.d directory, which is automatically appended to the sudoers file at startup. The file needs to be installed as root. Apparently Mythbuntu did that automatically, whereas the MythTV installer did not (and did not prompt me to do so).

The file's name is just "mythtv" (which I don't think is significant -- any file name should work). It is a plain text file, containing the following single line:

%mythtv ALL = NOPASSWD: /sbin/shutdown, /bin/sh, /usr/bin/setwakeup.sh, /usr/bin/mythshutdown, /sbin/poweroff, /sbin/reboot

The first bit ("%mythtv" -- don't forget the percent sign) says that what follows applies to anyone in the "mythtv" user group. The rest identifies six programs that get to run as root without requiring a password to be entered. Note that it includes the "setwakeup" script (which sets the wake-up time for a specified interval ahead of the next scheduled recording) and various commands relating to shutting down or rebooting the system. I'm a bit surprised to see /bin/sh in there, which apparently lets the mythtv group run any shell script that requires elevated privileges. That said, I'm not going to screw with it. If it ain't broke, don't fix it!

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 versus Media Center

I'm still getting the hang of MythTV, but I think I have enough experience to make a reasonably informed comparison to Windows Media Center (WMC), which I used for years. A quick but important disclaimer is that, while I used the same hardware with both systems (other than an upgraded tuner that plays no role in the comparison), MythTV runs on the latest version of Mythbuntu whereas WMC ran on Windows Vista. I would expect the latest WMC, running on Windows 7, to be more stable and possibly have an improved feature set.

Where WMC has the edge

 

• Setup is much easier than with MythTV. I've documented some of my experiences setting up MythTV in other posts (click "MythTV" in the tag cloud, lower right, to find them). Familiarity with Linux (preferably Ubuntu), good skills using Google and nerves of steel are pretty much requirements (as might be the patience of Job). In contrast, with WMC you tell Windows whether you're using an antenna, cable or whatever, identify your signal provider, and you're off to the races.
• Data for the television guide seemed to download and install more rapidly (although this is a rather subject perception measure, and the guide source was different).
• The guide is free (or prepaid, if you prefer to look at it as bundled into the cost of the software). With MythTV, I pay a modest annual fee for guide data.  (This is actually not an issue for me, since I was buying that data even when I used WMC, for reasons I'll articulate below.)
• The automatic download of guide data may be a bit more reliable than with MythTV (where I've already seen one instance in which the scheduled replenishment of guide data failed silently).

Where MythTV has the edge

• MythTV records shows in a reasonably standard format (MPEG-4, or something quite close to it). That means the recordings can be played by other software and can be transcoded. WMC, on the other hand, uses a rather nonstandard format (DVR-MS). Web searches suggest that it is possible to transcode them, but my first two tries ended in failure. Since VideoLAN's VLC player can play them, and since I have no interest in retaining the recordings once I've watched them, I gave up trying to transcode my accumulated DVR-MS files.
• MythTV can wake the PC from a  G3 powered off state to record programs (assuming, of course, that the PC remains plugged into a live outlet). WMC, to the best of my knowledge, could only wake the PC from an S3 standby (sleep) state. I use the PC in question solely for recording and viewing television. Not having to leave it in sleep mode saves power, but perhaps more importantly it insulates me against power failures while I'm away on a trip. With WMC, if power happened to fail while I was away, the PC remained off once power was restored, and WMC could not wake it to record shows.
• I can schedule recordings by looking up the name of the show or by jumping to a date and time in the guide. WMC required me to open the guide (to the current date/time) and then scroll to the date and time of the show I wanted to recorded. I found it surpassingly strange that it had no option (or at least none I could find) to jump to a specific date/time.
• I can control how many days the guide contains. WMC downloaded however much data it wanted to download. In a few instances, when planning for a trip, I had to wait until the last minute to program recordings because dates late in the trip had not yet materialized in the guide. Although it never happened to me (that I recall), presumably on a long enough trip one would be barred from scheduling some recordings. (This "feature" is why I was already subscribed to the guide data that I ended up using in MythTV.)
• I have yet to see an analog to the Black Screen of Obfuscation (BSoO).

Regarding the last point, the BSoO was apparently a relative of the Blue Screen of Death (BSoD). This may be a Vista-specific "feature". Occasionally, when I opened WMC, I would encounter an utterly featureless black screen (maximized). Blindly clicking in the upper right corner would kill WMC, so the screen was actually alive and populated; it was just not painting. "Flipping" also worked (that's alt-tab task switching, not flipping the bird -- although I certainly tried the latter more than once). The truly annoying part, though, was that if you killed WMC during a BSoO and then restarted it, you were guaranteed to get another BSoO. This was also true if you killed it using the task manager. Once you saw a BSoO, your only remedy was to reboot the PC -- which could be rather inconvenient if you were trying to record live TV (particularly as Vista set no speed records for rebooting).

I think it was the BSoO that finally convinced me to brave MythTV. So far, so good with that change.

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.

Android Remote Control for VLC

This is part of my continuing adventure setting up MythTV at home. (You can find related posts by clicking the MythTV label in the tag cloud on the lower right portion of the page.)  Having set up MythTV, I copied over backups I'd made of my Windows Media Center recordings.  It turns out that they are recorded in a somewhat proprietary format (.dvr-ms file extension).  I'm sure you are as shocked as I am that Microsoft would deviate from the file format standards adopted by, oh, the rest of the world.  At any rate, it is theoretically possible to transcode those files into something like MPEG format, but after one failed attempt I decided not to bother.  These are TV shows I intend to watch once and then delete, and VideoLAN's VLC player, which is available and multiple platforms and a standard part of many (most?) Linux distributions, handles .dvr-ms files nicely.

I've used VLC (frequently) on PCs, but always when I was sitting at the keyboard watching a (typically short) video.  Watching a TV show means sitting at a distance from my TV (and keyboard), so I needed a way to control VLC from a distance.  (It was either that or watch the commercials.)  Enter Remote for VLC, a free VLC remote control app by Peter Baldwin, available for Android devices (such as my Toshiba Thrive tablet) from Google Play (formerly known as the Android store).  There are several VLC remote control apps on Google Play, but this one has one of the highest customer satisfaction ratings, has a very well done interface, and is free.

I have a Wi-Fi network in my house, including the computer running MythTV and VLC, and of course including the tablet.  My version of VLC is "2.0.1 Twoflower".  There are setup instructions for the app online, and I found general instructions for enabling VLC's web interface several places, but not of them exactly matched my setup, so I though I would post my steps here in case they might help someone else.

First, you have to enable the built-in web interface to VLC.  In VLC, click Tools > Preferences, and at the bottom left set Show settings to All.  Expand Interface and select Main interfaces.  Put a check next to Web.  (This is the first place where I had to deviate -- slightly -- from posted help, which mentioned "http".)  Now exit VLC.

Find VLC's .hosts file and open it in your favorite editor.  On my Mythbuntu box, the path is /usr/share/vlc/lua/http/.hosts.  On the PC I'm using right now (Linux Mint), the path is /etc/vlc/http/.hosts, but both /usr/share/vlc/lua/http/.hosts and /usr/share/vlc/http/.hosts symlink to it.  So you may have to do a little detective work, bearing in mind that file names that start with a period are hidden by default (so use ls -a, click ctrl-H in Nautilus, or do whatever is analogous in your file manager of choice).

The troubleshooting instructions say, somewhat vaguely, that you should edit this file after you find it.  Specifically, you need to enable whatever address or range of addresses will be used by your remote control device.  My Wi-Fi network uses non-routable addresses in the 192.168.whatever.whatever range.  So I found the line containing the mask 192.168.0.0/16 and uncommented it by removing the initial hash (#) character, then saved the file.  The file contains masks for all standard private network ranges, so you just need to know what range covers the address your device will be using.  If you will be using a device that is not on the same network as the PC running VLC, you will need to add a line enabling the specific address of the remote device (and make sure the device can communicate with the PC, i.e., that you don't have a firewall that will block the remote device).

Once you have saved the modified .hosts file, start VLC.  (VLC needs to be running so that the remote device can see the built-in web service.)  Make sure your Android device is connected to the network, and start Remote for VLC.  It will scan for VLC servers and, hopefully, find yours and add it to its internal list.  You can tap the menu button in the upper right and select Settings to verify that it is connected and see whether it found your VLC server.

With that, you should be good to go. Have fun exploring the controls.