| Greg's computer video recorder project |
|
|
| Main multimedia page |
| Multimedia packages page |
| Greg's diary |
| Greg's photos |
| Greg's links |
| Greg's home page |
|
|
|
This page describes the fun I have had setting up a computer as a video recorder, covering the time period April to December 2006. I also have older information which hopefully won't be needed except to document the pain, and the current log. See the main page for an overview.
Inevitably, I make mistakes. As I gain experience, I realize these mistakes; rather than just correcting the text, I prefer to leave the original statement and add a clarifying comment: if I have made a mistake, others might do the same.
Yes, this page is done in chronological order. I hate reverse chronological order. The latest entry is here.
Discussions on Australian lists suggest that I won't find a better alternative to computer video than MythTV or mplayer, so in the afternoon spent more time trying to get things to work. It's still like pulling teeth: spent all afternoon trying to work out how to get my tuner card set up. I've done this before with FreeBSD, but with Linux and even help from people on the list, it still took all afternoon. People on the lists suggested using xawtv to test the tuner; I've already commented on how bad that program's documentation is. It now comes with a new program called scantv. It prompts for standard and country and then does a scan of all channels. The problem is, it looks for a device called /dev/vbi, which doesn't exist. In FreeBSD, I can find out about devices from the man pages: for example, for a /dev/bktr I'll find a man page bktr(4). Linux, at least as I have installed it, has nothing corresponding. Google didn't help much either; the suggestion of creating a device with mknod based on major device numbers of several years ago didn't seem to be the right way to go. Finally found that there's a device called /dev/vbi0, so specified that instead, and it seemed to work. I still have no idea what /dev/vbi0 is. The name shows up in files like drivers/media/video/bttv-driver.c in the kernel, but it has almost no comments, certainly nothing to explain what vbi means.
The output of scantv was not surprising: I had no antenna cable connected, so at least for that reason it didn't find anything. I need to move it to where there's an antenna, but by the time I had got that far, I had no more time. Next week.
One useful source of information that I shouldn't discount is this diary; people read it and reply to me. Today on IRC, Olli Lehmann told me about the meaning of /dev/vbi. pointing to an article on zapping VBI. It explained the meaning of the name: “Vertical Blanking Interval”. Makes sense (the vertical blanking interval is often used to carry additional information). But what a way to find out.
More work on trying to get my TV tuners to work on ceeveear, the Ubuntu machine. It's still not easy. One of the strangest things I've seen has been that NFS mounting file systems from FreeBSD to Ubuntu takes 104 seconds per file system. Once mounted, access to the file system works fine. I suspected an incompatibility between the implementations, so spent some time running ethereal to try to work out what was going wrong, but that just showed a normal NFS mount operation followed by 104 seconds of nothing. The local (Ubuntu) /var/log/messages was more informative, but I no longer have the messages (see the end of today's entry); something about “unable to connect to localhost”. I suspect that it's a problem with the initial installation, but it happens on both machines (eucla, the laptop, and ceeveear, the TV machine).
The tuner was easier. I connected it to an antenna and answered the questions, and was gratified by:
=== root@ceeveear (/dev/pts/0) /home/grog 22 -> scantv -C /dev/vbi0
6 (175.25 MHz): no station
7 (182.25 MHz): ???
[unknown (7)]
channel = 7
8 (189.25 MHz): no station
9 (196.25 MHz): ???
[unknown (9)]
channel = 9
10 (209.25 MHz): ???
[unknown (10)]
channel = 10
11 (216.25 MHz): no station
That all looks correct: we do indeed have channels 7, 9 and 10. But according to the man
page,
DESCRIPTION
scantv scans a v4l device for available TV stations and writes a
xawtv/fbtv config file.
So where's xawtv/fbtv? Not in the cwd, nor in the home directory. Since it didn't
mention the pathname, decided that it might be somewhere else, and tried running xawtv
anyway. Nothing, but the man page said that the configuration file was called .xxawtv,
and not xawtv/fbtv. That wasn't there either. Ran scantv again and confirmed
that it didn't write any output file. Then I read more of the man page:
-o outfile
specify output file. If none is specified, scantv write to std-
out.
It turns out that the text in the example above is in fact the configuration information:
[unknown (7)] channel = 7Not that you can do anything with it like that; both the defaults and the man page are less than suitable.
Finally created a configuration file, and it selected channel 61 (conveniently, not occupied, so just noise on the screen), and discovered that I could not change channel: neither mouse nor keyboard worked. This seemed to be related to the messages it printed on startup:
This is xawtv-3.94, running on Linux/i686 (2.6.12-8-386) Warning: translation table syntax error: Unknown keysym name: XF86AudioRaiseVolume Warning: ... found while parsing '<Key>XF86AudioRaiseVolume: Command(volume,inc) ' Warning: String to TranslationTable conversion encountered errors Warning: translation table syntax error: Unknown keysym name: XF86AudioRaiseVolume Warning: ... found while parsing '<Key>XF86AudioRaiseVolume: Command(volume,inc) ' Warning: String to TranslationTable conversion encountered errors Warning: Cannot convert string "-*-ledfixed-medium-r-*--39-*-*-*-c-*-*-*" to type FontStruct Warning: translation table syntax error: Unknown keysym name: XF86AudioRaiseVolume Warning: ... found while parsing '<Key>XF86AudioRaiseVolume: Command(volume,inc) ' Warning: String to TranslationTable conversion encountered errorsOn another attempt, it found a different channel, one that was in use, and showed that it was, indeed, receiving TV. But it still didn't accept any mouse or keyboard input. So, possibly a forgotten dependency? That seems common in Linux—see the installation of mplayer. Looking for related packages, I found:
=== root@ceeveear (/dev/pts/0) /home/grog 26 -> apt-cache search xawtv
liblircclient0 - LIRC client library
came - Rewrite of the xawtv webcam app using imlib2
libvideo-capture-v4l-perl - Perl interface to the Video4linux framegrabber interface
pia - movie player
scantv - scan TV channels for stations
v4l-conf - tool to configure video4linux drivers
xawtv - X11 TV application
xawtv-plugin-qt - quicktime plugin for xawtv and motv
xawtv-plugins - plugins for xawtv and motv
xawtv-tools - Miscellaneous tools distributed with xawtv
libmjpegtools-dev - MJPEG video capture/editting/playback MPEG encoding
libmjpegtools0 - MJPEG video capture/editting/playback MPEG encoding
mjpegtools - MJPEG video capture/editting/playback MPEG encoding
So, which were installed and which not? What I wanted was the Linux equivalent of FreeBSD's pkg_info. Looking through the
documentation for apt-get and apt-cache, that didn't seem right. Neither did
the documentation for dpkg. So I went to the Ubuntu support site, which pointed me
to a quick tour and a start guide, neither of which I
wanted: I wanted a user guide. Looking on Google brought
me 102,000 hits for
"Ubuntu User Guide". The first
one looked good, but despite calling itself an “unofficial user guide”
(where's the official one?), it's a forum. Most of the other hits looked less than useful, so
I limited my search to PDF documents. One single hit, not from the
official Ubuntu site, and only 31 pages long, including table of contents, introductions and
disclaimers. It had some stuff on software installation, but still nothing on how to find out
which packages were installed.
OK, this system is laid out to work under GNOME, and there's a graphical program called synaptic. That produced its own error messages:
(synaptic:7099): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed (synaptic:7099): Gtk-CRITICAL **: gtk_accel_label_set_accel_closure: assertion `gtk_accel_group_from_accel_closure (accel_closure) != NULL' failed (synaptic:7099): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed (synaptic:7099): Gtk-CRITICAL **: gtk_tree_view_unref_tree_helper: assertion `node != NULL' failed
It also produced a ridiculously badly proportioned display, showing only the first third of the package category names, and that on a full screen 1600x1200 display. Fixed that, selected multimedia and looked for xawtv. Nothing. Also nothing in multimedia-multiverse and multimedia-universe. Only when I did a search for xawtv did I get a display that matched the list from apt-cache above, only alphabetically sorted. It showed that everything I could reasonably expect to install was already installed. So where is the problem? An hour of searching useless and non-existent documentation, and no closer to the solution.
At about this point, and not for the first time, I gave up. I decided that the hardware was working, but the software was not. I've had at least these problems with Ubuntu, and they shouldn't happen in a production release:
Anyway, I had just downloaded Fedora Core 5 from the Internode mirror server, so decided to try that on the spare partition (I always put two root partitions of 4 or 5 GB on my machines, and I only put system-related stuff on them, so that I can move from one release to another relatively easily. eucla even has three, two FreeBSD and a Linux, all of which share the same /home file system). Installed Fedora on ceeveear and was gratified by a much cleaner install. No problems with the meta-characters, NFS mounts Just Work, I now have a /dev/vbi, and I even found a MythTV HOWTO that seems to make sense, so followed that. Hopefully I won't run into Yet Another dead end.
Another interesting thing about GNOME is that I was able to get the top menu bar to display on wantadilla, my main machine, which runs fvwm2 as its standard window manager; this could be a good compromise between the GNOME menus and the flexibility of fvwm2. Today, though, it confused things: for some reason, it slowed down the repeat rate of the keyboard, and also disabled kbdcontrol, which should set the repeat rate. It also changed the input line editing on my local (wantadilla) firefox from Emacs-like to something Microsoft-like. But I know about that, and hopefully I'll be able to find a solution that is more convenient than anything I have so far.
Up early this morning with the intention to finally make progress with the Computer Video Recorder. I did make quite a bit of progress, but mainly towards getting functional Linux installations on ceeveear and eucla:
Following http://wilsonet.com/mythtv/fcmyth.php: For the SiS drivers for ceeveear, execute the following as root:
mkdir -p ~mythtv/sources/sis_drv cd ~mythtv/sources/sis_drv wget http://www.winischhofer.net/sis/sis_drv.o_xorg_gcc3_current.tar.gz tar -xzvf sis_drv.o_xorg_gcc3_current.tar.gz mv /usr/X11R6/lib/modules/drivers/sis_drv.o /usr/X11R6/lib/modules/drivers/sis_drv.o.orig cp sis_drv.o /usr/X11R6/lib/modules/drivers/sis_drv.oThe directory http://www.winischhofer.net/sis/ contains a very large number of similarly named files, which firefox conveniently truncates. sis_drv.o_xorg_gcc3_current.tar.gz appears to be the latest version (i.e. not a static content).
At this point, things went wrong. /usr/X11R6/ has only one directory in it, bin. Fortunately, Fedora seems to do the right thing by locate (or maybe I was just lucky that it gets done Saturday night; I can't work out the format of the periodic cron scripts). It shows:
=== root@ceeveear (/dev/pts/2) /home/mythtv/sources/sis_drv 35 -> locate sis_drv
/ubuntu/usr/X11R6/lib/modules/drivers/sis_drv.o
/usr/lib/xorg/modules/drivers/sis_drv.so
OK, rewrite that script:
mkdir -p ~mythtv/sources/sis_drv cd ~mythtv/sources/sis_drv wget http://www.winischhofer.net/sis/sis_drv.o_xorg_gcc3_current.tar.gz tar -xzvf sis_drv.o_xorg_gcc3_current.tar.gz mv /usr/lib/xorg/modules/drivers/sis_drv.o /usr/lib/xorg/modules/drivers/sis_drv.o.orig cp sis_drv.o /usr/lib/xorg/modules/drivers/sis_drv.oInterestingly, though, that's still not the same name:
So which do we take? Took a look at Thomas Winischhofer's SiS chipset overview, which was instructive. ceeveear has:=== root@ceeveear (/dev/pts/2) /home/mythtv/sources/sis_drv 41 -> l /usr/lib/xorg/modules/drivers/sis_drv*-rw-r--r-- 1 root root 597402 Apr 9 12:03 /usr/lib/xorg/modules/drivers/sis_drv.o -rwxr-xr-x 1 root root 609444 Feb 13 05:53 /usr/lib/xorg/modules/drivers/sis_drv.so=== root@ceeveear (/dev/pts/2) /home/mythtv/sources/sis_drv 42 -> file /usr/lib/xorg/modules/drivers/sis_drv*/usr/lib/xorg/modules/drivers/sis_drv.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped /usr/lib/xorg/modules/drivers/sis_drv.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
02:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 315PRO PCI/AGP VGA Display Adapter (prog-if 00 [VGA]
)
Subsystem: Silicon Integrated Systems [SiS] 315PRO PCI/AGP VGA Display Adapter
Flags: bus master, 66MHz, medium devsel, latency 39, IRQ 5
BIST result: 00
Memory at d0000000 (32-bit, prefetchable) [size=256M]
Memory at e5000000 (32-bit, non-prefetchable) [size=256K]
I/O ports at c000 [size=128]
[virtual] Expansion ROM at e4000000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Capabilities: [50] AGP version 2.0
On further investigation,
http://www.winischhofer.net/sis/sis_drv.o_xorg_6.9.0_gcc4_091205-1.tar.gz contains the
file /usr/lib/xorg/modules/drivers/sis_drv.so, and it's the correct version of Xorg, so I'll go for that.
While doing that, decided to set up the environment a bit better. One thing I definitely need is a window manager that I'm happy with, and that's pretty much fvwm2. Found the RPM and downloaded it, and was then forcibly reminded of why I didn't like Fedora:
=== root@ceeveear (/dev/pts/2) /home/mythtv/sources 102 -> rpm -i fvwm-2.5.13-1.i386.rpm
error: Failed dependencies:
libfribidi.so.0 is needed by fvwm-2.5.13-1.i386
libreadline.so.4 is needed by fvwm-2.5.13-1.i386
libstroke.so.0 is needed by fvwm-2.5.13-1.i386
libXft.so.1 is needed by fvwm-2.5.13-1.i386
Spent a bit of time following up these references before it dawned on my that I was being silly. Some of these were missing simply because they were out of date. What I should have been doing was building from source—after all, when it comes to porting, I wrote the book. That worked relatively simply. Getting it to actually work was more complicated; I need to read more about GNOME.
At this point, the instructions became quite complicated, and I first need to read both them and the MythTV documentation to understand what needs to be done. The good news appears to be that there's a generic IR remote control application, which will make things much easier. But that's for another day. Tried installing xawtv, but again ended up with a maze of twisty little unfulfilled dependencies, all different. An attempt to build xawtv from source also failed, since I first needed to install the Xorg sources. Put that in the “too hard” basket.
Input from James Andrewartha on the topic of my Ubuntu woes. More in my diary, but this relates to CVRs:
Due to the way Linux development works, a lot of device information is only located in Documentation/ in the kernel source. DocBook/videobook.tmpl contains the following:
<entry>VFL_TYPE_VBI</entry><entry>/dev/vbi{n}</entry><entry> The VBI devices capture the hidden lines on a television picture that carry further information like closed caption data, teletext (primarily in Europe) and now Intercast and the ATVEC internet television encodings.</entry>
Back to looking at CVR software. Last Sunday I had got to the stage where I couldn't install xawtv on Fedora Core 5: the binary package had a missing dependency on libXm.so.3, and the source didn't build with some missing header files.
Investigated both. For libXm.so.3, the obvious choice was to find a yum repository with the library. It seems, though, that there are no lists of yum repositories—some of the web pages I found even seemed proud of the fact. Found a watch4tv page, which doesn't say so but appears to be a list of instructions to install a TV application on an operating system that uses yum. That was helpful, but didn't get me past the basic problem:
=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 48 -> rpm --import http://dag.wieers.com/packages/RPM-GPG-KEY.dag.txt=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 49 -> rpm --import http://ftp.osuosl.org/pub/centos/RPM-GPG-KEY-CentOS-4=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 50 -> yum install xawtvLoading "installonlyn" plugin ... --> Running transaction check --> Processing Dependency: libXm.so.3 for package: xawtv --> Finished Dependency Resolution Error: Missing Dependency: libXm.so.3 is needed by package xawtv=== root@ceeveear (/dev/pts/1) /src/FreeBSD/ports/distfiles 51 ->
Confirmed that I had a /usr/lib/libXm.so.4, but symlinking that to /usr/lib/libXm.so.3 didn't get me past the problem. Went back to the issue of building from source; further investigation showed that the missing header file belonged to the X font server, and that xawtv, though it uses autoconf, didn't seem to notice that the X libraries were not installed. Installing that made it build and brought instant gratification:
That's the TV image in centre left: it's tiny by itself:
It is indeed smaller than it should be, only 394x314. That's something to investigate, but the real issue was to get it to run on ceeveear. That didn't work as well:
=== grog@ceeveear (/dev/pts/11) ~ 3 -> DISPLAY=:0 xawtv
This is xawtv-3.95, running on Linux/i686 (2.6.16-1.2080_FC5)
/dev/video0 [v4l2]: ioctl VIDIOC_G_FBUF: Invalid argument
v4l-conf had some trouble, trying to continue anyway
ioctl: VIDIOC_G_FBUF(capability=0x0 [];flags=0x0 [];base=(nil);fmt.width=0;fmt.height=0;fmt.pixelformat=0x00000000 [....];fmt.field=ANY;fmt.bytesperline=0;fmt.sizeimage=0;fmt.colorspace=unknown;fmt.priv=0): Invalid argument
That looks like a problem with the X configuration; maybe the HOWTOs will help there. Also
the program scantv that I used last week under Ubuntu is no longer built by default;
the sources are there, but when I try to compile them, I get lots of errors. More stuff to
investigate. This whole exercise reminds me of when I was writing Porting UNIX Software well over ten years ago. Why
do these problems still exist?
Yvonne back with more mushrooms today, along with the information that she had met some Polish women in the forest who were gathering large quantities. They offered to tell her the name in Polish, but she didn't bother. I sent a message out to an internal MySQL list and got answers from Mårten Mickos and Boel Larsen, who both apparently eat them and tell me, as did Alexander Keremidarski, that they're not boletus pinophilus, but suillus luteus, called smörsopp in Swedish and maslovka in Bulgarian (also Butterpilz in German), all of which mean the same thing. Certainly the photo looks convincing enough. They need peeling, apparently, and there are some indications of people who get stomach upsets from them, possibly only if the skin is not removed.
Today continued my attempts to install MythTV. First continued with xawtv, though, and looked for scantv, which I have used before. It wasn't there. There's no target for scantv in the top-level directory, but there's a file console/scantv.c that won't compile in that directory:
=== root@ceeveear (/dev/pts/1) /usr/src/ports/xawtv-3.95/console 14 -> make scantv
cc scantv.c -o scantv
scantv.c:5:20: error: config.h: No such file or directory
scantv.c:19:25: error: frequencies.h: No such file or directory
(etc)
Presumably config.h was in the top-level directory, so tried it there; it got a bit further:
=== root@ceeveear (/dev/pts/1) /usr/src/ports/xawtv-3.95 16 -> make console/scantv
CC console/scantv.o
console/scantv.c:47: warning: 'struct vbi_event' declared inside parameter list
console/scantv.c:47: warning: its scope is only this definition or declaration, which is probably not what you want
With a bit of investigation (including far too much guesswork), established that this related to libzvbi, and that the corresponding package was called zvbi. Installed that and zvbi-devel, but scantv still didn't compile. It looked as if the header files weren't being found; but which header files? Spent some time trying to get yum to tell me which files were associated with the packages that were installed (something like FreeBSD's pkg_info -f), but that doesn't seem to exist. It was also strange that scantv.c didn't complain about missing header files. Then it dawned on me: configure was run without the libraries being present, so it decided not to build the programs. Re-ran configure and all got built.
Next was the problem with saving the config file. I had already discovered that scantv writes its output to stdout; but what's the real config file called? xatwv(1) refers to the file several times, but refuses to divulge its name. That's in xawtvrc(1): it's called ~/.xawtv, a funny name considering the name of its man page.
Finally moved on to lirc, the Linux Infrared Remote Control software. That was a new level of incomplete, inaccurate, incorrect and confusing documentation. According to one page, I should try irrecord to find out what the control said. That resulted in:
=== root@ceeveear (/dev/pts/0) ~ 219 -> irrecord foo
irrecord - application for recording IR-codes for usage with lirc
Copyright (C) 1998,1999 Christoph Bartelmus(lirc@bartelmus.de)
irrecord: could not init hardware (lircd running ? --> close it, check permissions)
Well, lircd wasn't running, so I tried strace:
=== root@ceeveear (/dev/pts/0) ~ 220 -> strace irrecord foo 2>&1 | less
open("/dev/lirc", O_RDWR) = -1 ENODEV (No such device)
What kind of programming is that? It doesn't even check the return value from open!
Of course, I don't have the source, so I can't do the obvious two-line fix, and getting it is
liable to cause other problems.
In the middle of this, ran into another problem: the dreaded NFS hangs, this time between ceeveear and wantadilla. I had to reboot ceeveear to get out of it, and then X wouldn't start: the font server kept crashing. strace didn't show anything of interest, so modified the X configuration to load the fonts directly (why are they stored in /usr/share/X11/fonts and not in the usual /usr/X11R6/lib/X11/fonts? Is this a change that came with X11R7?).
After starting X again, discovered that I also no longer had a window manager. That was GNOME anyway, something I don't need, so changed the init level to 3 and started fvwm2 manually, the way I'm used to do it.
Then continued for a while, discovering that my tuner card (MSI “TV@nywhere Master”—where do they get these names from?) probably required a kernel module (I was left to guess which one), and that lircd require a “driver” (again, though there's an entry for my remote control, there's no information about which driver to use). Finally went through with a brute force search and found that a number of them worked, including at least bte and dsp. Of course, they only understood some of the keys; for tomorrow I need to investigate how to decipher the keys.
For the fun of it, tried to run xawtv again. The results were startling: the X server crashed with a SIGSEGV and a backtrace:
Backtrace: 0: X(xf86SigHandler+0x87) [0x80b86c7] 1: [0x675420] 2: [0x5] 3: /usr/X11R6/lib/libXfont.so.1 [0x14e9ed] 4: /usr/X11R6/lib/libXfont.so.1(FontFileListNextFontWithInfo+0x747) [0x121ecb] 5: X(doListFontsWithInfo+0x24c) [0x808b5fc] 6: X(StartListFontsWithInfo+0x145) [0x808bbd5] 7: X(ProcListFontsWithInfo+0x6b) [0x808705b] 8: X(Dispatch+0x19b) [0x80888eb] 9: X(main+0x487) [0x80701d7] 10: /lib/libc.so.6(__libc_start_main+0xdc) [0x6a87e4] 11: X(FontFileCompleteXLFD+0xb1) [0x806f511]
I wonder if the NFS crash somehow ended up corrupting some of the font files. I've never seen that on FreeBSD, but I've heard of it on Linux, and recently I've been experiencing lots of things I have never seen before. The overall fragility of this system is horrifying, a far cry from the claims of absolute stability that the die-hard “Open Source” advocates make.
Tried more stuff with lirc, but it didn't behave as described in the “manual” (not the man pages; that would be too simple. Instead it's on the web). After several readings of this document, I still don't know what to do.
Finally downloaded the source, which also required the kernel sources. ./configure was a surprise: I got a menu asking me which tuner card to compile for (and of course my TV@nywhere wasn't on the list). Somehow it's possible to generate the programs with all “drivers”, but it's not made clear how. It's also full of references to other documentation, which in turn leads on to yet other documents, none of which seem relevant. After following the instructions, I ended up with the Makefile configured only for a serial connection. After a lot of investigation, I found:
1. Which kernel module do I have to load for my hardware?The documentation contains a detailed list how to setup the various devices supported by LIRC.
Somehow I then found my way to the installation instructions at http://www.lirc.org/html/install.html#compiling, which state:
See ./configure --help for a detailed description of the possible parameters. You will have to at least choose a driver with the --with-driver=X option.That worked: ./configure finished with the message
All kernel modules will be built.Of course, it didn't compile:
/usr/src/ports/lirc-0.8.0/drivers/lirc_atiusb/lirc_atiusb.c:1183: error: unknown field 'owner' specified in initializer /usr/src/ports/lirc-0.8.0/drivers/lirc_atiusb/lirc_atiusb.c:1183: warning: initialization from incompatible pointer type make[5]: *** [/usr/src/ports/lirc-0.8.0/drivers/lirc_atiusb/lirc_atiusb.o] Error 1
Round about here something strange occurred to me: the system was responding to the IRC control even when there was no lirc program running! Further investigation showed that there was a kernel module ir_common, and trawling the kernel sources showed that the driver does indeed understand the remote control interface; found some useful information at LinuxTV.org, which enabled me to—finally!—configure the thing.
The next step was easy: install MySQL. Including setting up the MythTV databases, it took about a minute. The next step, mythtvsetup, looked complicated enough that I decided that it would be better to put it off until tomorrow.
On with the pain that is MythTV. Started writing a HOWTO so that I'll find my way better next time. That might be sooner than I expect: I got as far as the step Run mythtvsetup. It's not a very clever program:
=== mythtv@ceeveear (/dev/pts/2) ~ 3 -> mythtvsetup
mythtv: could not open config file /home/mythtv/.mythtv/lircrc
mythtv: No such file or directory
Failed to read lirc config /home/mythtv/.mythtv/lircrc for mythtv
2006-04-20 13:17:48.215 Joystick disabled.
2006-04-20 13:23:51.491 DB Error (simpledbstorage update):
Query was:
No error type from QSqlError? Strange...
2006-04-20 13:27:35.911 RecordFilePrefix is not set?
I wonder what all that means. It's the first I've seen of a ~/.mythtv/lircrc.
Running strace showed what you might expect:
open("/dev/video0", O_RDWR|O_LARGEFILE) = -1 EACCES (Permission denied)
I feel like screaming! Why can't people report errors any more? But even after I fixed the permissions on all likely devices, mythtvsetup could not access the card. Tried to run xawtv again. It still crashes the local X server, though (modulo network speed) it works fine on wantadilla. Discovered that even on wantadilla, xawtv didn't work for user mythtv; it just displayed noise. Copying ~grog/.xawtv to ~mythtv helped, but only after an explicit channel change. This software is so buggy!
Decided to test my installation instructions and possibly get rid of some crashes by installing Fedora Core 5 again on a new (well, very old, but overwriteable) disk. In the process, various niggles became apparent:
KnoppMyth states at several occasions on the way that it's experimental beta software; most versions of Knoppix (from which it is derived) do something similar. In each case, they're wrong; Knoppix is surprisingly stable and, bar the horrible eye candy, not at all a bad installation. KnoppMyth is barely alpha quality. The installation scripts forgot the passwords I entered and chopped the first characters off each IP address. They then put me back in the same position I was earlier in the day; the only advantage was that failure came more quickly.
Very frustrated, gave it up for the day. This is not merely a question of compatibility, as some people say; it's a question of really badly written software. Not checking system call return values is a sure course for disaster.
On trying to debug ceeveear today. There's definitely something wrong with the installation for Fedora Core 5: I went to some trouble to specify that the X11 sources should be installed, but they weren't. Emacs was also missing, but it's possible that the packager is a vi bigot and left Emacs out of the default editor installation.
Finally got it installed, along with all the bits and pieces needed to build xawtv. It didn't crash the X server, but it did the same thing as KnoppMyth—blank screen and lots of ioctl error messages:
ioctl: VIDIOC_TRY_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=21;fmt.win.w.top=53;fmt.win.w.widt h=384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win.clips=(nil);fmt.w in.clipcount=0;fmt.win.bitmap=(nil)): Invalid argument ioctl: VIDIOC_S_FMT(type=VIDEO_OVERLAY;fmt.win.w.left=21;fmt.win.w.top=53;fmt.win.w.width= 384;fmt.win.w.height=288;fmt.win.field=ANY;fmt.win.chromakey=0;fmt.win.clips=(nil);fmt.win .clipcount=0;fmt.win.bitmap=(nil)): Invalid argument ioctl: VIDIOC_OVERLAY(int=0): Invalid argumentIt did this at each attempt to change channel; paradoxically, though there was no image in the main window, it displayed an image in the channel window, suggesting that there's some issue with the phone.
That left the question why the X server crashed before. Installed the new, corrected xorg.conf file and the new driver and—it crashed! So it wasn't something I did with the installation on the “old” version of ceeveear.
In the meantime I had downloaded a CD of FreeBSD 6.1-RC1, so installed that on a spare partition, in the process finding out again how to boot FreeBSD from grub:
title FreeBSD 6.1-RC1
root (hd0,0,a)
kernel /boot/loader
The important thing to remember here is that “hd0, 0, a” corresponds to the FreeBSD name ad0s1a; the BIOS partition numbers are off by 1. This isn't what Fedora puts in by default, and it had caused me problems booting eucla, my laptop.
It ran (of course), but didn't detect the tuner, as I expected, so I still need to continue with Linux.
Rebooted the “old” ceeveear and played around with xorg.config. The old one didn't work at all, of course, because it relied on xfs (font server; what a confusing name), which kept crashing. After much trial and error, discovered that the crashes occurred only when Type 1 fonts were used, this entry:
FontPath "/usr/share/X11/fonts/Type1/"
Without that, it ran fine and displayed the same ioctl problems as KnoppMyth and the
“new” Fedora installation. So it looks like it's a display card problem. Spent
some time investigating that, without coming to a conclusion.
Funnily, there seem to be multiple issues with xawtv. It continues to run across the network on echunga and wantadilla, my main machines in the office; but it won't run on teevee, the machine that (currently) drives the projector, also a FreeBSD machine. Another thing that I don't understand.
Spent more time searching for the ioctl errors that had been annoying me yesterday, and got quite a few results on Google. Many reported the bug and got no solution. Some reported fixes that were really workarounds (use a different tuner card, for example). Michael Krufky reported that it was a kernel bug in Linux 2.6.15-rc2 and before; unfortunately, I'm still getting it in kernel 2.6.16. Finally, Hermann Pitton came up with a plausible explanation: the driver doesn't support overlay with PCI/PCI transfers to the graphics card. That would explain why it only happened when displaying on the same machine. But why can't there be a better error message?
Hermann recommended to use xawtv grabdisplay and referred to a file called README.cx88 without saying where to find it. It wasn't on ceeveear, and it's not in the xawtv distribution; nor is there more than a passing reference to it in the documentation. More googling suggested that it's in the Linux kernel sources, and indeed I found it there on echunga. But there's no mention of grabdisplay in that file, just the comment “For now only capture, overlay support isn't completed yet.”.
Found a reference to a program called tvtime, and installed that. Oh wonder! It just worked. Well, I had to read through the config file that was supplied, and it got a bit confused about the channel numbers, but it worked, modulo sound, which doesn't seem to be an tvtime problem: it doesn't work at all yet. About the only thing wrong with it is that it only displays TV. If only more software were of this quality.
Spent some time investigating the sound issue. According to man -k, there isn't much choice in mixer software:
=== root@ceeveear (/dev/pts/3) ~ 46 -> man -k mixer
alsamixer (1) - soundcard mixer for ALSA soundcard driver, with ncurses interface
alsamixergui (rpm) - GUI mixer for ALSA sound devices
amixer (1) - command-line mixer for ALSA soundcard driver
dump-mixers (1) - dump OSS mixer settings to standard output
I suppose there's more, but how do you find it? They could at least have extended man to show what other documentation is available.
Running alsamixer brought a message that I've seen before:
=== grog@ceeveear (/dev/pts/6) ~ 6 -> alsamixer
alsamixer: function snd_ctl_open failed for default: No such device
What device? Are people deliberately trying to make it more difficult? strace
revealed:
access("/home/grog/.asoundrc", R_OK) = -1 ENOENT (No such file or directory)
open("/dev/snd/controlC0", O_RDONLY) = -1 EACCES (Permission denied)
open("/dev/aloadC0", O_RDONLY) = -1 ENOENT (No such file or directory)
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f69000
write(2, "alsamixer: function snd_ctl_open"..., 68alsamixer: function snd_ctl_open failed for default: No such device
) = 68
After fixing the permissions, it seemed to work, but it wasn't very easy to understand. Tried
the HELP menu, which told me:
Return return to main screen
That doesn't work, so I of the help menu. tried ESC. That got me out quickly:
=== grog@ceeveear (/dev/pts/5) ~ 2 -> alsamixergui &[2] 5465=== grog@ceeveear (/dev/pts/5) ~ 3 ->Segmentation fault.
I think I'm going to modify that message from bash to
Segmentation fault (too lame to dump core).By default, a SIGSEGV creates a core image; if it doesn't, it's because the program has explicitly decided not to. Considering that much of this software is of early alpha quality, this just makes it even more difficult to debug. Decided to read the documentation again before doing anything else, and returned to trying mythtvsetup again.
After 5 minutes of swearing at the completely broken interface (right arrow moves left, left arrow moves right, cursor not visible), gave up and looked for a simpler way, like writing a program to do it or encoding it in hex. I didn't find one, so here's a list of things to remember:
In parallel with the other work, started downloading the latest (DVD) version of Knoppix from the Internode mirror server; contrary to my normal use of command lines, I this time allowed firefox to do it. That always annoys me, because firefox is just completely stupid about path names; it started downloading to Desktop, which on this machine proved to equate to /var/tmp. There was enough space there, so I let it go. Some hours later I found it had stopped:
=== grog@echunga (/dev/ttypl) /var/tmp 57 -> l KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso
-rw-r--r-- 1 grog wheel 2147483647 Apr 22 15:07 KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso
That wasn't the real size, of course; the download had stopped at the 2 GB limit. Grr. And
because I was loading from a web server, I couldn't use REGET. Looked around on the
web and found alternatives, and started that transfer, somewhat slower (50 kB/s instead of
150 kB/s).
Came into the office to discover that my Knoppix download was still going:
ftp> reget KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso local: KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso remote: KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso 229 Entering Extended Passive Mode (|||61749|) 350 Restart position accepted (2147483647). 150 Opening BINARY mode data connection for KNOPPIX_V4.0.2DVD-2005-09-23-EN.iso (3344640000 bytes). 91% |********************************************************************** | 2918 MB 13.16 KB/s 5:51:43 ETA
That's nearly 24 hours. Network transfer speeds may have increased, but so have download volumes. Did some investigation and discovered that the Internode mirror server also has an ftp interface, so finished off the transfer from there.
Today was the last day of a ten day period during which I had intended to do a number of things; just about all of it was spent fighting Linux multimedia, and I'm still far from finished. The current biggest problems are:
Another holiday today, so spent more time torturing myself with multimedia setup. A package that I haven't tried so far is VLC, so set to trying that out. Found a detailed (and somewhat opinionated) description by Brent Norris, which required a complete kernel upgrade. That didn't go well. Once again dl.atrpms.net was not accessible. It's a real pain that you can't tell yum to ignore it; it causes the entire update to fail, even if you tell it to tolerate errors. I had to move the file away (yes, I know you can also disable it, but it's easier and less error prone to move it). Even then, I got messages like this:
--> Running transaction check --> Processing Dependency: libgif.so.4 for package: libgdiplus --> Processing Dependency: libgif.so.4 for package: emacs --> Processing Dependency: libgif.so.4 for package: gfontview --> Finished Dependency Resolution Error: Missing Dependency: libgif.so.4 is needed by package libgdiplus Error: Missing Dependency: libgif.so.4 is needed by package emacs Error: Missing Dependency: libgif.so.4 is needed by package gfontviewBut Emacs was installed, for example, and so was libgif.so.4. While experimenting, removed Emacs:
Then, later, it happens again:=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 64 -> yum remove emacs... Removing : emacs ######################### [1/1] Removed: emacs.i386 0:21.4-14 Complete!=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 65 -> yum install emacs... Installing: emacs i386 21.4-14 core 1.6 M ... Installed: emacs.i386 0:21.4-14 Complete!
... --> Finished Dependency Resolution Error: Missing Dependency: libgif.so.4 is needed by package libgdiplus Error: Missing Dependency: libgif.so.4 is needed by package emacs Error: Missing Dependency: libgif.so.4 is needed by package gfontviewThere's obviously something very wrong here, but it's not clear what I can do about it. Later I got, after downloading 230 MB of packages:
(162/165): firefox-1.5.0. 100% |=========================| 17 MB 02:42
(163/165): mythvideo-0.19 100% |=========================| 470 kB 00:04
(164/165): libksba-0.9.13 100% |=========================| 2.2 kB 00:00
(165/165): mythweb-0.19-7 100% |=========================| 602 kB 00:05
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
[('installing package firefox-1.5.0.2-1.2.fc5 needs 17MB on the / filesystem', (9, '/', 17469440L)),
('installing package mythweb-0.19-74.at needs 17MB on the / filesystem', (9, '/', 17485824L))]
No idea what that is. Checked things, but it wasn't obvious:
So it wasn't a lack of space. The annoying thing is that yum appears to insist on downloading every package every time; presumably they're already on the system. With 230 MB at a time, it takes a while, and it could become expensive. Ended up installing some of the larger packages individually; I think in future I'll always do it that way.=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 71 -> echo $?1=== root@ceeveear (/dev/pts/2) /ubuntu/home/grog 73 -> dfFilesystem 1M-blocks Used Available Use% Mounted on /dev/hda2 5540 4865 389 93% / tmpfs 506 0 506 0% /dev/shm /dev/hda1 5629 2487 2856 47% /ubuntu /dev/hda4 175495 9212 157369 6% /spool
That still didn't help too much, of course, since dl.atrpms.net was still not accessible. Tried some other things and with a lot of effort more or less got mplayer to display on the screen, something that tvtime had done out of the box.
=== grog@ceeveear (/dev/pts/1) ~ 3 -> mplayer -tv driver=v4l2:normid=2:width=960:height=720:chanlist=australia:\
channels=2-ABC,7-Seven,9-Nine,10-Ten,28-SBS:outfmt=yuy2:brightness=70:saturation=90:hue=50 -vo x11 tv://5
Unfortunately, getting the companion mencoder to make MPEG files out of that didn't
work: mplayer claimed that the result was not a valid MPEG stream. What a crock!
Other events included installing the DVB-T tuner that I borrowed from Ben Kramer on Thursday, along with c't magazine's Debian “VDR” software. I think this stands for “Video Disk Recorder”, a term which doesn't make much sense to me: where's the video disk? I prefer to use the more descriptive term “CVR” (“Computer Video Recorder”). That hung up a surprising number of times; I wonder if the motherboard is getting even flakier. And why does Debian load the floppy driver three times in the course of installing on a system that doesn't have a floppy drive?
Spent the morning writing up some recipes, then continued trying to install c't magazine's “VDR” software. I think there must be a conspiracy amongst authors of multimedia software to avoid documentation; once again, and unexpectedly for c't, the documentation was almost completely missing. During the installation I had to choose a transmitter profile, and of course they were only available for Germany (I didn't even see Switzerland or Austria). The on-screen instructions (all that I ever found) said that they could be changed afterwards, so chose one at random. At the end of the installation, the terminal under Alt-F8 was supposed to have the application; but it just produced a text-mode message saying (roughly) “this screen reserved for DVR”.
Spent a lot of time investigating and discovered:
Configuration information is spread widely throughout the wiki, so this page is just first aid for finding where to start searching.It then points to the user handbook, which starts by describing how to use the software in everyday situations. I still haven't found anything that describes initial setup.
Also tried KnoppMyth again. This time the installation failed consistently with an error in an installation script. I'm not sure what I did differently, but given my previous experiences, I couldn't be bothered trying more than 4 times. Gave up in disgust. This is all far more complicated than it needs to be.
Put the new motherboard in ceeveear. It's not at all new; in fact, it's so old that it can't correctly identify the Athlon XP+ 2500 processor that I'm using, and it runs at half speed. I've also had to scrape up some SDRAM because it doesn't take DDR. But it runs, and the hangs I had before no longer occur. I still couldn't get the “VDR” software to do anything useful, though, and this brain-dead setup is such a pain that I gave up after installing X and discovering that the configuration routines couldn't recognize my nVidia 6200-based board and wanted all the horrible configuration rigmarole that you used to have to supply years ago.
Tried KnoppMyth, which installed this time (another difference from two weeks ago), but it forgot to install the boot loader. What a pain this stuff is! Installed FreeBSD 6.1-PRERELEASE and started building -STABLE: at the speed this processor is running, it took the rest of the day before hanging on NFS access to echunga. That never used to happen.
More work on ceeveear, the computer video recorder that I'm trying to build. Got a fractionally newer version of KnoppMyth, which refused to exit the partition menu during a manual install. Gave up on that, grabbed another (“empty”) disk and installed on that using the “automatic” install. That worked, and it even recognized my nVidia 6200-based card and installed a driver on it which set contrast so flat that I could barely recognize anything. Put in an nVidia 4000-based card and it worked. MythTV still has one of the strangest user interfaces I have ever seen, and I still wasn't able to get it to “open” the video card. xawtv found it (though at the time I didn't have an antenna connected), so it looks like my next job is to learn how to set up MythTV.
Daniel O'Connor along in the afternoon to pick up a tuner, some Weihenstephan W68 yeast and the old iiyama monitor that I retired on Thursday. In turn he brought an AMD Duron 800 processor, still mounted on a motherboard of dubious quality:
After that, finally got the motivation I needed to continue with the work on the video recorder project. The last time I tried this was only barely less frustrating than the previous attempts, though there were signs that it might be more promising. On IRC and the LinuxSA mailing list I had got some suggestions to try tzap, which was typical of the documentation standards for multimedia programs:
So I went googling for tzap and finally found a wiki page describing it; it seems that I couldn't use it until I had run dvbscan, which of course also had no documentation, and even the wiki page was pretty cursory. It did tell me that I needed a list of local transmitters, though.=== root@ceeveear (/dev/ttyp2) /myth/Images 11 -> tzapusage: tzap [options] <channel_name> zap to channel channel_name (case insensitive)=== root@ceeveear (/dev/ttyp2) /myth/Images 12 -> man tzapNo manual entry for tzap=== root@ceeveear (/dev/ttyp2) /myth/Images 13 ->
Based on the information, extrapolated a file name au-Adelaide, went googling again, and to my surprise discovered indications that I should already have the file on the machine; and I did:
=== root@ceeveear (/dev/ttyp1) ~ 26 -> locate au-Adelaide | xargs ls -lrt
-rw-r--r-- 1 root root 363 Apr 29 2005 /usr/local/share/dvb/dvb-t/au-Adelaide
-rw-r--r-- 1 root root 4000 Sep 24 2005 /usr/local/share/dvb/zap/dvb-t/au-Adelaide
-rw-r--r-- 1 root root 363 Sep 24 2005 /usr/local/share/dvb/scan/dvb-t/au-Adelaide
With a bit of playing round, got the tuner to work and copy MPEG data to disk. To get that far, I needed:
=== root@ceeveear (/dev/ttyp1) /myth/Images 58 -> dvbscan \
/usr/local/share/dvb/scan/dvb-t/au-Adelaide > channels.conf
(limiting even more voluminous output)
scanning /usr/local/share/dvb/scan/dvb-t/au-Adelaide
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder 226500000 1 3 9 3 1 1 0
...
>>> tune to: 226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRA
NSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE
Network Name 'ABC Adelaide'
0x0000 0x0250: pmt_pid 0x0102 ABC -- ABC HDTV (running)
0x0000 0x0251: pmt_pid 0x0100 ABC -- ABC TV Adelaide (running)
0x0000 0x0252: pmt_pid 0x0101 ABC -- ABC2 (running)
>>> tune to: 177500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRA
NSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE
0x0000 0x0550: pmt_pid 0x0500 Seven Network -- 7 Digital (running)
0x0000 0x0554: pmt_pid 0x0540 Network Seven -- 7 HD Digital (running)
...
>>> tune to: 571500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_2_3:QAM_64:TRAN
SMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE
WARNING: >>> tuning failed!!!
(many more such message)
...
dumping lists (28 services)
Done.
It's not clear what the error messages at the end mean; I couldn't find anything corresponding in the input file, and dvbscan found everything I expected it to find.
Find the names of the channels from the channels.conf file. This file is a typical UNIX colon-delimited file, and the channel name is the first field:
ABC HDTV:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:... ABC TV Adelaide:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:... ABC2:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:... ABC TV:226500000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_3_4:QAM_64:... (etc)
Once again spaces in names rear their ugly head; it is possible, though, to write abc hdtv: it obviously does a case-insensitive search. The indication FE_HAS_LOCK at the end of the lines indicates that the station is “tuned”, and the -r option enables recording output via /dev/dvb/adaptor0/dvb0 (in this case; the values of 0 may vary).=== root@ceeveear (/dev/ttyp1) /myth/Images 60 -> tzap -r ABC HDTVusing '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/root/.tzap/channels.conf' ERROR: could not find channel 'ABC' in channel list=== root@ceeveear (/dev/ttyp1) /myth/Images 61 -> tzap -r "ABC HDTV"using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' reading channels from file '/root/.tzap/channels.conf' tuning to 226500000 Hz video pid 0x090a, audio pid 0x0000 status 00 | signal 92ef | snr 0000 | ber 00000000 | unc 00000000 | status 1f | signal aabf | snr aeae | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal a93f | snr aaaa | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal a96f | snr afaf | ber 00000000 | unc 00000000 | FE_HAS_LOCK status 1f | signal aa5f | snr adad | ber 00000000 | unc 00000000 | FE_HAS_LOCK (continues with about one message per second)
From another xterm, copy the data to disk:
=== root@ceeveear (/dev/ttyp2) /myth/Images 13 -> cat /dev/dvb/adapter0/dvr0 > abchdtv.mpeg
Today messed around trying to get MythTV working. As expected, it wasn't as simple as it should have been. Although they're mentioned on the web site, tzap and friends have nothing to do with MythTV, and the files they use are of no use in setting up MythTV. In addition, the documentation is very weak; it doesn't really tell you what you need to know to configure the tuners. From mythtv-setup, fortunately started from an xterm, I discovered that the cause of the hang was that it started a command on the xterm. I wonder where that would have gone if it had been started from the window manager.
Grab listings for which region? 0: ACT - Canberra 1: NSW - Regional 2: NSW - Sydney 3: NT - Darwin 4: NT - Regional 5: Queensland - Brisbane 6: Queensland - Regional 7: SA - Adelaide 8: SA - Regional 9: Tasmania - Hobart 10: Tasmania - Regional 11: Victoria - Melbourne 12: Victoria - Regional 13: WA - Perth 14: WA - Regional Select one: [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 (default=3)] 7 Grab listings for which service? 0: Austar Analogue 1: Austar Digital 2: Foxtel Analogue 3: Foxtel Digital 4: Free to Air 5: Free to Air Digital 6: Free to Air Digital (High Definition) 7: Optus Select one: [0,1,2,3,4,5,6,7 (default=4)] 6 ERROR: can't find DataSet for Adelaide - freehd 2006-07-09 16:45:54.198 tv_grab_au --config-file '/root/.mythtv/Tuner-1.xmltv' --configure 2006-07-09 16:45:54.198 exited with status 65280All I managed to do was 4 (“Free to Air”), which gave me a file ~/.mythtv/Tuner-1.xmltv with the following contents:
# tv_grab_au 0.6.2 config file region Adelaide service free # "channel name" and "frequency" can be changed to suit # [+yes/-no] [channel ID] [channel name] [frequency] +channel free.Adelaide.10 "Network TEN" 10 +channel free.Adelaide.2 "ABC SA" 2 +channel free.Adelaide.7 "Channel Seven" 7 +channel free.Adelaide.9 "Channel Nine" 9 +channel free.Adelaide.SBS "SBS" 28That's clearly analogue. I couldn't find any way to get the digital signals. The same happened with “Free to Air Digital (High Definition)”. Gave up and sent a message to the local mailing lists asking for help.
Trying to configure mplayer to display the data I copied yesterday was no better. mplayer did completely different things depending on where it was started from and where it displayed. In all cases, I got the error message:
VDec: vo config request - 720 x 576 (preferred csp: Mpeg PES) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. VDecoder init failed :(This, though, is just “ha ha, only joking”; it doesn't stop mplayer from working. What I got depended on where I ran the program and where I directed the output:
Checking audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le... AF_pre: 48000Hz/2ch/s16le AO: [oss] 48000Hz 2ch s16le (2 bps) Building audio filter chain for 48000Hz/2ch/s16le -> 48000Hz/2ch/s16le... Starting playback... VDec: vo config request - 720 x 576 (preferred csp: Planar YV12) Could not find matching colorspace - retrying with -vf scale... Opening video filter: [scale] The selected video_out device is incompatible with this codec. FATAL: Could not initialize video filters (-vf) or video output (-vo).
This is the configuration in which I've been watching video from DVD for about a year; normally I see:
VDec: vo config request - 352 x 576 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) VO: [xv] 352x576 => 1280x900 Planar YV12 [fs] [zoom] Shared memory not supported Reverting to normal Xv Shared memory not supported Reverting to normal Xv A: 1.5 V: 1.5 A-V: 0.017 ct: 0.075 34/ 34 7% 40% 16.0% 0 0The only difference I see here are the chosen output dimensions.
By comparison, the same program output the same file on wantadilla:
VDec: vo config request - 720 x 576 (preferred csp: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.78:1 - prescaling to correct movie aspect. VO: [xv] 720x576 => 1024x576 Planar YV12 Shared memory not supported Reverting to normal Xv Shared memory not supported Reverting to normal Xv A:22773.9 V:22772.8 A-V: 1.084 ct: 0.020 26/ 26 21% 245% 5.4% 22 0
Only here, the aspect ratio was messed up, apparently by a factor of 2 to 1.
Finally, in the evening, I tried looking at the
Audio: no soundThis turned out to be because of the -alang en parameter that I also provided; that works for DVDs, but not for the input stream, but I didn't find that out until later. Wouldn't a descriptive error message be good?
As usual when writing up my diary entry for the previous day, I tried reproducing some of the problems I had, in this case including the inability to set the channels. To do so, I started mythtv-setup on wantadilla:0.0, the 2048x1536 display. This takes forever! So did key presses, with the result that I accidentally selected the wrong entry, didn't notice it, and found myself in the channel scan menu. Despite all the error messages from yesterday, it seems that it had found the information it needed, and it was able to perform a (surprisingly slow) channel scan and locate the channels:
Went looking for the ~/.mythtv/Tuner-1.xmltv file, but there was none. After a bit of searching, discovered that Chris Yeoh was right: the channel information is stored in a MySQL database, specifically the table channel in database mythconverg:
=== root@ceeveear (/dev/ttyp6) /myth/Images 31 -> mysql -D mythconverg
mysql> select callsign, freqid, serviceid from channel;
+-----------------+--------+-----------+
| callsign | freqid | serviceid |
+-----------------+--------+-----------+
| 7 Digital | NULL | 1360 |
| 7 Digital 1 | NULL | 1361 |
...
| ABC HDTV | 7 | 592 |
| ABC TV Adelaide | 7 | 593 |
...
| SBS DIGITAL 2 | 5 | 834 |
| SBS EPG | 5 | 835 |
+-----------------+--------+-----------+
24 rows in set (0.00 sec)
Getting closer to work, made a dump of the table with
mysqldump; presumably it's the same for all installations in Adelaide, though notably
the frequency information is missing.
In the evening, confirmed that the sound problems yesterday were caused by the audio language settings of mplayer, so finally was able to play the MPEG stream with sound. Even then, though, the problems aren't over. Trying to play the recorded HDTV, the recorded audio failed again:
DEMUX OPEN, AUDIO_ID: -1, VIDEO_ID: -1, SUBTITLE_ID: -1, PROBING UP TO 2000000, PROG: 0 VIDEO MPEG2(pid=2314)...NO AUDIO! NO SUBS (yet)! PROGRAM N. 0 Opened TS demuxer, audio: ffffffff(pid -1), video: 10000002(pid 2314)...POS=99452 ... Audio: no soundSo what's going on there? It really looks as if there is no audio in the feed. I'm not going to worry about it too much until I get MythTV working and it shows up there too.
As if to add to the general instability I've been seeing lately, tvremote, the laptop I use to control teevee, died on me. Investigation showed a loose mains plug adaptor. sigh I think that machine had been up for 6 months.
Today finally found both the time and the courage to look at the question of recording video from my DVB-T card. As I had mentioned last month, tzap offers me the opportunity to record without further pain installing undocumented software. But it would be nice to have a wrapper program to control tuning, start and stop. So I wrote a little program called record. Most of the code is, not surprisingly, in the time routines—why is UNIX timekeeping such a mess? Ended up writing about 800 lines, very little of which had to do with actually starting and stopping the tzap process. And it worked. Well, almost. Stopping the process on occasion caused the hardware to get confused:
Aug 6 17:38:38 ceeveear kernel: cx88[0]/2: queue is empty - first active Aug 6 17:38:38 ceeveear kernel: cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2 Aug 6 17:38:38 ceeveear kernel: cx88[0]/2: setting the interrupt mask Aug 6 17:38:38 ceeveear kernel: cx88[0]/2: [f3cbc0c0/0] cx8802_buf_queue - first active Aug 6 17:39:09 ceeveear kernel: cx88[0]/2: cx8802_restart_queue Aug 6 17:39:09 ceeveear kernel: cx88[0]/2: cx8802_restart_queue: queue is emptyThis wasn't the first time; the log files showed that it had happened before in March. I didn't find a way round that beyond rebooting; hopefully it won't happen if I don't kill the tzap process.
In addition, the recording stopped after 2 GB:
00:35:24 of 01:00:00 (169%) 2047 MB testfoo File size limit exceededWhy? There's nothing in this file system that has a 2 GB sensitivity. Tried looking in the man pages:
I could scream! Why do Debian consider documentation optional? On eucla, my Fedora machine, I found:=== root@ceeveear (/dev/pts/0) /var/log 46 -> man 2 openNo manual entry for open in section 2 See 'man 7 undocumented' for help when manual pages are not available.=== root@ceeveear (/dev/pts/0) /var/log 47 ->
O_LARGEFILE
(LFS) Allow files whose sizes cannot be represented in an off_t
(but can be represented in an off64_t) to be opened.
But that's only for LFS, and a test confirmed that the flag wasn't even known.
Still, despite all, the day's work was a success. It's a sad recognition that it's easier to write your own program than install somebody else's. Documentation standards seem to have reached an all-time low.
Chasing up the failure of record to write beyond 2 GB was interesting. First, I found the Debian development man pages and installed them. man 2 open still gave me nothing; the man pages was installed as /usr/share/man/man3/open.3posix.gz, which leaves me wondering if it's even the right man page. It says nothing about O_LARGEFILE (not surprising; it has nothing to do with POSIX.1). Looking for the flags in the required header files sys/stat.h and fcntl.h brought nothing: the header files are part of the incredible mess that is the Linux system header files. The actual definitions are hidden in a maze of #ifdefs that ultimately include /usr/include/asm/stat.h, which defines three incompatible structs, __old_kernel_stat, stat and stat64. struct stat has offsets that are unsigned long (i.e. 32 bits on i386), so that can't work.
Spent some time talking with Linux people, and finally came up with the fact that I needed to define _GNU_SOURCE to get the correct definitions, and then add O_LARGEFILE after all, and replace calls to fstat with calls to fstat64, and define the receiving structure as struct stat64. And then it finally worked. But what a mess! I don't think even the most convoluted System V headers were this bad.
More importantly, though, the man pages say nothing about this mess, neither a definition of the structures, nor a mention of the _GNU_SOURCE requirement, nor the restrictions on file size. By contrast FreeBSD is a model of cleanliness. About the only excuse I can find for Linux (and a feeble one at that) is that this is the price of compatibility, exacerbated in Linux' case by the fact that the kernel and userland come from different places.
Mail from James Andrewartha today, pointing out the mistake that I had made yesterday: I had installed the wrong Debian man pages (manpages-posix-dev instead of manpages-dev). Under those circumstances, it's not surprising that they're in section 3 and don't refer to Linux specifics. But it's easy to make this mistake: apt-cache search manpages gives me 65 different packages, and it's easy to miss this:
manpages-de - German manpages manpages-de-dev - German development manpages manpages-dev - Manual pages about using GNU/Linux for development manpages-es - Spanish man pagesThe real issue is that man pages shouldn't be something you have to go out and get. If you install development software, the man pages should be there too. That was one of the great new ideas with UNIX over 30 years ago. In those days, the man pages took up a significant amount of the available disk space, but people obviously thought it was worth it; nowadays it's just noise.
The manpages-dev pages appear identical to the man pages on my Fedora system, as you'd hope. As I've noted, they mention O_LARGEFILE, but nothing else. James also found a reference to LFS on Andreas Jaeger's web pages. It seems that LFS stands for Large File Support, not Log-structured File System. Somehow it's all not very satisfying: first, there's no need for this stuff, and secondly if it's needed, it should be documented in the system, not somebody's web site.
Spent some time playing around with record, the DVB recording program I wrote on Sunday, making it more user-friendly (for command line users, of course). One of the interesting things is that Linux doesn't have a setproctitle() function, which changes the text displayed by ps(1). In the end, found a way to fake one by overwriting the argv and envp parameters at the top of the stack:
int main (int argc, char *argv [], char *envp [])
...
for (i = 0;; i++)
{
if (envp [i])
env = envp [i];
else
break;
}
statusline = argv [0]; /* display in ps output */
statuslength = env + strlen (env) - argv [0];
...
snprintf (statusline,
statuslength,
"record: start recording %s to %s at %s",
channelname,
outfilename,
starttimebuf);
The results are visible in the ps output:
=== root@ceeveear (/dev/pts/1) /myth/Images 172 -> ps aww | grep record
15144 pts/0 S+ 0:00 record: start recording SBS HD to koeter-rex-2006-08-10
at 10 August 2006 19:30:00
More investigation of the sound problems with HDTV, with some interesting non-results. I need to learn more about MPEG-2, but it's clear that multiple data streams are multiplexed in packets, and that each packet header contains a package ID or (confusingly) pid defining the stream to which it belongs. There seems to be no particular standardization of the pids for audio and video. mplayer thus investigates the beginning of the stream to determine the pids involved in the stream; somehow it also manages to determine their nature, by a means I haven't investigated yet. With the -v option, it shows what it chooses. For Channel 10 TV (normal definition), I get:
Checking for PVA Checking for MPEG-TS... TRIED UP TO POSITION 0, FOUND 47, packet_size= 188, SEEMS A TS? 1 GOOD CC: 32, BAD CC: 0 TS file format detected. DEMUX OPEN, AUDIO_ID: -1, VIDEO_ID: -1, SUBTITLE_ID: -1, Checking for MPEG-TS... TRIED UP TO POSITION 0, FOUND 47, packet_size= 188, SEEMS A TS? 1 GOOD CC: 32, BAD CC: 0 PROBING UP TO 2000000, PROG: 0 VIDEO MPEG2(pid=512)AUDIO MPA(pid=650) NO SUBS (yet)! PROGRAM N. 0By contrast, 10 HD gives:
VIDEO MPEG2(pid=514)NO AUDIO! NO SUBS (yet)! PROGRAM N. 0So it didn't find the audio pid. But the video pid is different too; it's different on other channels as well:
| Channel | Video pid | Audio pid |
| 7 | 1281 | 1282 |
| 9 | 512 | 650 |
| ABC | 512 | 650 |
| ABC2 | 2307 | 2308 |
| SBS | 161 | 81 |
| SBS 2 | 162 | 83 |
| SBS HD | 102 | 103 |
Clearly it's difficult to guess the pid, especially since it can get quite big. But ~tzap/channels.conf contains lots of information. Could it include this stuff? Looking at it (and removing a lot of stuff in the middle), I found:
ABC HDTV ... :2314:0:592 ABC2 ... :2307:2308:594 ABC TV ... :512:650:595 7 Digital ... :1281:1282:1360 7 HD Digital ... :1345:0:1364 NINE Digital ... :512:650:1105 NINE HD ... :513:0:1112 TEN Digital ... :512:650:1617 TEN HD ... :514:0:1624 SBS HD ... :102:103:832 SBS DIGITAL 1 ... :161:81:833 SBS DIGITAL 2 ... :162:83:834 SBS RADIO 1 ... :0:201:846Clearly the third last and second last columns are the video and audio pids. But what's the last column? It looks like a pid too, especially since exactly those channels which I can't get audio for don't have an audio pid, and SBS radio (the last line) has no video (not surprisingly) and the last two columns both set; in fact, all channels, including the ones I don't have set here, have the last column set.
So what is this? Some kind of digital encoding, MP3 maybe? The abbreviation MPA in the successful case may be a clue. The obvious thing to do is to read the tzap documentation. But, as I have complained in the past, that doesn't exist. OK, find the source. That's also more easily said than done, and by the evening I hadn't foudn anything up-to-date. apt-get said:
=== root@ceeveear (/dev/pts/1) ~ 265 -> apt-get source dvbutils
E: You must put some 'source' URIs in your sources.list
That will have to wait for another day.
In the afternoon, more investigation of the “no sound” problem on HDTV. Spent quite some time determining that yes, it seems that I did have the latest version of dvb-utils. Documentation is horrendous: even the name of the package is not clear. Debian calls it dvb-utils, but elsewhere it's called dvb-apps or dvbtools, and the package itself is called linuxtv-dvbtools. After a lot of searching, discovered the cause of my problems: the audio modulation for HDTV in Australia is different, but the information I need is not present at all in the channels.conf file: the last field is the service ID, whatever that may mean. Instead, HDTV uses (only) AC3 audio encoding (the other programmes also apparently do so), and dvbscan doesn't look for that when run in the “build channels.conf” mode. Instead, you need to tune to the stream with tzap and then run it in a different mode:
Conveniently, this output is also in hex; presumably somebody else wrote it. Putting the AC3 PID into channels.conf finally gives audio. But what a pain to find that out!=== root@ceeveear (/dev/pts/0) /myth/Images 262 -> tzap -r 'ABC HDTV' -S &reading channels from file '/root/.tzap/channels.conf' [1] 23737=== root@ceeveear (/dev/pts/0) /myth/Images 263 -> dvbscan -cusing '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' 0x0000 0x0250: pmt_pid 0x0102 ABC -- ABC HDTV (running) 0x0000 0x0251: pmt_pid 0x0100 ABC -- ABC TV Adelaide (running) 0x0000 0x0252: pmt_pid 0x0101 ABC -- ABC2 (running) 0x0000 0x0253: pmt_pid 0x0103 ABC -- ABC TV (running) 0x0000 0x0256: pmt_pid 0x0105 ABC -- ABC DiG Radio (running) 0x0000 0x0257: pmt_pid 0x0106 ABC -- ABC DiG Jazz (running) dumping lists (6 services) ABC HDTV (0x0250) 01: PCR 0x0905 V 0x090a TT 0x090c AC3 0x090b ABC TV Adelaide (0x0251) 01: PCR 0x0080 V 0x0200 A 0x028a (eng) TT 0x0240 AC3 0x0294 ABC2 (0x0252) 01: PCR 0x0902 V 0x0903 A 0x0904 (eng) TT 0x0906 ABC TV (0x0253) 01: PCR 0x0080 V 0x0200 A 0x028a (eng) TT 0x0240 ABC DiG Radio (0x0256) 02: PCR 0x0901 A 0x090d (eng) ABC DiG Jazz (0x0257) 02: PCR 0x0901 A 0x090e (eng)
More work on the stuff I learnt yesterday, mainly updating the LinuxTV wiki with pages for dvbscan and tzap. In the process discovered that we're not out of the woods yet; sometimes mplayer still doesn't find the audio in HDTV streams.
Playing HDTV also brought me up against another issue: it looks like my machine isn't fast enough, and I get lots of dropouts:
a52: CRC check failed! -0.354 ct: 0.002 4/ 4 ??% ??% ??,?% 0 0 a52: error at resampling a52: CRC check failed! -0.108 ct: -0.050 30/ 30 59% 27% 6.5% 3 0 a52: error at resampling a52: CRC check failed! -0.147 ct: -0.162 89/ 89 49% 13% 5.1% 12 0 a52: error at resampling
Tried running it on eucla under Fedora Core 5, where it didn't have any problems with dropouts—but exactly every ten seconds it hung for about 5 seconds, and then continued as if nothing had happened. I suspect that's some artefact of GNOME, so rebooted the machine into FreeBSD to try it there—but of course mplayer wasn't installed. Spent some time trying to do that, but didn't finish.
Finally got mplayer installed on the FreeBSD incarnation of eucla and confirmed that it didn't have any difficulties with the HDTV MPEG stream. So the simple answer seems to be: throw more CPU at the problem. eucla has a 2.0 GHz Pentium M; teevee has a (1.466 GHz) Athlon XP 1700+.
(Not directly related, but potentially of interest):
Playing around with the cxm driver for Hauppauge PVR-350: we found that if you pipe it directly into mplayer, it suffered severe buffer overflows, giving really bad images. Modifying the number of buffers in the ring significantly improved that; we'll have to look at what's really needed.
Also looked at the mplayer port, about which I have said less than friendly things in the past. I have only just discovered that the version in the Ports Collection is version 0.99.8.2, which is so old that I can't even find a date for it; but 1.0pre7 came out well over a year ago, and 1.0pre8 came out recently. Did some attempts to build that, with the usual problems of port dependencies getting in my way. Put it on quartet.lemis.com, a test machine with (almost) no ports on it, and left it go (it's a quad CPU 200MHz Pentium Pro).
Writing up my diary entry for yesterday gave cause to investigate the versions of mplayer I was running. Looking at the build log file, I found:
install -o root -g wheel -m 555 /src/FreeBSD/ports/multimedia/mplayer/work/MPlayer-1.0pre8/
TOOLS/wma2ogg.pl /usr/local/share/mplayer/tools
install -o root -g wheel -m 555 /src/FreeBSD/ports/multimedia/mplayer/work/MPlayer-1.0pre8/
TOOLS/x2mpsub.sh /usr/local/share/mplayer/tools
...
===> Compressing manual pages for mplayer-0.99.8_2
...
===> Registering installation for mplayer-0.99.8_2
So it is the latest version, only the reported version number is wrong!
Following up on my HDTV sound problems of a few days ago, discovered that a programme I had recorded from 9 HDTV still claimed to not have any sound. I'd seen intermittent problems in this area, so kept the program for investigation. As it turned out, it worked fine on wantadilla, but not on teevee, which is running 5.3-RELEASE. It also has problems with a bad sector on the main disk, so it's a clear candidate for an upgrade. I don't have a spare machine, and I don't want to take teevee down for an extended period, so chose ceeveear instead—the only thing that it's doing is recording the occasional programme, and I can always reboot it for that. Chose a new disk and installed 6.1-RELEASE, then upgraded to 6.1-STABLE. In the process it came home to me just how little I have achieved in the last two year in my attempts to create a good system upgrade procedure.
Planned a quiet day today, but somehow it didn't quite happen that way. Instead, continued with the rebuild of teevee, which proceeded slowly but steadily and took up most of the day. In the end had swapped the hardware of ceeveear and teevee. As a result, I can now watch HDTV with audio and only use about 50% of the CPU. In combination A number of things have probably contributed to this:
ModeLine "1280x720" 99 1280 1324 1420 1656 720 725 728 772 +hsync +vsync
Yvonne into town this afternoon to pick up some pieces for a new, real CVR, based on a “bare bones” system from MSI. Amusingly, this relatively low-end machine is my first own AMD64 machine (I had a dual Opteron machine last year, but it belonged to Rocksoft). The current box looks interesting; it's almost the size to fit into a home entertainment tower, though I fear it might be a little deep. Hopefully it won't be too noisy.
Spent most of the day today installing the new CVR machine. Its internal layout is quite interesting: there's a removable cage at the front for disk and DVD drive (and, puzzlingly, for a floppy disk, made in such a way that you can't use it for a second disk). The remainder looks quite well laid out too:
Putting the machine together wasn't without its surprises. First, I ended up with the wrong memory (DDR-2 instead of DDR, so I had to take some memory out of teevee), and secondly I found two fans, one that came with the CPU and one that came with the system:
The (larger) one on the left is just sitting on the PCI slots for comparison: that's the one that came with the CPU, but it doesn't fit properly on the CPU (too loose). I wonder how many people have lost their CPU as a result, and why MSI made such an incompatible board.
Installing FreeBSD on the machine brought a couple of surprises, too: read errors from the installation DVD, and later a panic with corrupted data. Guessed at memory incompatibilities, but the SIMM I put in was a PC 400 SIMM, and that's what the BIOS was set for. Turned the memory speed down to 166 MHz and had no further stability problems.
Setting up X was the next issue: the board has its own display chip, but x.org doesn't recognize it. It managed to set it up with a really unusual resolution, something like 1800x1350, and mplayer wasn't able to render correctly on it. Put in an SiS 315 board, set to 1280x720, and it worked.
But, not for the first time, it seems that 64 bit machines are slow! This is an Athlon 64 2800+, presumably intended to be faster than the Athlon (32) 2500+ in teevee; but tests with a specific HDTV file showed much more CPU usage. Of course, there are a number of things to compare: display card, display drivers, memory timing and 64 bit mode. I'll do them in sequence.
I had intended to go riding today, but it was cool, and somehow I managed to find excuses not to do so. Instead carried on looking at the new CVR machine, and did numerous tests with mplayer, making interesting discoveries on the way:
- Most common: broken/buggy _audio_ driver
In summary, nothing I did significantly improved the situation. The next step was to install a 64 bit kernel; but that failed miserably. The instability I had noticed before became impossibly bad with the 64 bit kernel. Both FreeBSD and Ubuntu didn't make it through the installation process. Spent a lot of time playing with BIOS settings (the “restore default settings” and “set optimized defaults” both seemed to do nothing), and finally removed all boards, used the new disk I had bought for the machine (previous attempts were done with disks about 3 to 5 years old, but still in good condition) and tried again—and it worked! So: is this a problem with the BIOS settings, some of which I might have reset after all, with the boards, or with the disk? Who knows? Still more work to do.
Brew day today, but also found some time to work on the CVR machine. Spent a lot of time working on the system upgrade scripts, but also installed X—strangely, it created a configuration file very different from the one it created on the same hardware in 32 bit mode. Did some preliminary tests with mplayer suggested that it was a lot faster than in 32 bit mode.
But before I could start some real tests, it crashed. Not once, but repeatedly; it took several attempts before it would stay up long enough to finish the boot and fsck. And the only way I could get it to stay up longer than about 5 minutes was to turn all the timings down to their minimum values, which also slowed the machine down unacceptably. Finally, frustrated, gave up. What a waste of time!
What a waste of a day! Spent most of it double and triple checking what's wrong with the new machine, without any firm result except to confirm that it's not working correctly. That's a particular nuisance because it's holding me up doing other things, notably video performance testing.
Into town with my defective computer today and spent quite some time at the warranty/service department, where I was first told that the processor that I had been given was a 32 bit Athlon—this after I had said that it had run for some time in 64 bit mode—and then that it was not the chip that I had ordered. In the end it eventuated that the motherboard BIOS didn't know about the processor—which of course was an Athlon 64, as the photos show—and thus couldn't set the operating parameters correctly. It seems that Socket 754 chips are pretty much unobtainable nowadays, so in the end we agreed to return the machine and I started again with the same cabinet, an MSI Socket AM2 motherboard and a faster processor (Athlon 64 3500+).
Home to put the new machine together. That wasn't without its surprises either. It worked fine in 64 bit mode, but X didn't load the driver for the on-board video chip (part of the VIA chip set), and the sound driver didn't detect anything. Some research showed that the via driver isn't 64 bit clean. Damn.
Putting in an AGP card wasn't an option, either: this board has PCI Express slots, two of them, but I don't have any PCI Express boards. Finally removed a PCI card from wantadilla and used that. Result: I can now finally display the test HDTV image without dropping frames. Now to investigate the other issues.
Spent most of the day playing around with the new motherboard. Far too much of it isn't supported. Booted back into 32 bit mode and found that I still couldn't load the via driver: it seems that this chip set is too new. I was also unable to find a FreeBSD driver that would recognize the sound chip, which seems to be intimately related to the VGA chip. pciconf -lv reports:
none1@pci1:0:0: class=0x030000 card=0x72531462 chip=0x32301106 rev=0x11 hdr=0x00
vendor = 'VIA Technologies Inc'
class = display
subclass = VGA
none2@pci4:1:0: class=0x040300 card=0x72531462 chip=0x32881106 rev=0x10 hdr=0x00
vendor = 'VIA Technologies Inc'
class = multimedia
Did get some testing done, which showed that the difference in mplayer performance between 32 bit and 64 bit versions of X was less than the margin of experimental error: so for the moment it doesn't seem worthwhile taking in the disadvantages of 64 bit mode (mainly less driver support).
After that, decided to install Linux, the latest version of Ubuntu (“Dapper Drake”). They've managed to dumb down the installation to a point where it's not possible to set anything except possibly the partition size. How I hate these “modern” GUIs!
As the result of a suggestion by Stephen Rothwell, went looking on the VIA web site and found sources for VGA drivers for the chip set I'm using, released under what is effectively a BSD license. That's in marked contrast to the claims on the web that VIA hasn't understood “Open Source” and provide no support for them. I wonder why the drivers aren't included in the x.org distribution, and whether they're in the XFree86 distribution.
Tried installing the latest version of KnoppMyth. The installation process is no more refined than the previous version which I tried a couple of months ago . The “automatic” install fails with:
/usr/local/bin/KnoppMyth-auto: line 609: / 10000000: syntax error: operand expected (error token is "/ 1000000").Looking at the code, it's in partition_autosize() trying to calculate the disk size based on a variable $SIZE that obviously didn't get set. It's set by the output of fdisk, and it seems to assume that the disk in question is /dev/hda; in this case, for some reason probably related to SATA, it's /dev/hdc. But I want to install, not debug installation procedures.
Tried the custom install and on leaving the Partition-Menu (sic), got
Fatal dialog error: Error: Expected at least 7 tokens for --radiolist, have 4.
I should be used to this by now, but somehow I still find it incredibly frustrating.
On advice from Ben Herrenschmidt, downloaded the Ubuntu “alternate” CD image, but that didn't give me much more control over the installation. In particular, no choice of what software to install, certainly not whether to start GNOME or not.
The manual disk partition menu (text mode) is marvellous: it has to have a frame, which makes it one line shorter than it should be. It scrolls, but there's nothing to tell you that. Instead, you're left with a menu that looks complete, but is missing the “Next” button: it looks as if there's no way to continue.
Somehow didn't have the courage to try to continue beyond the basic installation. First I need to fix my “new system” scripts to work with Linux as well, then I'll be able to do things much more quickly.
Instead, back looking at the drivers for the VIA chip. What they supply is supposedly tailored for Fedora Core 4 (now happily obsolete), but part of it at least (marked “kernel”) is intended to be incorporated in a build of X.org as a replacement for the via driver. Started that, but ended up with no accessible header files and even less desire to continue, so put it off until next week. I should take a break from computers over the weekend.
Tried Yet Again to install a version of MythTV on the new CVR box, which I'm calling tv2 for the moment. First I started with the version of Ubuntu that I installed last week. I hate Ubuntu! It installs nothing of value, and it doesn't even have a valid apt/sources.list: it appears to have only the CD-ROM, and that doesn't include everything. In particular, I wasn't even able to apt-get Emacs. I also couldn't find a menu item for mounting NFS file systems. To make matters worse, the xterm replacement in the menu misinterprets all Meta-key functions, so I couldn't even type into