Bell 9200 Reaches New Lows

As I blogged earlier, there are continuing problems with the Bell ExpressVu 9200 PVR. This morning, I woke up to the only problem on the growing list that I had not personally experienced yet. Error 0521. It means that the hard drive is corrupted. I lost all of my recorded shows (which, because of the stuttering problem, were almost unwatchable) and all of my event timers (which, because of the lack of name-based recording, were at the mercy of the networks shuffling around show times). I called Bell, and spent several minutes re-explaining all of the issues with the 9200 PVR, to which they agreed. They are shipping me a replacement unit which should be here in 3 to 7 days. I seriously doubt that the replacement is going to fix anything at all. Infact, I believe that the replacement shipping is merely a stalling tactic to try to delay another week or so until they can finally get all of the bugs out of the fabled software update.  I’m not the only one with problems with the 9200. I think Bell has a major PR problem on their hands, and they had better do something to fix it quick.

As a quick recap, here’s the list of 9200 problems that are known:

  • Stuttering playback of recordings
  • Green pixelization which doesn’t go away until unplugged
  • Name based recording missing
  • Caller ID not working
  • Error 0521 causing all hard drive content to be lost
  • Interactive TV features not working

Kenwood TM-D700A Repair

A fellow ham approached me with a defective Kenwood TM-D700A transciever. The unit showed no signs of life. There was no display, and no response to pressing the power button. The only hint was that the cable between the radio and remote head had recently been repaired.

Luckily, I have the service manual for this radio. It was essential in this repair. After checking the obvious (making sure that power was getting to the radio), I decided to check that power was getting to the remote head. In order for the soft power switch to operate, there is a constant supply to the remote head. There should be 9.66v between pins 1 and 4 of the remote head cable. In this instance, there was no voltage at all. A simple power supply around D903, Q910, Q911 and Q913 creates the 9.66v signal from the raw 13.8v. Again, no voltage at all. The supply is protected by fuse F902. This is a 1.8A tiny surface mount fuse. Without the schematic, I probably wouldn’t have found it. It’s located just below the voice synthesizer connector (see rather bad camera phone picture). I was unable to locate such a tiny surface mount fuse, so I replaced it with a 2A picofuse. I carefully bent the picofuse leads to attach to the original solder pads. A small dab of glue gun glue held the fuse up off of the circuit board to avoid any shorts.

After re-assembling the radio, all functionality checked out. I suspect that the original damage to the head cable caused a short which blew this fuse.

T520060428170625276T52006042818562153T52006042819462673

Disassembling the 9200 PVR

Never one to shy away from voiding a warranty, I decided to take the plunge and pull apart my malfunctioning 9200 PVR to see if I could figure out if the hard drive had any sort of AAM (Advanced Acoustic Management) enabled.

Opening the case was easy enough. It consists of removing four screws holding the top cover on. The cover on my unit was a little tight, and needed some gentle persuasion. Once the cover is off, you’ll notice a small silver sticker on the hard drive bracket. This makes it impossible to remove the hard drive without breaking the sticker and voiding the warranty. Luckily, drive removal was unnecessary because I was able to remove the SATA cable and power cable from the drive, and plug in cables leading to my desktop PC.

Once hooked up to the PC, I was able to recognize the drive in the BIOS. It comes up as a ‘MAXTOR SABRE’ drive. At this point, I tried several utilities to see if I could detect and adjust any AAM setting on the drive. I tried several DOS-based utilities (the Hitachi utility is supposed to work with many manufacturers’ drives, but didn’t work in my case). The only utility I was able to make work was a utility called Doc’s AAM Utility. Unfortunately, this utility is in German, and my German is non-existent. It appears that the drive was recognized, but that AAM was not supported on the drive. As of yet, I’ve been unable to confirm or deny whether AAM is a feature of this drive.

It’s late, so I decided to put the PVR back together and call it a day.

T520060417221559934T520060417234235958T520060417234247988T520060417234300721T520060417234314376

Bell 9200 PVR Sucks

have been a PVR fan for quite some time. My first exposure was a TiVO series 1 on DirecTV, and then when Bell ExpressVu came out with their 5100, I immediately grabbed one. The difference between the 5100 and a TiVO series 1 is quite stunning – no name based recording or season’s passes. In spite of the shortcomings, I happily used the 5100 for a couple of years, until the hard drive started getting more and more flakey.

What a perfect opportunity to check out ExpressVu’s latest offering – the 9200. This beast offers HD, dual tuners, 180 hours of recording time, and name based recording! At least, that’s what all the advertising said. In reality, there’s no name based recording. After much hype advertising the feature as coming soon for the last six months or so, they have quietly dropped all mention of it on their website.

The second problem is that my unit ‘stutters’ when playing back recorded shows. Not just some of the time – it stutters about every two mintues or so continuously! It makes watching recorded shows unbearable. I thought I must have got a defective unit. I did some searching on the web to see if this was a known issue. Boy was I surprised. I found some good threads over at digitalhomecanada.com with people experiencing the exact same issue. In fact, these people had researched the problem enough to pinpoint the problem to a particular brand of hard drive.

This morning, I called Bell ExpressVu to ask them about the problems I was experiencing. After initially denying any knowledge, they conceded that there was a known problem with the software, and that a fix was going to come out to address the problem. They were unable to provide me with an estimated date for the fix, and they seemed to think that the stuttering was okay and wouldn’t affect my enjoyment of Bell ExpressVu. They were also unable to provide a delivery date for the promised name-based recording feature. I’m not happy with their explanation, and I’m not happy that I’m not able to watch recorded shows with this unit. I’ve escalated the problem to a manager (yeah, right) who will call me back within 48 hours. I’ll let you know what they say.

Update: 2006-04-17 20:37

Discussions on the boards seem to suggest that the 9200s that exibit problems have Maxtor hard drives in them. My son suggested that perhaps Maxtor’s ‘Acoustic Management’ feature might be enabled on the drive, which would definitely affect performance, and might be the cause of the stuttering. I might just have to break down and void the warranty to pull the drive out to verify if this is actually the case. I’ll post an update if I pull it apart.

Tech Podcasting Has Jumped The Shark

I think I’m listening to history happening. I think that podcasting is the most incredible thing to happen to online content in quite some time. I’m a big fan of tech-related podcasts – mostly from the ex-TechTV crowd. However, this week I was shocked to hear the latest from Diggnation and This Week In Tech. Diggnation episode 38 has fallen to an all-time low. This was a live podcast from Reno Nevada. Unfortunately, Kevin and Alex had already hit the bar long before taping began, and the show quickly descended into chaos. TWIT’s episode 48 was an Apple 30th anniversary special. There was none of the usual TWIT crowd there. Instead, it was Leo and Woz having a love-in reminiscing about the ‘old days’. This carried on for an hour and a half. The audio quality was terrible, with some of the guests barely audible.

I’m beginning to suspect that these people have been doing the podcast thing for too long, and now the novelty has worn off. The once-surprising level of professionalism shown by these amateur broadcasters has descended into meaningless drivel. I’m seriously hoping that this week was just a blip, and these (and other) podcasters will pull up their socks. Otherwise, this medium is doomed.

Turning RSS Feeds in to Movable Type Entries

A while ago, I created the site PsychicProgrammer.com as a place to gather up programming-related stories from various corners of the Internet. I whipped up some code to automatically gather RSS feeds from various programming-related websites and pull the stories to turn them into Movable Type postings. I’ve had a few people ask how I did this, so I thought I’d post the code with some explanation of what’s going on.

#!/usr/bin/perl

use strict;
use XML::RSS::Parser;
use RPC::XML;
use RPC::XML::Client;
use Date::Manip;
use LWP::Simple;
use DBI;

The script is written in Perl, and I’m using a few nifty Perl modules available from CPAN.
XML::RSS::Parser – a great module for dealing with RSS feeds.
RPC::XML – used to communicate with Movable Type via RPC.
LWP::Simple – used to retreive the RSS feed document.

my @info=({'url'      => "http://www.oreillynet.com/pub/feed/16?format=rss2",
           'name'     => "Perl.com",
           'category' => "Perl.com",
           'datetype' => 2},
          {'url'      => "http://www.digg.com/rss/indexprogramming.xml",
           'name'     => "Digg.com",
           'category' => "Digg.com",
           'datetype' => 1},
          {'url'      => "http://www.oreillynet.com/pub/feed/20?format=rss2",
           'name'     => "Xml.com",
           'category' => "Xml.com",
           'datetype' => 2},
          {'url'      => "http://www.dotnetjunkies.com/WebLog/saasheim/rss.aspx",
           'name'     => "Steinar Aasheim's Blog",
           'category' => "Steinar Aasheim's Blog",
           'datetype' => 1},
          {'url'      => "http://tomcopeland.blogs.com/juniordeveloper/rss.xml",
           'name'     => "Junior Developer",
           'category' => "Junior Developer",
           'datetype' => 1},
          {'url'      => "http://programming.newsforge.com/programming.rss",
           'name'     => "Newsforge.com",
           'category' => "Newsforge.com",
           'datetype' => 2});

Here, I set up a structure containing the RSS feeds that I’m going to retreive. Of course, to scale this, it would be better to store this information in a SQL table.

my $username='user';
my $password='password';
my %category;
my $i;
my $dbh;
my $sth;
my $q;
my $seencount;
my $feed;
my $site;
my $xmldoc;

Some variable definitions.

# Set up database connection
$dbh=DBI->connect("dbi:Pg:dbname=p","psy","password") or die "Can't open database";

# Set up XML-RPC interface
my $cli=RPC::XML::Client->new('http://www.psychicprogrammer.com/mt/mt-xmlrpc.cgi');

# Set up XML parser
my $p=new XML::RSS::Parser;

# Get category list
my $req=RPC::XML::request->new('mt.getCategoryList','1',$username,$password);
my $resp=$cli->simple_request($req);
foreach $i (@$resp)
{
  $category{$i->{categoryName}}=$i->{categoryId};
}

Here, we set up a database connection. The database is used to record which articles have been seen before, so that we don’t have any duplicates. Next, we set up the RPC interface to the Movable Type blog. Make sure you put your correct URL in here for your blog. Then, we talk to MT to get a list of the categories. We do this because we need to map the RSS feed name to the appropriate MT category.

if($DEBUG)
{
  foreach $i (%category)
  {
    printf("$category{$i} $i\n");
  }
}

Some debugging script to dump the category information. This is a good check to make sure that the RPC interface is working. This script assumes that there is a pre-existing category defined for each RSS feed. Use the MT interface to create new categories.

foreach $site(@info)
{
  printf("*** Processing for site %s\n\n",$site->{'name'}) if $DEBUG;

  $xmldoc=get $site->{'url'};
  $feed=$p->parse($xmldoc);

This starts a loop for each RSS feed defined above.

  foreach my $i ( $feed->query('//item') )
  {
    my $datenode;
    my $date;
    my $titlenode = $i->query('title');
    my $linknode = $i->query('link');
    my $descnode = $i->query('description');

    if(($site->{'datetype'})==1)
    {
      $datenode = $i->query('pubDate');
      $date=UnixDate($datenode->text_content,"%Y-%m-%dT%H:%M:%S");
    }

    if(($site->{'datetype'})==2)
    {
      $datenode = $i->query('dc:date');
      $date=UnixDate($datenode->text_content,"%Y-%m-%dT%H:%M:%S");
    }

    my $dd = $descnode->text_content .
      "<br>Link: <a href=\"" . $linknode->text_content . "\">" .
      $linknode->text_content . "</a>";

For each entry in the RSS file, start pulling out information we’re interested in. I came across a problem with recording the date. If found both pubDate and dc:date tags. I use a variable called datetype to determine which one to look for in the RSS feed. I add a line of HTMl to the end of the article content that includes a link back to the original article.

    # Check to see if we've seen this one yet
    $q="SELECT count(source) FROM seen WHERE index=" . $dbh->quote($linknode->text_content);
    $sth=$dbh->prepare($q);
    $sth->execute();
    ($seencount)=$sth->fetchrow();
    $sth->finish();
    if($seencount==0)
    {

This is where we check our SQL table to see if we’ve seen this article URL before.

      # Post article
      printf("Posting %s\n",$titlenode->text_content) if $DEBUG;
      my $req=RPC::XML::request->new('metaWeblog.newPost',
                                     '1',
                                     $username,
                                     $password,
                                     RPC::XML::struct->new(
                                       'title' => RPC::XML::string->new($titlenode->text_content),
                                       'description' => RPC::XML::string->new($dd),
                                       'dateCreated' => RPC::XML::string->new($date),
                                       'mt_tb_ping_urls' => RPC::XML::array->new(
                                         $linknode->text_content)
                                     ),
                                     RPC::XML::boolean->new(1)
                                    );
      my $resp=$cli->simple_request($req);

This executes the RPC call to MT to actually post the article. Note that we attempt a trackback ping to the original article. This array can also be populated with other tracking sites, such as Technorati.

      # Change category
      $req=RPC::XML::request->new('mt.setPostCategories',
                                  $resp,
                                  $username,
                                  $password,
                                  RPC::XML::array->new(
                                    RPC::XML::struct->new(
                                      'categoryId' => $category{$site->{'category'}},
                                      'isPrimary' => RPC::XML::boolean->new(1)
                                    )
                                  )
                                 );
      $resp=$cli->simple_request($req);

Now we change the article’s category to be the same as the feed’s name.

      $q="INSERT INTO seen (index, source) VALUES (" . $dbh->quote($linknode->text_content) .
         ", " . $dbh->quote($site->{'name'}) . ")";
      $sth=$dbh->prepare($q);
      $sth->execute();
      $sth->finish();
    }
  }
}

# Close database
$dbh->disconnect();

We write a line into the database to say that we’ve seen this article before. We loop back for the rest of the articles, for the rest of the feeds. Finally, we close the database connection.

That’s it! I run this code from a crontab entry every hour or so. As soon as new articles are discovered in the RSS feeds, they will be magically turned into postings on a Movable Type blog, thanks to the wonders of XML-RPC.

I’d appreciate any comments or feedback if you decide to use this code in your own projects. Have fun!