Tuesday, December 25, 2007

mythtv and 720p HD screen

This morning a nice Sharp 32" Aquos 720p screen was found near the fireplace. What a surprise. I hooked it up with analog VGA, since I don't have a DVI-HDMI cable here. The TV doesn't come up in wide screen format automatically (somewhat to my surprise).

Things I did to make mythtv work with this setup:

  • enable "de-interlace video" in mythfrontend setup (otherwise videos recorded from broadcast TV are unwatchable due to interlacing artifacts).
  • in xorg.conf turn off the special settings I added for analog TV out (don't need that anymore)
  • in xorg.conf add the 720p metamodes settings as described in the mythtv wiki


Well, the latter seems to have no effect, I guess my Nvidia driver is too old. I set the modes to 1280x720, and still the TV would only use 1024x768. After some headscratching and navigating the TV menus I found an option to adjust the input signal. It offered me to force the input to 1360x768. Done. Looks pretty darn good now.

Update:
After reading the manual (who reads manuals anyways?) I found out that apparently, the analog signal for 1360x768 and 1024x768 can't be differentiated automatically. Go figure...

Also, in order for mythtv to use the available screen real estate when playing SD videos, one needs to change the aspect ratio using the W key (or set it permanently in the player settings). I found that 'Fill' gives me the best picture with the least amount of distortion. Of course this will chop off some at the top and bottom of the picture, and heads/faces are slightly cropped. Particularly visible with shows like '24' which include lots of head shots.

Monday, December 24, 2007

Saturday, December 22, 2007

mdadm: /dev/hdb1 is too small: 0K

I finally added a second disk to grumpy so that I can complete the raid1 setup for my mythtv media archive.

I partitioned the disk to match exactly the first disk. On the first pass, the big media partition ended up a few blocks short, even though the disks have exactly the same number of blocks. I specified everything in cylinders, so that should have come up with exactly the same result. When I wiped the partition table and tried again, I adjusted the partition types only after creating all the partitions and verifying that they all line up. Then I changed the partition types for the raid partitions to fd and it all was correct. I have screwed up something the first time around, or changing the partition type to fd does something to the amount of available blocks on the disk. Anyways...

Next, I added the new media partition to the existing half of the array and let it rip.


mdadm --add /dev/md0 /dev/sdb6


Took three hours and completed just fine.

Next I want to make the root partition a raid1, too. The process should be rather simple:

  • create one half of the mirror on the new disk
  • create file system
  • cpio root partition data over to new root partition
  • reboot, manually set root to new partition
  • change partition id on old root partition
  • set up that partition as second half of root md

I ran into problems with the first step already. First, I interpreted the parameters to the --create option of mdadm wrong, and got an error message that there are not enough devices specified, even though I listed "/dev/hdb1" and "missing". The trick is --auto=yes still needs a md device name pattern (you need --auto to create the md device node in udev), like so:

grumpy:~# mdadm --create --auto=yes /dev/md1 -l 1 --raid-devices 2 -v /dev/hdb1 missing
mdadm: /dev/hdb1 is too small: 0K
mdadm: create aborted

Now, what is that?

I'm following the man page, it matches various examples what people do I found on the Internet. But no dice. Finally, this blog set me on the right track. I wrote the partition table, but the kernel didn't properly update it in memory, so I'm in this strange halfway state. It works for using hdb6 as mirror, but not for creating a new mirror on hdb1. fdisk confirms the problem:

grumpy:~# fdisk /dev/hdb

The number of cylinders for this disk is set to 60801.
There is nothing wrong with that, but this is larger than 1024,
and could in certain setups cause problems with:
1) software that runs at boot time (e.g., old versions of LILO)
2) booting and partitioning software from other OSs
(e.g., DOS FDISK, OS/2 FDISK)

Command (m for help): p

Disk /dev/hdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 1 851 6835626 fd Linux raid autodetect
/dev/hdb2 852 60801 481548375 5 Extended
/dev/hdb5 852 1032 1453851 82 Linux swap / Solaris
/dev/hdb6 1033 60801 480094461 fd Linux raid autodetect

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.
The kernel still uses the old table.
The new table will be used at the next reboot.
Syncing disks.

Alright. Reboot coming up right when the kids are done watching "Der rosarote Panther".

After the reboot I get:

grumpy:~# mdadm --create --auto=yes /dev/md1 -l 1 --raid-devices 2 -v /dev/hdb1 missing
mdadm: size set to 6835520K
mdadm: array /dev/md1 started.
grumpy:~# cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 hdb1[0]
6835520 blocks [2/1] [U_]

md0 : active raid1 hda6[0] hdb6[1]
480094336 blocks [2/2] [UU]

unused devices:

Sweet! Works like a charm.

Monday, December 03, 2007

Furniture Frustrations

I'm visiting my parents in Germany at the moment and stopped by one of the larger local furniture retailers. We are looking for a replacement dining table and chairs, as well as a couch table for the living room and have much trouble finding anything in California.

US furniture is either poorly made, ridiculously expensive, or doesn't have even hints of modern design. Many times all three apply.

As I was walking through Moebel Hofmeister I grew more and more frustrated. Where in most US furniture stores I have a choice of 3 or 4 couch tables, they had dozens to choose from in all kinds of styles and price ranges.
Where in the US I have a choice of 10 - 15 dining tables (on a good day), they had a whole floor full of dining arrangements, tables and chairs.

I left the store after an hours or so utterly frustrated. Anyone know any halfway decent furniture stores in the SF Bay Area or at least California?

Sunday, December 02, 2007

Layout Stats for Emsingen & Talheim - not so useful

I might have mentioned this elsewhere before, I really like Joe Fugate's Siskiyou Railfan Web site. He gave a talk a while ago about layout design analysis.

I wonder how this works for Emsingen & Talheim...

Room Size:
I'm working with 2.20 x 2.40 m, which is 7.2 x 7.8 ft = 56 square feet

Layout Area:
I have roughly 1.05 x 1.10 m of space in the lower left corner (12 sq ft), so the layout covers 44 sq ft.

In other words, the layout will fill 78% of the available space, which is quite a bit. However, since I'm planing an access hatch in the area of the lake, I think I should be fine.

Number of Turnouts:
I have 24 regular turnouts, 3 three-way switches, and 2 double-slips, that makes a total of 31 turnout equivalents.

Track Length:
~82 ft (24m) of visible track, ~75 ft (22m) of hidden track. It's that much hidden track mostly because of the long ramp to hidden staging and hidden staging itself. A total track length of 157 ft roughly equates enough space for 314 HO box cars (2 cars/foot).

Mainline Track:
22 cars in staging yard, 112 cars in main level tunnel and visible track. Total: 134 cars

Passing track:
4 cars in Talheim, 5 cars + 16 cars in Emsingen. Total: 25 cars

Storage Track:
3 cars in Talheim, 9 cars in Emsingen. Total: 12 cars

Service Track:
14 cars in Emsingen. Total: 14 cars

Staging Track:
120 cars to/from staging yard, including loop + staging tracks. Total: 120 cars

Connecting Track:
314 - 134 - 25 - 12 - 14 - 120 = 9

Passing Sidings: 3

Passing Train Length: 16/8/4 (longest/average/shortest)

Staging Tracks: 3

Staging Train Length: 24/21/16 (longest/average/shortest)

All those numbers now may yield some interesting stats:

Maximum Number of Cars: 112 = (storage + passing/2 + staging) * 0.8

Using the regular formula I get 112 cars on this layout. That's clearly too much, and comes from the fact that I counted the hidden main line track into staging as staging track. A more accurate number on my layout would be to only count the loop and the actual staging tracks, and don't include the ramp:
((24 + 24 + 16 + 8) + 12 + 12 ) * 0.8 = 76 cars

Number of Cars Moved in an operating cycle: 71 (staging * 2 + passing + connecting) * 0.4

Trains: 9

What can I learn from this? Nothing really. This was an interesting exercise, but I think that due to the nature of this layout, the formulas don't fit well, and the final outcome is not nearly as useful as I thought it might be when I started this.