Michael J. Hammel - The Graphics Muse

I made notes on my upgrade from 0.20 to 0.21.  The software upgrade is clean but the runtime is somewhat broken on two of my three frontends.  These are my (raw) notes.

All upgrading was done via the ATrpms repository which provided the previous release (0.20) for both backends and frontends.

No serious problems on the backend.  There were some issues with getting the database updated but after I shutdown the backend, ran mythtvsetup as root and then exited the database was migrated.  I don’t think I did anything other than that.

I tested the backend with a frontend setup on the same system.  Everything worked perfectly.

Next I upgraded my mythbox:
    Fedora 7
    EPIA M-10000 board
    IguanaWorks USB IR receiver

The upgrade worked fine with yum.  However, the video was terrible when I tried to watch TV.  I tried switching from OpenGL to Qt for the menus (which have a much different appearance) but that didn’t help.  I was using the Project Greyham theme.

Tried a different theme: MythMediaCenter.  Same problem.  The OSD menu looks terrible.  The Menu Theme is set to "Default", though I don’t know if that’s what I had it set to previously.   I changed it to "Classic" then went through all the rest of those setup screens and after the last one MythTV died (and restarted because I’m using inittab to restart it).  This didn’t change the menu.  Turns out the problem is with the playback settings (as I discovered from reading the MythTV Users list).

Live TV playback is very jumpy.  This was not the case for 0.20 on this system.  Went into Setup->TV Settings->Playback:
    Playback Profiles (3/9)
        Profile: CPU+
            Moved XvMC to position 1: crashed MythTV without editing
            Edit this entry:
                Decoder: Via XvMC
                Video Renderer: xvmc-blit
                OSD Renderer: chromakey
                OSD Fade:  not set

                Primary Deinterlacer: Bob (2x)
                Fallback Deinterlacer: One field
            Tried Live TV again:  no picture
            Restarted MythTV frontend:  no picture
            Note: back button/ESC does nothing at this point.

            Restart MythTV
            Edit entry again:
                Decoder: Standard XvMC
                Video Renderer: xvmc-blit
                OSD Renderer: chromakey
                OSD Fade:  not set

                Primary Deinterlacer: Bob (2x)
                Fallback Deinterlacer: One field
            Tried Live TV again:  crash

            Restart MythTV
            Edit entry again:
                Decoder: Via XvMC
                Video Renderer: xvmc-blit
                OSD Renderer: chromakey
                OSD Fade:  not set

                Primary Deinterlacer: One field
                Fallback Deinterlacer: None
            Tried Live TV again:  no video
            Note: back button/ESC does nothing at this point.

        Restart MythTV
        Profile: Slim
            Tried Live TV again:  playback works, not jumpy.  Poor color,
            though not terrible.  Picture controls are enabled but
            increasing "Color" setting in playback mode doesn’t appear
            to affect the color quality.
            Didn’t note settings and now I’ve mucked them up.  *sigh*

        Restart MythTV
        Profile: CPU++
            Edit entry again:
                Decoder: Standard
                Video Renderer: opengl (was xv-blit)
                OSD Renderer: opengl2 (was softblend)
                OSD Fade:  not set (was set)

                Primary Deinterlacer: None
                Fallback Deinterlacer: None
            Tried Live TV again: crash

        Restart MythTV
        Profile: High Quality
            Edit entry again:
                Decoder: Standard
                Video Renderer: opengl (was xv-blit)
                OSD Renderer: opengl2 (was softblend)
                OSD Fade:  not set (was set)

                Primary Deinterlacer: None
                Fallback Deinterlacer: None
            Tried Live TV again: starts to play, but crashes on exit after
                having video freeze and audio dropping in and out

        Restart MythTV
        Profile: Slim
            Edit entry again:
                Decoder: Standard XvMC (was Standard)
                Video Renderer: xv-blit
                OSD Renderer: softblend
                OSD Fade:  not set (was set)

                Primary Deinterlacer: None
                Fallback Deinterlacer: None
            Tried Live TV again: crash
            Edit entry again:
                Decoder: VIA XvMC (was Standard)
                Video Renderer: xvmc-blit
                OSD Renderer: softblend
                OSD Fade:  not set (was set)

                Primary Deinterlacer: None
                Fallback Deinterlacer: None
            Tried Live TV again: crash

    Turns out there is a bug on this problem with VIA XvMC:
        http://svn.mythtv.org/trac/ticket/4930

    I’m screwed on MythBox till this is fixed.

Next: My laptop frontend
    Fedora 7
    Intel 915GM grahpics (intel X driver)
    No IR, just a keyboard and mouse

Upgrade went smoothly.  First try at LiveTV had jumpy video (smooth sound).  Obviously need to update it’s playback settings too.  Escaped out of LiveTV and MythTV crashed.

Fonts were way too large with MythMediaCenter (which was the config already set).  Reduced font sizes as first setup change.  Switched to "Slim" playback without modifying it’s configuration and the playback worked.  However, when exited with ESCAPE MythTV dies.  This happens every time.

I noticed mythtv themes appeared to be at their old rev:

    mythtv-themes.i386                       0.20.2-175.fc7

so I tried updating them.  But that didn’t do anything;

    mjhammel(tty3)$ sudo yum install mythtv-themes
    Setting up Install Process
    Parsing package install arguments
    Nothing to do

So I tried updating the MediaCenter theme manually:

    mjhammel(tty3)$ sudo yum install mythtv-theme-MythCenter mythtv-theme-MediaCenterWeb mythtv-theme-MediaCenterOSD

This worked:

    =============================================================================
     Package                 Arch       Version          Repository        Size
    =============================================================================
    Installing:
     mythtv-theme-MediaCenterOSD  noarch     0.17-6.at        atrpms        188 k
     mythtv-theme-MediaCenterWeb  noarch     0.17-5.at        atrpms        460 k
    Updating:
     myththemes              noarch     0.21-138         atrpms             14M

    Transaction Summary
    =============================================================================
    Install      2 Package(s)
    Update       1 Package(s)
    Remove       0 Package(s)

    Total download size: 15 M
    Is this ok [y/N]:

I managed to get the Laptop working using the Slim playback profile.  I edited the same profile on the M10K so it was an exact match and that got the M10K playing again.  Both frontends crash when exiting the internal player, whether from live TV or from playing a ripped video.

I keep running into this problem and I decided it was time to make notes on how I resolve it.

The problem is that I’ve used the methods I’ve described previously to include missing multimedia support in Fedora 7 and when I do updates I run into this problem:

Error: Missing Dependency: libdts.so.0 is needed by package xine-lib-extras-nonfree

It’s not clear to me why this comes up, but I think it is because libdts is included in a package called libdca but xine-lib-extras-nonfree apparently depends on a libdts package instead.  Something like that.

So what I do is remove libdca first:

sudo yum remove libdca

This removes xine-lib-extras-non-free too.  That’s okay.  It’s a temporary problem which I’ll resolve after I do the rest of my updates.  Both packages come from the Livna repository, which means I should be able to reinstall them later.  Next, I do my system updates, which now no longer encounter the previous error:

sudo yum -y update

This completes without problem.  Then I reinstall the xine-lib-extras-non-free package as per the command in my Fedora 7 multimedia script:

sudo yum -y –enablerepo=freshrpms install xine xine-lib-extras-nonfree libdvdcss libdvdnav gxine

That appears to be the way to get past this constant problem.

I found an interesting story online about a producer at CNN who got canned for blogging - mostly about stuff that didn’t pull the corporate line.  It’s interesting to read from my point of view because it mirrors (to an extent) the pitiful way in which Dell treated its employees or Rockwell treated its employees (like my dad). With this guy, though, I at least see the start of the revolution of reporting that will NOT be a part of big media.  Long live blogging!  Big media must die, die, die.  The truth cannot be told if it’s attached to monetary requirements.

And I think I’m done watching CNN too.  I long ago stopped watching FOX. The only value they provide I can see when it’s replayed on The Daily Show.  If I want real, honest news reporting, I’ll go online to read and listen to NPR or listen to BBC on XM radio.  Yeah, XM is big media.  I can alwasy skip XM and go online with them too, though it’s useful to have more than one way to get information (digital broadcast AND Internet broadcast).  But the BBC is the closest thing to a news source I can trust  these days.  At least for now.  Till they do something stupid too.

A recent article about GNOME 2.22 included this brief mention:

Totem 2.22 features plugins for YouTube and MythTV. The YouTube plug-in allows you to search and browse YouTube.com video files all within Totem. The MythTV plugin for GNOME allows you to view recordings from a MythTV server as well as view live TV.

According to posts on the MythTV Users mailing list, the Totem translations file suggests that Totem is acting as an actual MythTV frontend.  Subsequent posts point to this using a little publicized project, gmyth, to access the MythTV backend services.  This just happens to be the same library used by MaemoMyth, a MythTV frontend that runs on the Nokia N800.

Pretty slick.  MythTV is starting to look very grown up.

I got an interesting question the other day that I thought might be of value to the general public.  The requestor thought there might be a problem with the Linux scheduler, but that really wasn’t the issue:

I’m using FEDORA 7 at work and I have run into a problem that I thinks is related to the scheduler. I have a core program that must run in the background and need to be able to configure it on the fly using an interface program that must run in the foreground and when done have the interface go away. When I need the interface again, I just restart it, reconfigure the system and tell the background process to grab the configuration and deal with it. So I start the UI program do what I need and then inform the background process via a socket the new configuration knowing that it sould be in a state where it will read from the socket the new data. The problem is that the background process start a read from the socket and never returns. This seems to to be a scheduling problem. The question is 1) how to prove it and 2) how to fix it? Please accept my apology  for the intrusion. Have you ever encountered a problem like this?

This likely isn’t a scheduler problem.  It’s more likely socket management problem.  You probably aren’t reading the EOF on the socket or you have a KEEP_ALIVE on it or something similar.  In other words, your daemon (re: background) process is not closing the connection or is not getting the socket close from the foreground process.

A simpler solution to this is to have your daemon process read a configuration file periodically.  It does a stat() on the file and if the file has been touched since the last check then the file is reread.  If the file has not been touched since the last check, then the daemon skips it.  The daemon just has to poll the file every now and then.  The foreground process doesn’t care about when the daemon polls the file. It just reads the file when it starts, and writes the file when it’s done.  No socket messiness.

Of course, if your foreground process is not running on the same machine as the daemon, then you’ll need to stick with the socket-based solution.  But it didn’t sound like that was the case here.

I tend to work very much to myself on projects.  I get help from the open source community via discussion forums or mailing lists, but in-house (at work or at home) I’m pretty much on my own to figure things out.  This has led to some development practices which work well for me, but are not necessarily the norm.  One of these is the use of debug libraries in all my code.

While most languages and development environments offer debuggers that let you step through code to find a problem, I find that I seldom use these.  For C code I sometimes use gdb to find where a program crashes, while for Java I’ve never used a debugger.  Instead, one of the first things I do in a project is create a debug library.  I then use this library to save trace information to a file or to the console.  In this way I can always tell what is happening in places where I think something else should be happening without having to examine structures or classes.

But I know the rest of the world is not so old-school as myself and I wonder if I should continue to avoid the potential benefits of a debuggers.  Then I happened across the following quote, which was posted to the Log4J (a logging library for Java programs) web site:

As Brian W. Kernighan and Rob Pike put it in their truly excellent book "The Practice of Programming"

As personal choice, we tend not to use debuggers beyond getting a
stack trace or the value of a variable or two. One reason is that it
is easy to get lost in details of complicated data structures and
control flow; we find stepping through a program less productive
than thinking harder and adding output statements and self-checking
code at critical places. Clicking over statements takes longer than
scanning the output of judiciously-placed displays. It takes less
time to decide where to put print statements than to single-step to
the critical section of code, even assuming we know where that
is. More important, debugging statements stay with the program;
debugging sessions are transient.

Well, if Kernighan and Pike can think like me, I must not be too wrong. So I think I’ll stick with debug libraries.

It’s interesting to find old friends and coworkers reading my blog, mostly since I write it for myself and really don’t expect anyone else to read it.  But I guess a few do.

So it was a pleasant surprise to hear from Charlie Sauer today.  Charlie was director of product planning at Dell during the days of Dell Unix.  He’s written up an accurate (as much as I can remember) history of that product.  Consider it the unbiased history of Dell Unix, to counter my fairly biased memories of the same period.

I downloaded Google’s Android SDK today.  The kit is about 55MB for Linux and was a breeze to get running.  The kit comes with an emulator that displays a generic phone with the Google UI.  The majority of the online help is geared towards creating applications that run on Android.  The application development environment requires Java (there is no native C/C++ interface at the moment) and there is an Eclipse plugin for people who need IDE’s to build software.  Fortunately, I don’t need IDEs and Google does a good job helping those who don’t use eclipse get started.  There are plenty of command line tools available in the tools directory of the SDK.

How this works is that you create an Activity project using activityCreator.py (in the tools dir), write your code, and build it with ant.  The build.xml created by activityCreator.py handles the packaging for you.  Android requires applications be packed in a special format called apk, which is a wrapper for another format called dex.  At the moment I don’t know anything about those formats but I don’t really care either.  Since the autogenerated build.xml handles the packaging I can focus on application development.

Once the application is built you install it in the emulator’s environment using the adb debugger:

adb –install file.apk

You need to be in the HOME page of the UI.  You’re initial application will probably show up under the Applications folder though I’d suspect you can stuff it anywhere you want in the UI. 

I built the autogenerated code for a new project without writing any of my own code and installed it.  It worked perfectly.

Since I’m quite familiar with building applications under ant now (thanks to the grid system I’m building in my day job) I next wanted to see what UI components are available.  Android has some sophisticated features like transparency and mixed 2D/3D displays.  The documentation for their UI libraries are quite complete for a first release.  The widget set is extensive enough to build very useful applications.

My first impressions of this project is that it’s complete enough to do serious development.  Considering they’re offering $10million in prize money for applications, I think that’s a very important point to make.  Anyone who waits is going to be left behind on this one.

Update: 2007-11-16
I’ve played with the tutorials.  They’re fairly well written and easy to follow, although if you, like me, don’t use eclipse (I use vi and cscope) you have to cheat a little to see what eclipse may be hiding, uh, I mean automatically doing for you.  IDEs suck.  You’ll never learn anything if you let an IDE do all your work for you.

Anyway, I discovered that adb, the tool used to upload the binaries to the device, doesn’t appear to have a delete option.  So you can install apps but not remove them.  At least not as far as I can see.  I got around this by using the adb shell to manually delete the .apk files.  What happens when you do this is that the device errors trying to load the file (because it’s gone) and causes the Applications folder to be reread.  Essentially, the device recovers gracefully when the .apk’s are removed out from underneath it.  That’s a good sign.  Nice, stable environment to develop in.

So, more investigation.  I find that the basic classes available are rather interesting (lots of harware, os and environment classes) and plan on extending the initial NotePad application to pull information from the device.  One of the first things I want to do is deteremine how to receive an event when a button is pressed.  Not a keyboard button, but one of the buttons on the side.  I’m wondering if you can hijack those for your application.  Anyway, more fiddling to come…

I’m building Minimyth on a number of machines in order to debug a problem with the build I’m having on Fedora 7.  The machines are running FC5 and FC6 and are on an internal network that connects to the Internet via a proxy.  Minimyth’s source is a build system whose purpose is to build a distribution from scratch (much like the Linux From Scratch methodology).  To do this, it uses the GAR build environment to configure package downloads which are then used in the build process. 

The downloads are all handled with wget.  In order to use wget on these machines I needed to tell wget to use the proxy.  The man page for wget doesn’t say exactly how to do this, but if you read carefully it mentions the use of *_proxy environment variables.  After some experimentation I discovered that the * can be http or ftp (or perhaps other mechanisms that wget understands and the proxy supports).  So now I do the following as part of my environment setup before building minimyth:

export http_proxy="http://proxy.sys.com:4214"
export ftp_proxy="http://proxy.sys.com:4214"

The 4214 is just the port on proxy.sys.com (an fake name, by the way - substitute your proxy’s host name there) that the proxy server is listening on.  If you need to find a proxy server, try squid.  But note that setting up a proxy can be a bit daunting.  It’s not readily clear how to do this in 5 minutes.

I’m finally getting back to using my Epia M10000 board as a MythTV frontend.  The goal here is to configure it to run with a CF card for booting and a wireless card to communicate with the backend, and use the TV-output connected to our TV in the living room.  Long ago I started out on this project using a small system called MiniMyth, which essentially network boots the board to run it as a diskless frontend.  I then migrated to rolling my own distribution using the steps outlined by the Linux From Scratch project.

Well, life gets busy and the best laid plans don’t always work out.  I’m now back on this project and have found that MiniMyth has evolved a bit since I last used it.  Enough so that I can now muck with it enough to try and get the one missing piece added to it:  wireless networking via the MadWifi drivers.

MiniMyth is designed with two boot options and two root filesystem options.  The boot options are either local, as from a hard disk or CF card, or network boot via PXE.  The root filesystem options are either run from RAM or run from an NFS mounted root partition.  To get back into this project I started with the simplest mechanism to set up:  PXE booting with an NFS root filesystem.  This setup will allow me to peruse the runtime system manually to see how it was built and how I might go about adding in the WIFI drivers.  Setting up for booting from PXE is fairly straight forward.  You’ll need to install the DHCP and TFTP servers (the latter requires xinetd to also be installed) on your boot server.  My boot server happens to be the same system running my MythTV backend.  You’ll need to make sure you configure your minimyth.conf file, which needs to be stored in your TFTPBOOT/conf/minimyth directory, where TFTPBOOT is the root directory for your TFTP server.

While your debugging your configuration you should know some things that the MiniMyth site doesn’t mention.  First is that the network booted frontend has a telnet server installled.  If you want to login to it and look around after it boots up, then telnet to the box and use the userid "root" (no password).  Note that MiniMyth is NOT secure.  It’s not intended to be publicly accessible.  It should only be accessible on your local network at home and safely behind a well configured firewall.

Another thing to note is that there is an extra script you can write that MiniMyth will download from the same directory as your minimyth.conf file.  This file is called minimyth.script and should be written as an ordinary shell script.  The online docs at the MiniMyth project suggest that if you use this script to manually mount remote directories you should use a functions file called /etc/minimyth.d/minimyth.functions, but that doesn’t exist at boot time.  More than likely this has been changed to /etc/rc.d/functions.  For mounting remote directories on the MiniMyth box you use a function called mm_url_mount, which also differs from the online documentation (which says to use mount_url). 

I have all video related files saved under /store on the MythTV backend and music under /music.  I export these two directories via NFS.  In order for my MiniMyth box to use these, I configure the following variables in my minimyth.conf file:

MM_MYTHMUSIC_MOUNTPOINT=’/music’
MM_MYTHMUSIC_URL=’nfs://192.168.1.101/music’
MM_MYTHVIDEO_MOUNTPOINT=’/store’
MM_MYTHVIDEO_URL=’nfs://192.168.1.101/store’

To verify these settings are in place, I telnet in after the Minimyth box boots and check to see that /store and /music exist on the box and that the remote NFS server is mounted there correctly.

So far everything is working using the netboot w/NFS configuration except that videos are not playing yet.  I believe this to be a problem with the way the video players are configured.  I’ll be testing that shortly.

The next step after verifying everything is working as expected using the netboot/NFS configuration is to move to a local boot configuration on the CF card.  I’m also working, at the same time, on trying to build Minimyth from source (a metabuild based on GAR).  Once the local boot and build-from-source are working, then work can begin on determining how best to integrate the MadWiFi drivers.  I don’t expect this to be particularly difficult other than learning the structure and usage of the GAR-based build system.

One thing I noticed while getting started with compiling Minimyth from source:  on Fedora 7 the default compiler is found using a package called ccache, which is used to speed startup of the compiler.  That means "type gcc" (which lists the location of gcc under BASH) will report "/usr/lib/ccache/gcc".  That doesn’t work for the Minimyth build - it dies when it tries to build a package called gmp, which is a dependency for building the Minimyth gcc.  To get around that you simply start the build by explicitly setting the CC environment variable, such as:

make CC=/usr/bin/gcc build