It's a stiff

It appears to be dead. For some reason, the box has turned off, and it won't turn on anymore. With power connected, the network interface card's lights are on (and, when I disconnect power, the NIC's lights go out), but the power button does not power up the machine. I opened up the machine and checked the connections, and everything appears to be in order, but it just won't power on.

And I never did figure out how to get the IR remote working...

Out of space! Out of space! Out of...

The box died a couple weeks ago, just completely stopped responding. I rebooted the thing and managed to pull up the MythWeb site and checked its status, and it was reading 0 bytes free. Well, that might have something to do with it. I shelled into it (since the web site again stopped responding), and I found an older video file and just deleted the thing, along with its "pretty" link. That should do, right? At least, it should get the box up and running again to check on the schedules and see what's filling up the drive, maybe set a few things to auto-expire that weren't before.

Except it didn't work. It was still unresponsive. Why? Shelled back into it and ran the df command. There was some space on the /myth partition, so that was fine, but... the ROOT partition was full as well! What?

I solicited some help in getting a command to find what directory is hogging my disk space. (I could do this in Windows with WinDirStat. Heck, I could do this on this box with KDirStat, except I wanted to do this from the comfort of my laptop shelled remotely with a text terminal instead of standing in front of my TV.) The command du -sk * | sort -nr | head gave me the top 10 directories, and by progressively drilling into each one, I was able to track down the offender to /var/log/mythtv, whose most recent log file was over two gigabytes.

For kicks and giggles, I took a peek at the file. It was a couple gigs' worth of:

<date & time> TFW, Error: safe_write(): File I/O errcnt: 1
eno: No space left on device (28)
<date & time> TFW: safe_write(): funky usleep

So, apparently, /myth ran out of space, and in response, mythtv filled up the log on root complaining about it until that ran out of space, too.

Well, now all schedules are set to auto-expire, so hopefully that will help to alleviate the problem with disk space filling up. At least, unless and until I get a larger hard drive for the thing.

Remote control... maybe?

I was going through some old bookmarks and I saw some I made for my PVR project. I thought I'd browse for an update to the issue with the picoLCD module receiving IR signals but not sending them to Myth, which I first mention here. Essentially, there is a Linux package that is built for receiving and processing IR control codes, but because the lcdproc daemon doesn't know what to do with them (it's an LCD panel driver after all), the codes just don't go anywhere.

Well, there is some good news. Someone with a lot more smarts about this has been working on the solution, patching lcdproc to hand off the IR codes from a picoLCD module to a daemon that is written for IR codes, LIRC. This could make my MythTV box truly "feature complete" at last.

It may be time to finally get the box working again. It unfortunately has been off for several months now, as it was no longer getting any network connectivity. I'm hoping it's just a function of the network cord not holding up to the strain of running vertically about six feet from the box to the hub, holding itself up by its own connector; and not a function of the box running so hot that it fried its own network adapter (that little box does run very hot, even when idle). Without a network connection, it's not very useful — no network, no schedules; no schedules, no recording.

A victory

In following up on the compile error mentioned earlier, I found comments about trying to compile MythTV after installing a MythTV package. So, I shut down MythTV and moved the existing binaries and libraries out of the /usr/bin and /usr/lib directories, and then I recompiled (after making sure the configuration files were coded to /usr instead of /usr/local, since --prefix=/usr didn't seem to work as advertised). And the compile completed with zero errors.

After running make install on the newly-compiled binaries, I rebooted, and to my surprise and delight, MythTV came right up. Better still, all of the picoLCD's keys were behaving exactly as I had programmed them. Success!

So, just about all that's left is remote control. IR will be a long time coming, if I ever get it at all, because of the lack of an appropriate driver. I did install the MythWiFi plug-in for a web-based remote, which is probably my best hope for full remote control. But, when I click any button on the web remote, I get:

Warning: fsockopen() [function.fsockopen]: unable to connect to localhost:6546 in /var/www/remote/backend.php on line 115
ERROR: Connection refused (111)

The answer to this turned out to be a big "duh" moment -- Network Control must be enabled. Unfortunately, since I coded the LCD module to send "Key_Space" on the enter keypress instead of "Key_Enter" (because I was unsure of using "Key_Enter" vs. "Key_Return", I thought I was playing it safe), I had no way to navigate the config menus to enable that ("Space" doesn't activate the "Next" button). However, all was not lost -- since MythTV stores its configuration in a MySQL database, all I had to do was run the following query in MySQL:

update settings set data = '1' where value = 'NetworkControlEnabled';

A quick reboot (since exiting and restarting MythTV is also a little problematic with the keypad), and as if by magic, I can now control MythTV with a web browser.

Stubborn, isn't it?

I found another instance of the PREFIX directive, in the settings.pro file. The code around it would seem to indicate it defaults to /usr/local only if it's not already set; apparently configure --prefix=/usr doesn't set it to settings.pro's satisfaction. I set the prefix to /usr there as well, recompiled, linked to my libmythtv library, and finally, a successful boot.

Except it would seem that my code did not take effect. Down still sent a Key_Right.

Well, maybe the library isn't referenced, but compiled into the front end. Copy the compiled version of mythfrontend into place, reboot -- nope.

One last try. Maybe, just maybe, the fact that the old library was in /usr/lib at the time of compile of the programs caused confusion. I'll recompile.

While that's compiling, I'm going to take a look at the MythWifi plugin. Unless and until someone writes a lirc driver for the picoLCD (don't know if I will be able to), it'll be the closest thing we get to remote control. (And, if I can't get the front panel working, it'll be the only thing we get to control at all, barring hooking up an actual keyboard.)

The Mysterious Configuration

Quick post. I can't seem to find from where it's getting the /usr/local/bin path. I tried running ./configure --prefix=/usr (noting that the config file uses /usr/local if that isn't set), but that just wasn't good enough. Same problem (and associated errors in the log file) as before.

Control Progress

After downloading the MythTV package from MythTV.org's Downloads page and compiling mythlcdserver, I discovered that KnoppMyth used a slightly newer version of the files (and resulting libraries). Wasted a lot of time there, but got the last stable release out of subversion (which, fortunately, was the same version used by KnoppMyth), and I am now able to compile MythTV modules with the correct library. Mostly. I am getting this error with mythtranscode/replex:

/usr/lib/libmythavcodec-0.20.1.so: undefined reference to `XvMCLoadQMatrix'
/usr/lib/libmythavcodec-0.20.1.so: undefined reference to `XvMCSyncSurface'
/usr/lib/libmythavcodec-0.20.1.so: undefined reference to `XvMCFlushSurface'
/usr/lib/libmythavcodec-0.20.1.so: undefined reference to `XvMCBeginSurface'
collect2: ld returned 1 exit status
make: *** [mythreplex] Error 1


But I intend to ignore it for now as it happens after mythlcdserver is compiled. (This is going to bug people searching for an answer to this problem and finding none. Sorry. Hopefully I'll find out more for a later post, because I'd like to solve this as well before I get desirous to compile and install a brand new release of MythTV.)

I made the following changes to mythlcdserver/lcdprocclient.cpp:

Changed	To
lcd_keystring = gContext->GetSetting("LCDKeyString", "ABCDEF");	lcd_keystring = gContext->GetSetting("LCDKeyString", "A B C D E F");
aString = "client_del_key " + expandString(old_keystring);	aString = "client_del_key " + old_keystring;
aString = "client_add_key " + expandString(lcd_keystring);	aString = "client_add_key " + lcd_keystring;

Judging from the expandString function, apparently lcdproc used to take single-character "keys", all concatenated in one string (i.e. "ABCDEF" representing six keys), whereas now it can use longer names, and the functions take a space-delimited list. My guess is that, in order to make MythTV compatible with old configuration values, they chose to stick to the single-character key designations and assume all configuration strings were such, and the expandString function puts a space between each character (if lcdproc is version 0.5 or higher). Some of the lcdproc drivers even have a provision for mapping their keys to a single-letter designation. The driver for picoLCD does not, though. So, my solution is to make mythlcdserver use key names instead of key letters, by simply removing the call to expandString and treating the LCDKeyString value as a space-delimited string.

So far, I've had a bit of success. When I compiled mythlcdserver with my changes and used a LCDKeyString value of "Plus Minus F1 F2 F3 F4 F5 Up Down Left Right Enter", I was actually able to control MythTV with the keypad. Sort of. The

+

key moved the menu selection up, and the

-

key selected the menu option. None of the other keys did anything (except after pressing all of them quickly to see if anything else would work, it stopped responding altogether; I suspect a bug in the picoLCD driver). When I changed the LCDKeyString value to "Up Down Left Right Enter", Up moved the cursor up and Down selected. So I have at least solved the problem of getting the keypad and the mythlcdserver program speaking the same language.

I have to say there is an annoyance that makes this whole process much more difficult, in that mythlcdserver doesn't work from the command line. Oh, it starts all right. Even connects to MythTV and gets status updates. It just can't connect to LCDd. I keep getting "connection refused" from LCDd, whether I run as mythtv or as root. Can't figure out the problem there.

The reading of the key press appears to be handled by the library libmyth, via lcddevice.cpp. It is under the same assumption that the LCDKeyString value represents a list of non-delimited, single-character keys. In fact, the translation is done by taking the key name reported (actually just the first character thereof), finding the position it matches in LCDKeyString, and using that position as a "magic number" translation to a key press. Using my edited code, the key press for "Up" would cause it to look for a "U", find it at position 0, and translate that as Key_Up. "Down" caused it to find a "D" at position 3, thereby sending Key_Right (which happens to select a menu option).

To "fix" this, I am rewriting the LCD::handleKeyPress function. It is, for the moment, quite simple:

void LCD::handleKeyPress(QString key_pressed) {
    int key = 0;

    if (key_pressed == "Up")
        key = Qt::Key_Up;
    else if (key_pressed == "Down")
        key = Qt::Key_Down;
    else if (key_pressed == "Left")
        key = Qt::Key_Left;
    else if (key_pressed == "Right")
        key = Qt::Key_Right;
    else if (key_pressed == "Enter")
        key = Qt::Key_Space;
    else if (key_pressed == "Plus")
        key = Qt::Key_Home;
    else if (key_pressed == "Minus")
        key = Qt::Key_End;
    else if (key_pressed == "F1")
        key = Qt::Key_F1;
    else if (key_pressed == "F2")
        key = Qt::Key_X;
    else if (key_pressed == "F3")
        key = Qt::Key_I;
    else if (key_pressed == "F4")
        key = Qt::Key_Escape;
    else if (key_pressed == "F5")
        key = Qt::Key_M;

    QApplication::postEvent(gContext->GetMainWindow(),
         new ExternalKeycodeEvent(key));
}

I think there is oodles of room for improvement. Some way to map keys would be ideal. I was kind of hoping I could use the keybindings table, maybe get the LCD module to report a key of, say, "LCD_UP", and have that text in the keybindings table to identify what action LCD_UP performs. Maybe if I have time, I'll work on that. Right now, I'll just keep my fingers crossed for a clean [enough] compile, install the library, and see if I managed to make this thing usable.

And... It's no good. The front end never appeared, and the LCD showed LCDd's default screen (0 clients). The mythfrontend.log file gave me a clue, though:

sh: /usr/local/bin/mythlcdserver: No such file or directory
[...]
Couldn't find theme Titivillus

The big clue is that I have mythlcdserver in /usr/bin/, not /usr/local/bin/. I'm going to hazard a guess that there is a path that gets compiled into the library that is different than the default KnoppMyth layout.