Michael J. Hammel - The Graphics Muse

If you hadn’t heard, Fedora and Red Hat systems had a break in of sorts that impacted their software repositories. I don’t quite understand the details but apparently nothing bad happened except that they need to create a new GPG key to sign their software packages. That means that all packages on all Fedora systems (possibly on Fedora 9, but maybe older supported versions as well) will eventually have to be migrated to the new signing key.

I wasn’t sure how this was supposed to work, but Kevin Fenzi over at tummy.com (who works on the Fedora project) pointed me to the LWN.net posting that linked to Fedora’s plan for this. So I’ll try to keep track with LWN.net on the issue to find out when I’m supposed to be updating my systems. Hopefully they’ll get the details worked out so we don’t get too far behind in security updates.

I should really be on the Fedora Announce mailing list, though, if I want to really keep up to date.

After installing F9 I had to go through the process of reinstalling all my old multimedia tools. Fedora doesn’t generally include support for playing MP3s or DVDs so you have to install them from alternate repositories such as Livna or ATrpms. I’d written up how to do this in the past for F7 but with F9 you can find most of what you’ll need from Mauriat Miranda’s Personal Fedora 9 Installation Guide. I found all I needed there except information on MythTV. I know from past experience that MythTV is best installed from the ATrpms repository.

Before doing any updates I found that Fedora has finally tasted the kool-aid: they’ve added useless sounds when you login and do other desktop activities. Disable this quickly, before you mind turns to Muzak mush. Look under System->Preferences->Hardware->Sound, under the Sounds tab to disable this foolishness.

Once all your multimedia stuff is loaded you will probably run into a few small dependency issues when doing updates using yum. I had xmms with mp3 support installed on one box which caused a yum update to fail. I also had problems with packages on which MythMusic depends.

The first problem I hit was with totem-mozplugin and nspluginwrapper. I don’t need either of these so I just removed them:

• sudo yum -y remove totem-mozplugin nspluginwrapper

Next I found that the xmms-mp3 package on one of my F9 systems was conflicting with MythMusic. I haven’t found a way to fix this yet and was left with simply removing xmms-mp3. At the same time I found that mjpegtools was also causing problems with yum updates. The fix here is to remove this package and then reinstall it after the update:

• sudo yum -y remove mjpegtools
• sudo yum -y update
• sudo yum -y –disablerepo atrpms install mjpegtools

A binary packaged version of AcidRip (for ripping DVDs to small .avi files) was not available for F9 when I tried, but the F8 version from ATrpms works if you install lsdvd and perl-Gtk2. Then you need to add this link:

ln -s /usr/lib/perl5/site_perl/5.8.8/AcidRip /usr/lib/perl5/site_perl/5.10.0/AcidRip

Then again, a quick check shows there to be an AcidRip for F9 source RPM now so you may not need to do this for much longer.

MythTV

The MythTV metapackage doen’t install all the plugins so you have to get them separately. Some plugins would not install due to a conflict with the python-imaging package. Remove this package before installing the mythplugins package.

The more annoying problem with MythTV comes from MythMusic’s use of the faad library. There are conflicts between this library and some others when doing yum updates. To get around this I remove mythmusic and faad2, which removes a number of other packages, do the update and then reinstall the packages I just removed:

• sudo yum -y remove mythmusic faad2 (also deletes mythplugins)
• sudo yum -y update
• sudo yum -y –disablerepo livna install mythmusic mythplugins avidemux mytharchive mythvideo transcode libquicktime

My Epson Style 740 finally gave out earlier this year, joining a Lexmark E210 laser printer that had given out before that. That left me without a printer (though my wife has two nice printers for her graphics design business). So I decided to get a low end model for my home office. Having had so much luck with the Epson and knowing Epson support was good in Gutenprint drivers, I went for a new Epson.

The cheapest model at my local Office Max was the Epson Stylus Photo R280. This printer is supported under Gutenprint but under Fedora 9 it isn’t. That’s because the gutenprint package under Fedora is missing the driver support for this printer. Fortunately, you just have to remove gutenprint and gutenprint-foomatic packages

sudo yum -y remove gutenprint gutenprint-foomatic

and then download the LSB 3.1 gutenprint RPM package from the OpenPrinting web site and install it:

sudo yum -y install gutenprint-5.0.1-1lsb3.1.i486.rpm

Note that OpenPrinting is the new version of the old LinuxPrinting.org, but it’s under the LinuxFoundation’s web site now.

The LSB3.1 gutenprint package is required because Fedora’s gutenprint-5.0.2 package does not contain the driver for the Epson Stylus Photo R270, which is the driver used for the R280 too. Unfortunately, since the OpenPrinting package is a back rev (5.0.1) of the gutenprint release, every time you do a package update (yum update) the OpenPrinting package is replaced by the Fedora package. This means you need to manually remove the Fedora package and reinstall the OpenPrinting package after each update. I don’t know why the Fedora package is missing the R270 driver.

Another important note on this is that you must get the LSB 3.1 gutenprint package from the OpenPrinting site. Fedora is an LSB (Linux Standards Base) 3.1 compliant distribution, not an LSB 3.2 compliant system (see the output from the lsb_release command).

With the OpenPrinting version of the gutenprint package installed, configuring the printer under CUPS was pretty simple. You can also configure the printer using the GNOME printer configuration utility (/usr/bin/system-config-printer from the command line).

Quality of the printer test is good but I’ve not done any serious prints with the printer yet. I don’t print many documents any more so it’s mostly intended for printing forms I need to fax or snail-mail.

I’ve finally figured out how to get my external monitor working with my Acer Aspire 1691WLMi laptop in side-by-side mode. The trick is to use the Virtual option with a large enough x dimension. Most of the documentation I’ve found up till now has stated that making Virtual larger than 2048 x 2048 was not possible. Well, turns out it is possible, but you disabled 3D acceleration. For me, that’s not a problem. I don’t use 3D for anything. MythTV works great on the laptops LCD while my desktop moves to the external monitor. BTW, moving the GNOME panel to the external monitor happens because the Intel chip always makes the VGA (re: external monitor) screen 0. In my case this means I lose 32 pixels in height since the external monitor is 1280×768 while the Acer Aspire is 1280×800. Minor annoyance.

So the xorg.conf now looks like this example.  Pay attention to the Screen section.

Detailed information on this can be found on ThinkWiki.

I’ve gotten into the habit of skipping every other Fedora release since that lets me skip doing upgrades every year.  I feel  a little more productive that way.  Most especially since I have lots of boxes at home doing special things (development, httpd staging, MythTV servers and frontends, etc).  Well, time flies and it’s time to upgrade once again.  This time I’m going from F7 to F9.

I upgraded a system at work first.  My primary development box.  Everything went fairly easily there (at least initially, see below) so I did my laptop and development / httpd staging server at home.  Those also went well, but they have the least specialized items on them.  I haven’t done the MythTV servers and frontends yet.

So what do I think of F9?  So far, it’s a mixed reaction.  I’ve found lots of changes that I’m not crazy about.  For one, the inittab file has been somewhat deprecated (mostly) and the init.d scripts expanded.  Why they moved things out of inittab I don’t know.  In my experience you don’t change the design of something that works unless the design prevents you from doing something better.  Inittab was fairly simplistic and, by design, flexible.  You can do just about anything from inittab if you need to.  And one of the things we’ve always done is launch the SysV init scripts (/etc/rc.d/rc.X, where X is 0-6).  This pretty much covers the range of things you can do at startup.  So why did they pull things like starting ttys out of inittab?  Consistency?  Maybe, but that’s not sufficient reason to change the design.  By moving things out of inittab all they’re doing is deprecating the basic purpose of inittab.  I don’t see the value.

Let’s ignore the inittab issue for now and look at the desktop.  Fedora, despite the claims by Red Hat, is doing lots of work on the desktop.  GNOME continues to grow (or bloat, as I see it) and evolve (or break, as I see it).   Some people will find this helpful.  Maybe not grandma, but perhaps semi-educated users.  But not me.  And probably not alot of technical users.

Up till this release I’ve never had any problems with GNOME sans, perhaps, general configuration changing from release to release.  But this release ran into a snag, in part because of a buggy NVidia driver which seemed to expose a bug in Metacity and, in turn, Bug-Buddy.  What happened (and this has only occurred on one machine, at work, which is using the NVidia provided X drivers) is that I would randomly loose all desktop interaction other than moving the mouse.  The desktop was still running - the GNOME panel’s System Monitor applet was still moving - but I couldn’t access anything on the desktop.  I couldn’t use the keyboard or change workspaces or click on anything.   This problem showed up 4 times in 2 days, three on the first day and the last being the one that sent me over the edge (see below for my switch from GNOME).

Logging in from another host I round that Metacity was running but so was Bug Buddy with Metacity as it’s reason.  Bug Buddy is that annoying little tool that pops up to ask if you want to report the problem with the application that just died.  But for reasons I’m not clear on - I think it has to do with the buggy NVidia driver, which I’ve since upgraded and the problem has not (yet) returned - Bug Buddy never opened it’s window.  I tried killing Bug Buddy but it kept coming back.  I tried killing Metacity and that just caused an additional occurrence of Bug Buddy to start.  All of this was visible only because I could ssh into the machine and perform the actions and view the response using the ps command.

In the end I was stuck wih killing the server (Ctrl-Alt-Backspace, which did work) and logging in again.  The moral here is:  save your work often.  Very often.  I didn’t lose anything but I sure was scared I was going to.

Upgrading the NVidia driver may have fixed this problem.  I believe NVidia was the root cause because the same problem occurred (sans the Bug Buddy issue) when I switched to XFce.   I’m sticking with XFce, however, because at least when the NVidia problem arises I’m not stuck in an endless loop thinking “I can still save it”, like some underpaid fighter jock from the ’50s in an experimental plane.  No, with XFce, when the NVidia driver locks up, none of the desktop applications crash.  Check one plus for XFce over GNOME.

There is another check for XFce:  no GVFS.  This new “feature” of GNOME is a user-specific mount point under the users HOME directory where the desktop can have access to things the user normally wouldn’t have access to.  Apparently tools related to file browsers need this.  Well, I don’t use file browsers.  Not nautilus or XFce’s file browser or any other.  I’m an old fart and the terminal prompt and aliases wrapped around “ls” and options are sufficient for me.  I don’t use drag and drop to open files in applicaitons.  I use “File->Open” when needed.  Or vi (who needs anything other than text files anyway?).

But the real problem with GVFS has to do with file access.  This damned directory gave fits to my rsync backups.  I finally managed to get rid of the errors from rsync by using an –exclude-from file (the syntax wouldn’t work right with –exclude filename for some reason).  This may be a problem with rsync, but I view it as a problem with GVFS because something that worked fine before stopped working because the desktop changed on my upgrade.  I’ve been FORCED to deal with their change.

Another pain in the ass feature is the security lock down on the desktop.  There was a time when “xhost +hostname” was all that was needed to allow another system to display on your screen.  Now you have to muck with SELinux (a royal pain in the ass for the average user, no matter how useful a security tool it may be) and GDM.  In F7 it was just GDM that had gotten in the way but there was a nice graphical interface to disable the lockdown.  Now you have to hand edit a gdm configuration file along with mucking with SELinux.  Personally, I just disable SELinux and hope the firewall keeps me safe (probably not, but I’ll deal with the break ins with another method).

Here’s a note to all you pimply faced GNOME hackers:  change is bad.  It’s damned evil.  And rewriting something from scratch for the desktop because it don’t fit your ideal is bad.  We old folks (most especially grandma and her realm of unwashed anti-techites) don’t give a rats ass why GVFS solves the problem you were trying to solve.  If it changes how they do things, they won’t be happy.

And now that I’m an old fart (though not a grand dad - hopefully that’s years away), I don’t like change either.  Geez, I miss the days of FVWM.  I thought a desktop for Linux would be a good thing.  I’m not so convinced anymore.  To hell with world domination.  Just make it work like it used to.

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.