Upgrading Gentoo MythTV to 0.22

I recently upgraded a frontend to Mythbuntu 9.10 and got MythTV 0.22 as part of the deal. Rather than leap through the fiery hoops required to revert it back to 0.21 I decided to take the plunge and upgrade my other Gentoo-based MythTV backend and frontends to 0.22.

This was trouble free as upgrades go but I did encounter the UTF8/latin1 database encoding problem which requires a backup and restore of the MythTV database after changing the default encoding to latin1. Changing the MySQL server configuration is easy to do on Gentoo as all that is required is to rebuild MySQL with the latin1 USE flag.

My package.keywords now looks as follows;

   >=media-tv/mythtv-0.22 ~x86
   >=media-plugins/mythcontrols-0.22 ~x86
   >=media-plugins/mythgallery-0.22 ~x86
   >=media-plugins/mythmusic-0.22 ~x86
   >=media-plugins/mythvideo-0.22 ~x86
   >=www-apps/mythweb-0.22 ~x86
   >=dev-python/imdbpy-3.8 ~x86
   >=x11-themes/mythtv-themes-0.22 ~x86
   >=x11-themes/mythtv-themes-extra-0.22 ~x86

and my package.use has;

   dev-db/mysql latin1

posted by James Gemmell on Mon, 28 Dec 2009 at 10:36 | permalink | tags: , ,

DTV1000S Linux driver now working

Top of my todo list for some time now has been to get my Leadtek WinFast DTV1000S DVB-T capture card to pay its way on a Gentoo MythTV backend instead of gathering dust on the shelf.

Video4Linux (V4L) drivers exist for the individual DTV1000S components listed below as they have also been used in other DVB cards.

What was lacking was the support for the card. I made an unsuccessful attempt at putting it together at the beginning of the year. Now Michael Krufky has done all the heavy lifting and committed his changes.

The easiest way to incorporate these into the 2.6.30-r8 kernel was to follow the V4L build instructions. Revision 13263 has all the necessary changes.

hg clone http://linuxtv.org/hg/v4l-dvb
cd v4l-dvb
sudo make install

I've not tested the IR capabilities of the DTV1000S as I'm using an AverTV DVB-T 777 for that purpose.

I used Steven Toth's instructions to get the TDA10048 firmware drivers from http://steventoth.net/linux/hvr1700/ and followed the readme.txt. Hat tip to Terry for his Leadtek product page.

posted by James Gemmell on Sun, 29 Nov 2009 at 10:17 | permalink | tags: , ,

Purging MySQL binary logs

The 60GB root partition of my MythTV server has been gradually filling up and finally reached capacity over the weekend. The culprit turned out to be the MySQL binary logs which have never been purged since I set server up in early 2007. Weighing in at 26GB it was time for them to go.

All that was needed is a flush and reset to purge the logs.

mysql> flush logs;
mysql> reset master;

posted by James Gemmell on Wed, 04 Nov 2009 at 21:33 | permalink | tags: ,

Recovery from Windows XP chkdsk failure

My laptop started hanging at the Windows logo stage and successive reboots wouldn't fix the problem. Booting into the Windows recovery console and running chkdsk manually on the C: drive would hang at the 22% mark. Next I booted Trinity Rescue Kit 3.3. This Linux-based Live CD is essential to any system recovery arsenal. It can be booted from a USB stick and even a PXE network boot, if necessary. Bruce Allen's Bad block HOWTO for smartmontools is a great source of help. Its focus is Linux file system recovery but the techniques are readily adaptable to NTFS.

No obvious indications of errors were turned up using smartctl. The next thing I did was use badblocks to run a low level read-only test;

# badblocks -v -o bad.txt /dev/sda1

This came up with a list of 113 corrupted blocks starting at 19519872, which is roughly 22% of the way into the NTFS partition. There was a single block at this location and the remaining 112 in a contiguous segment starting at 19519892. I used dd and ddrescue to make a copy of the blocks and hexdump to have a look at the contents. ddrescue is one of the GNU utilities I've fortunately never had to use before. It is suited to recover entire disk images and has some smarts built in to recover problem areas.

# ddrescue -b1024 -i19519872b -o0 -s1b -t /dev/sda1 /tmp/bad2.img
# ddrescue -b1024 -i19519892b -o0 -s112b -t /dev/sda1 bad3.img
# hexdump -C bad3.img | less

The hexdump didn't show up anything of importance (or so I thought.) I now had the option of writing back the ddrescued image or zeroing the blocks. This forces the disk to mark the blocks as bad and reallocate. I opted for zeroing as I didn't want any future problems to be masked by the attempted recovery. This was followed by a non-destructive read-write test on the full disk ensured that I'd got all the bad blocks;

# dd of=/dev/sda1 if=/dev/zero bs=1024 seek=19519872 count=1
# dd of=/dev/sda1 if=/dev/zero bs=1024 seek=19519892 count=112
# badblocks -v -o bad-2.txt -n -s /dev/sda1

A succession of reboots and chkdsk's later got me back to the XP login screen. The side effect of zeroing the bad blocks appeared to be losing the Windows license which prevented any kind of login. This may have been prevented by writing the bad blocks with the recovered image. A re-installation of XP corrected the problem with no loss of data.

posted by James Gemmell on Sun, 30 Aug 2009 at 08:19 | permalink | tags: