|
| Greg's diary |
| April 2007 |
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sunday, 1 April 2007 | Echunga | |
| Top of page | ||
| next day | ||
| last day |
Out riding again today, but somehow we never seem to stay out long. There used to be a time where we'd go out for several hours, but nowadays a single hour seems to be our maximum. Hopefully things will be better when Carlos is a little older and stronger.
Looked at the IceTV stuff again today, and got it working; disappointingly, though, the file summaries don't have any information about year or rating. One of the reasons for my dissatisfaction with the programmes from tvguide.org.au was that they often incorrectly give this year as the year the film was made; but no year at all is even worse.
Also managed to make quite a mess of my configuration. Thank God for backups!
Also worked on the remote control stuff. This looks like an iterative issue; it's getting better all the time, but slowly. Somehow the whole issue is incredibly obfuscated by poor documentation.
| Monday, 2 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Back to work on the black box this morning. Once again there wasn't much to do, but once again, somehow it took all day. It's amazing how much cruft you find while going through old code.
| Tuesday, 3 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yet another day where I seem to have achieved nothing apart from some work on the black box. Did some backups to DVD as well, but at the end of the day I was left wondering where all the time went.
| Wednesday, 4 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yet another day spent on slow testing. At least today I made more progress: we identified a bottleneck in the process that required one of the central programs that required a complete restructure to fix: instead of a central loop, it had to become three threads, and the buffer management required a complete rewrite. Rather to my surprise, it worked as designed first time, though of course in the process we found a further bottleneck which requires another thread.
How I hate POSIX threads! They seem to have been designed without reference to previous methods.
| Thursday, 5 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yet another day “testing” our software. For reasons I don't understand, mplayer gets further and further behind. Spent quite some time investigating the buffer algorithm, but couldn't find anything wrong with it. Clearly using gdb here is not an option, so decided to take advantage of the fact that we have a shared memory segment shared between all processes, and wrote some debugging code that writes information to the segment, and very little code to actually dump it from another program. That showed nothing beyond the fact that mplayer was reading larger and larger chunks with longer in between. Looks like it's not the problem of my code; I'd like to say it's not my problem, but I still have to solve it.
| Friday, 6 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
It's been nearly three weeks since the last power failure, high time for the next one, which came at 4:20 this morning. Fortunately it didn't do any serious damage.
I've decided to take it easy over the Easter weekend, so didn't do very much today. Finally caught up on reading magazines.
| Saturday, 7 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent some time looking at why MythTV no longer compiles under FreeBSD 7-CURRENT. It proved to be a problem with the incredibly convoluted series of #include headers: a total of 137 header files and 16 levels of nesting. In the process, sys/time.h (included from the threads header file, of all places) was replaced by time.h. Somehow this can do with improving.
Yana along in the afternoon with her Apple computer and her old Canon EOS 20D camera, which she had subjected to sea water and sand a few weeks ago. Miraculously, it seems to have almost survived. Managed to take a couple of photos before it gave up again. Looks like a candidate for dismantling and cleaning.
The Apple had a problem typical of the stupidity of modern software: it has two disks, which it has given the names untitled and Untitled. There's a man page for mount(8), but that's not the way you mount file systems: in fact, it appears to be a virgin FreeBSD man page. To quote:
SYNOPSIS
[-adfruvw] [ ufs | lfs | external_type]
Where's Apple's HFS file system there?
It seems that the automounter looks at the volume name and creates a mount point for it. In this case, it can't tell the difference between untitled and Untitled, and so it mounted the second file system on the mount point “/Volumes/Untitled 1”—although the root file system, in a rare concession to UNIX, is mounted on /, and there is thus nothing is mounted on /untitled. That space in the name plays havoc with scripts.
Spent an inordinate amount of time trying to find out how to change the location of the mount. The Apple documentation, such as it is—I haven't been able to find a system administration handbook—is vague and contradictory. For 10.3 I am told, after searching for rename and selecting Changing the names of items:
This is incorrect, at least on this machine: clicking once highlights the name. Clicking a second time doesn't seem to change anything. Typing in anything, either after one or two clicks, unhighlights it again.
The instructions for 10.4 are different: searching for rename brings a completely different list, with the favourite “You need to restart your computer” message appears, which is in fact a reference to a “kernel panic”. The distinction kernel is presumably to distinguish from a user panic, which happens when somebody tries to access the documentation. No Changing the names of items any more; this section has now been renamed “Naming items”, and it tells me:
That even appears to work, but on the wrong machine.
Then tried umounting the file system—that's easy enough—and mounting it manually. “Incorrect super block”; it seems that one part of the mount(8) man page is correct, and that it's looking for a UFS file system.
This is a complete declaration of bankruptcy! No systems administration guide, man pages that don't reflect correct operation, utilities that don't work in the standard system environment, help that requires several attempts to find the correct incantation to find something, search results that seem completely unrelated, and instructions that don't work. And we traded our clear, simple UNIX structure for this?
After 90 minutes, I gave up. I still don't know how to tell the system where to mount a file system. Somebody on IRC suggested that I try fstab(5), but my recollections are that that doesn't work either. If it does, the man page is wrong: it doesn't mention HFS at all. Instead, created a symlink to “/Volumes/Untitled 1”. Using that name instead of the mount point name removes the space from the path name and lets things work again properly.
| Sunday, 8 April 2007 | Echunga | Images for 8 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Didn't do much today; a bit of brewing, made considerably easier by the fact that I'm currently experimenting with improving “kit” beers. The current batch is only slightly modified: less volume, half the amount of pure sugar, as dextrose instead of saccharose.
As the world gets smaller, we come more and more into contact with time zones and with people for whom the time of day is different. That's particularly obvious here in Australia. China and Japan are pretty close from a time perspective, but currently (mid-morning here) it's mid- evening (yesterday) on the east coast of the USA, and the middle of the night in Europe.
So it's really astounding that the Microsoft world pays no attention at all to absolute times. I get mail messages with claims like:
X-Mailer: Apple Mail (2.752.3) On Mar 9, 2007, at 11:25 PM, Greg 'groggy' Lehey wrote:This was in reply to a message sent with a clear header:
Date: Sat, 10 Mar 2007 14:55:31 +1030
Comparing the real, unambiguous time of the second with the first, and it's clear that there's an implicit time zone -0500, corresponding to the US east coast. But that's the only way we can know that.
There's certainly nothing wrong with translating the time to local time, but then losing the time zone information makes it useless. And as this example shows, Microsoft's not the only offender.
Today Yana took some photos for Yvonne and gave them to me to read in. When I did, I found:
-rwxr-xr-x 1 yvonne home 4664460 Apr 9 01:57 /home/yvonne/Photos/20070408/img_7790.jpg -rwxr-xr-x 1 yvonne home 5699992 Apr 9 01:58 /home/yvonne/Photos/20070408/img_7791.jpg -rwxr-xr-x 1 yvonne home 5753058 Apr 9 01:58 /home/yvonne/Photos/20070408/img_7792.jpg
These photos weren't taken in the middle of the night, of course, but the camera (Canon 30D) sets only time, not time zone, which ends up defaulting to UTC, so all the dates were 10½ hours off. Why 10½ and not 9½? I don't know, but another of the disadvantages of a device that doesn't understand time zones is that you have to reset the time when daylight savings time starts or ends, and possibly Yana hadn't done so.
This is a real pain! I last went through it last time I processed some of Yana's photos, but it occurred to me that I can't be the only person who has this problem, so ended up adding code to touch(1) to adjust the time specifications of a file:
$ touch -A -103000 ~yvonne/Photos/20070408/*
The argument 103000 is in the format HHMMSS, i.e. 2 digits hour, 2 digits minute and 2 digits second. That's not the nicest of formats, but it matches touch's settime format.
| Monday, 9 April 2007 | Echunga | Images for 9 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Another bloody power failure! This time at 2:43 am. I wonder if the number of failures in the small hours is statistically significant.
Spent some time today looking at the Canon EOS 20D that Yana brought back with her. She had subjected it to sand and water on the beach a few weeks ago, and the camera shop had declared it to not be repairable. But it almost worked. Took it apart and found that the damage was, indeed, relatively minor:
|
|||||||||||||||||||||||
So why doesn't it work reliably? My best bet is that the control knobs have got wet and no longer work reliably. But they're probably just switches. I'll leave it to dry out and then put it back together.
| Tuesday, 10 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Back to work again, first catching up on 5 days' worth of mail. Fortunately it's not as bad as it used to be.
Still trying to get our video application working, not helped by last Friday's power failure, which took down blackbox. It looks as if I had installed incorrect configuration files, and it took me 45 minutes to find out what I had done and to recover from them and reboot it. We're still having difficulty synchronizing data.
The modifications to touch(1) are obviously simple enough to warrant a bike shed: usage() should be static, the time zone offset should be in seconds, not HHMMSS, and a couple of others, not to mention a debate on whether time_t is UTC or not (I say no: it's a count of seconds from a specific event). Put in a new update which will hopefully keep most spectators quiet.
Bartosz Fabianowski sent a message offering an alternative method:
You can use graphics/jhead to comfortably change both EXIF and file modification time at once:jhead -ta-10:30 -ft *.jpgThe first parameter tells it to adjust the time by 10:30 hours, while the second applies the result to the file modification time as well.
| Wednesday, 11 April 2007 | Echunga | Images for 11 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Phone call from Tony from ETSA today, to tell me what I had expected: logging normal voltages on the power supply line showed no anomalies, though he was able to identify events such as the air conditioner engine turning on (an inductive load). He gave a few more items of interest:
I said that the results were pretty much what I expected, since the problems occurred in conjunction with power failures. He was surprised that I didn't have any other damage, such as electric motors and electronic modules in kitchen devices. That is surprising, but in each case when we had a power failure, no motors were running. He then suggested that I should have installed surge protection. I read to him the inscription on the connectors from one of the destroyed UPSs, something I didn't think of when I spoke to Shaun a couple of weeks ago: :
|
|||||||||||||||||||||||
He didn't seem to understand that, and continued to say that I should be using surge protection. When I asked what was wrong with the surge protection I was using, he said it was difficult to choose a surge protection device, and he wasn't able to make any recommendation. He explained to me that the power (he didn't say voltage or current) came in the form of a sine wave, and that it went through 360° 50 times a second; it seems that they're taught to say this and to imply that it's very fast. He also said that, depending on the position in the waveform, the effect of a short spike was different. On questioning, he said that the first quadrant (0 to 90°, not the words he used) was the most dangerous. He's not as ignorant as Shaun, but I don't think he was prepared for this question, and I don't see any reason to believe him.
I asked him what they were going to do about it, and he skated around saying “nothing”; I'm left with the distinct impression that ETSA personnel have been instructed to deny responsibility. He claimed that very few cases have been reported of damage in conjunction with power failures—this despite the fact that two of his colleagues have confirmed personal experience of such problems. He did, however, agree:
Where do we go from here? I don't have much hope. It's fairly clear that ETSA is not interested in following up.
More work on our black box application, including rewriting the buffer algorithm. For once I've found a case where it's simpler to use indices than pointers. Also ran into a really weird problem, which I finally reduced to this simple example:
infile = open (argv [1], O_RDONLY);
printf ("FD %d\n", infile);
thispos = lseek (infile, SEEK_SET, 0);
printf ("Current position: %lld\n", thispos);
thispos = lseek (infile, SEEK_CUR, 0);
printf ("Current position: %lld\n", thispos);
Running this gives:
FD 3 Current position: 0 Current position: 1
Calling lseek with SEEK_CUR and an offset of 0 should not change the position at all. The compiler issued no warnings, and I was about to tear my hair out before I realized I had the parameters to lseek in the wrong sequence: the whence parameter is the third parameter, and SEEK_CUR is defined as 1. The compiler can't find anything wrong, because what it sees is:
thispos = lseek (infile, 0, 0);
printf ("Current position: %lld\n", thispos);
thispos = lseek (infile, 1, 0);
One of the dangers of relying too much on compilers to detect programming errors.
| Thursday, 12 April 2007 | Echunga | Images for 12 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Still more work on the black box today. This is getting on my nerves. For reasons I don't understand, mplayer has decided to stop working, on two different development machines, though we changed nothing.
Put the Canon camera together and was able to take a few photos before it stopped responding again. It was becoming fairly clear that water must have got in the front somewhere, so found a way to take the front off—in fact, the camera is quite nicely put together—and discovered some more serious damage, including a miniscule resistor that had been corroded off altogether:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
In the first photo, the resistor (marked “753”) is visible below the solder joint with the pink wire. It was loose, though, and in the following photo (rotated by 90°) it's missing. The third photo shows how tiny it is. I can't think of any way to fix that; hopefully it won't make too much difference. Otherwise I suppose the camera really is a write-off.
| Friday, 13 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Another power failure in the middle of the night. That's the 16th so far this year, and of the 9 for which I recorded a time, 6 have been between midnight and 5 am. I'm beginning to think that there is some significance here. Atmospheric humidity? If so, we're going to be in serious trouble when the drought finally breaks.
In the morning, Yvonne decided to go to Beaufort tomorrow to see a horse. That's not too far from where Chris Yeardley lives, so thought of combining it with inspecting some properties. Spent quite some time doing that before deciding that it was all a bit too hurried.
Still more work on the black box, and ended up rewriting the buffer algorithm yet again.
| Saturday, 14 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yvonne off early to Beaufort this morning, and woke me to say that something was beeping like crazy in the office. That proved to be an Emacs running ERC and looping; what is there about this package that causes such instability?
Didn't do much in the day, mainly watching TV. Spent a bit of time scratching my head about the problems I've been having with the remote control and XvMC in conjunction with MythTV. The former is mainly a documentation problem, but it would be nice to have an easier way of testing it: each change to the .lircrc requires stopping mythfrontend, which is horribly slow on startup (and not much better the rest of the time). Started a build on eucla, which of course took most of the afternoon.
The issues with XvMC look like more of a problem: it looks like it's going to require serious debugging in an area about which I know almost nothing. I suppose I'm going to have to bite the bullet and start investigating the X protocol.
There's a positive side to documenting my problems in this diary. Today I got a message from Thomas Maynard referring to the missing resistor on my Canon EOS 20D:
You can do SMT (Surface Mount Technology) soldering at home at your workbench. Here
http://www.norcalqrp.org/ncdummyload.htm
is a link to an introductory SMT kit. I bring it to your attention not for its applicability to your camera issues but for the accompanying PDF manual that describes clearly and concisely what you need and how to perform SMT assembly at home.
Unfortunately, this particular kit looks simple in comparison with the problem I'm up against: firstly, the resistors in question are much larger, and secondly they're on an epoxy circuit board. In my case, the substrate is plastic ribbon:
|
|||||||||||||||||||||||
| Sunday, 15 April 2007 | Echunga | Images for 15 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally got round to putting the Canon camera back together today. I'm a little dubious about some of the connectors. They're tiny, and the alignment seems very critical. In particular, in the second photo below, it looks as if the holes in the tape should line up with the black clips below; but they don't. I tried quite hard to line them up, but that seemed to be the only way they would fit.
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
As a result of the lost resistor, I was expecting some loss of functionality, but it turned out to be complete: when I turned it on, the camera did nothing. If I hadn't got an electrical shock from one of the side connectors (flash? I wasn't expecting anything like that), I would have suspected that the battery no longer worked. That's disappointing.
Taking close-up photos of the components has unexpected advantages, though. On looking at one, a fair amount of residual corrosion can be seen:
|
|
|||||||||
There's a question, of course, as to whether this is corrosion or reflection, but at any rate it's clear that it needs cleaning. It's also interesting to note the indentations from the pins of the connector. I wonder if cleaning would help.
Spent some time playing with the lircrc file for MythTV, and got some better results. One thing that I haven't seen documented anywhere is how to send multiple characters to the application: separate them with commas. I have no idea how to pass a comma instead. Here's what I ended up with for sending the digit 1 followed by the “Cursor right” key (skip 1 minute forward) to mythfrontend:
# Big (10x) skip forwards
begin
prog = mythtv
button = skip
config = 1, Right
end
Yvonne back in the evening with a gift horse, Lucy, a Paso Peruano:
|
|||||||||||||||||||||||
| Monday, 16 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Wasn't feeling too well today, so apart from catching up on my mail, didn't do very much.
| Tuesday, 17 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Back to work on the black box today. One of the problems of the buffer rearrangement is that mplayer, instead of dropping behind the action, doesn't run at all. It seems that there is absolutely no provision in mplayer to wait for data to arrive if it gets to the end of a stream. This could happen, for example, if you skip forward while watching an incoming stream.
Spent some time investigating that, but was cut short by having to leave for town for a couple of events: first, an ICT council board meeting, where we're still discussing restructuring. I had to leave early to go to a dinner meeting with Metaplanners, discussing global investment opportunities. Some interesting talks.
Back home, our weekly power failure had occurred, this time one of the rare ten minute variety. Usually they're either a few seconds (“reconnector event”) or a couple of hours (when they have to send out a crew). This time echunga went down too—possibly the UPS couldn't hold out that long. I wish ETSA would finally do something about the situation.
| Wednesday, 18 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent all day looking at mplayer with an aim to get it to stop trying to seek past the end of a file, or to wait for data to arrive if it does. I was partially successful, but once again left with a sense of amazement about how this program is written. After checking the result of a read at EOF—which should return a read count of 0—I discovered I was getting -1 (error condition) instead. Of course mplayer doesn't check for error conditions—that's a wimp's way out—so I added code to print a message when this happened. The error code? 0, no error. After further searching, I found this gem in stream/stream-file.c:
static int fill_buffer(stream_t *s, char* buffer, int max_len){
int r = read(s->fd,buffer,max_len);
return (r <= 0) ? -1 : r;
}
I won't even comment about the layout of the code. All this function does is to:
There are others as well that seem more than a little dubious. In libmpdemux/demux_mpg.c, function demux_seek_mpg, I found:
while (1) {
if(newpos<demuxer->movi_start){
if(demuxer->stream->type!=STREAMTYPE_VCD) demuxer->movi_start=0; // for VCD
if(newpos<demuxer->movi_start) newpos=demuxer->movi_start;
}
Apart from the fact that this check doesn't need to be done multiple times, the comment and the code seem to contradict each other. The layout makes it not only difficult to read, but also confuses Emacs when it looks for start and end of the functions. In the end I reindented the functions I was working on to be able to read them at all.
| Thursday, 19 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Not feeling well again today, but struggled on with mplayer, which is still not starting the way I want it. Why is this program so fragile? I've been getting more messages that the X server doesn't support xv, but they seem to be related to some permission issue rather than lack of support; it all depends on which window I start mplayer from. Frustration.
| Friday, 20 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Still more work on the black box. Sometimes our “testing” seems more like trial and error, which it most certainly should not. We now have the machine running reasonably well, but my modifications to mplayer don't seem to have been as successful as I had hoped. Surely it shouldn't be that difficult to get it to track an incoming stream without falling behind.
Into town to the periodontist, third of five visits.
| Saturday, 21 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Quiet day, spent mainly setting up a personalized Google map of potential properties in the Ballarat area. This stuff is all so clunky! Still, the results look good, and with a bit of practice I'll be able to get some useful captions. But wouldn't it be nice to be able to influence the format of the listings on the left, or get a description to pop up when you run the mouse over a marker?
| Sunday, 22 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent most of the day updating private web pages. I have a “local” home page which is more tuned towards my needs than anybody else's, and effectively replaces a bookmarks page. Like bookmarks, it has “just growed” over the last 6 years, and today I split it out into a number of smaller pages and added some search forms from various web engines:
Also reinstalled squid, not the easiest thing in the world. For reasons I have forgotten, I had been running squid as user ftp, and that caused all sorts of permission problems, so in the end just gave up and ran as squid instead. I wonder why I ever changed it.
Why does squid write its log files to the /usr/local hierarchy?
| Monday, 23 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
We still don't have mplayer tracking the camera correctly! Wrote a program to keep up with the input stream and feed it to mplayer via a pipe, but it was so spectacularly bad that it dropped 95% of the stream. Ran it against /dev/null instead with not much better results. Clearly I'm missing some important performance issue here, but it's not pipes—the same thing happens directly to /dev/null. Maybe I should hold off a bit.
We have an offer for the house, unfortunately not one that we can accept as it stands. But maybe something will come of it.
| Tuesday, 24 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
The black box is finally on its way, so I can get back to the definitive MythTV installation under Ubuntu 6.10 (“Edgy Eft”) a month ago. Since then they've come out with a new release, 7.04, but generally called “Feisty Fawn”—what names! Tried installing that with less than spectacular success.
This time I tried it in graphics mode, which is effectively the default. It comes up with a GNOME screen and a couple of icons—and that's all. I suppose the GUI generation can instinctively (“intuitively”) know to double click on “Install”. Then an installation dialogue comes up, pretty much unchanged since the last release, including things like double selection of the time zone. On many screens (e.g. keyboard selection), there's no reaction to the mouse until you first move it away from where it is and then back again if necessary, a thing that I had noticed on previous versions.
I've already established that the performance of the ext3 file system is abysmal under certain circumstances: in particular, deleting large files takes for ever, up to 100 times longer than with ufs. ufs isn't a real option with Linux, of course, so selected a single XFS partition instead, along with 1.1 GB swap. After partitioning, I got a message entitled “Install the GRUB loader to XFS” and saying “The GRUB boot loader installation often fails or hangs when /boot is on a XFS file system. Using LILO in this situation is recommended. [Go Back] [Continue]”. Pressing Go back just continued. It gave no way to change the loader.
At the end of this install, the message was repeated. Again, selecting Go back did nothing. In fact, nothing at all happened. No information what to do next.
I rebooted, and it seems that LILO did get installed after all (or was just left behind from the previous installation). Saw many fatal modprobe failures during startup, along with a login prompt. While thinking about logging in, it started GNOME. The whole thing looked very flaky, and my USB mouse didn't work (it did during the installation). Rebooting didn't help. I then plugged in a PS/2 mouse, which worked immediately.
Decided to reinstall with the default parameters. The “Migrate documents and settings” stated “There were no users or operating systems suitable for importing from”. If the same version of Ubuntu isn't suitable, what is? It also completely ignored the existing layout and created a single ext3 77 GB root file system along with and 3 GB (!) swap. This time the installation completed with a message asking me to reboot. After reboot, the mouse worked.
I then installed for a third time, because I want XFS. This time, in addition to the other partition options, I was given the recommendation to resize the master partition to half the original size. Why? The previous installation was the default, and now it should be halved? What sense does that make?
I selected the “manual” partitioning again. This time, after getting the GRUB message, I answered “continue”, which didn't: I ended up in the same menu as before. I can't find any way to select the boot loader or its location. It seems that you have to press Go back to continue.
At the end of the installation, got the GRUB message again. Again I selected continue this time and got another message:
Executing 'grub-install (hd0)' failed. This is a fatal error.There was no further help; presumably the installer had crashed.
Finally, at the fourth attempt, I copped out and partitioned a 4 GB ext3 root file system and the rest as an XFS partition. That worked, but it's not what I want, and I'm only forced into it because of the limitations of the installation process.
Ubuntu is supposed to be a system for non-technical users. Does that mean that the installation process should only work properly in the default case?
XFS has given me other concerns as well. Over the last few days I've lost a number of recordings on ceeveear: the files were empty, and in a couple of cases there was no file at all. I assumed that there was some problem with initializing the tuner cards, and rebooted. That worked, but for some strange reason the second disk that I installed a week or so ago (with the XFS file system) came up running in PIO mode. That seems remarkably ancient; FreeBSD has selected DMA by default for nearly a decade. It's also not immediately clear from the hdparm(8) man page how to set DMA mode:
SYNOPSIS
hdparm [ flags ] [device] ..
...
-d Disable/enable the "using_dma" flag for this drive. ...
In fact, the -d option takes a parameter (0 to disable, 1 to enable), but this isn't described properly in the man page.
Today, on reboot, I entered the magic incantation:
# hdparm -d1 /dev/hdb
Immediately I was greeted by a stream of messages indicating a timeout on one of the tuner cards. Why? And why weren't they logged? Looks like a DMA channel conflict, but the only mention of DMA in the dmesg output relates to the parallel port, of all things. More head-scratching. Is the XFS? Probably not. This is also a pretty flaky motherboard, so maybe changing that would help.
| Wednesday, 25 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Installed mythfrontend (display part) on Yvonne's computer (battunga) today. It wasn't as straightforward as I had hoped: although I have no intention of running a backend (tuner part) on this machine, and the database should be on a different machine, I couldn't run mythtv-setup because it wanted access to a local database. Ended up copping out and installing a MySQL server on battunga, for all the good that will do.
Phone call from my Aunt Freda today. My father's planning a talk on his favourite subject, Banjo Paterson, and he wanted me to research the origins of Waltzing Matilda. That proved more difficult than I thought; there are at least three accounts (the others are from the Australian National University and the National Library of Australia), and the three don't agree on all details. Tidied up some of the stuff in the Wikipedia article, but there's much more that needs doing. One of the big problems with the Wiki approach is that it's really difficult to make larger edits (like change of structure).
Did some looking to find the cause of the DMA problems I had with ceeveear yesterday, but they seem to have gone into hiding. Frustrating.
Got a message from James Andrewartha regarding my problems with the Ubuntu installation process:
The Ubuntu graphical installer is designed for non-technical people, and to only be run once. So it tries to preserve the existing filesystems by resizing them. The Migrate Documents and Settings feature is for people coming from Windows.
In short, you should use the alternate install cd, which uses debian-installer and allows much more control over the process.
I still have a problem with this, and I don't completely agree with Andrew. If an installer installs a specific partitioning layout, it shouldn't want to change it when the installation program is run again, even if this is not intended use. Also, the download page doesn't mention any of an alternate install CD, and the Internode mirror server doesn't have the image. In fact, I'm not sure which image James is referring to. The only mention I see on the download page reads “Check here if you need the alternate desktop cd suited for computers with less than 256MB of RAM”. That's not the case here.
| Thursday, 26 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally it's raining again (unless you believe the daily rainfall bulletins of the Bureau of Meteorology, which have reported no rainfall at all for Meadows this year). Looks like we're in for a week of rain, a stark contrast to the last 10 months. It's also clear that our profuse watering of the garden wasn't nearly enough: now things that have struggled through the summer are finally growing.
More mail from diary readers on the question of the Ubuntu installation process. Oliver Herold writes:
http://ftp.tu-chemnitz.de/pub/linux/ubuntu-releases/7.04/It looks like it's really halfway down:
just scroll down to the bottom.
Alternate install CD
The alternate install CD allows you to perform certain specialist installations of Ubuntu. It provides for the following situations:
PC (Intel x86) alternate install CD
creating pre-configured OEM systems;
setting up automated deployments;
upgrading from older installations without network access;
LVM and/or RAID partitioning;
installs on systems with less than about 256MB of RAM (although note that low-memory systems may not be able to run a full desktop environment reasonably).
For almost all PCs. This includes most machines with Intel/AMD/etc type processors and almost all computers that run Microsoft Windows, as well as newer Apple Macintosh systems based on Intel processors. Choose this if you are at all unsure.
OK, that's the correct alternate install CD, I suppose. As I mentioned earlier, none of the reasons apply to me. It's also just a CD image (696 MB) which means that a lot of the stuff on the installation DVD is missing. It's a pity that the documentation is so misleading.
Ian Donaldson writes about my problems installing mythfrontend on battunga:
You don't need to run mythtv-setup on a front end. Just run mythfrontend. When it can't connect to the default db (mythconverg on local) it should prompt you for database host, database name, user name and password.He's right; I was just misled by the continuous stream of error messages:
=== grog@echunga (/dev/ttypa) ~ 1 -> mythfrontend
2007-04-27 09:58:45.882 Using runtime prefix = /usr/local
xscreensaver-command: not found
2007-04-27 09:58:45.973 DPMS is disabled.
2007-04-27 09:58:46.012 Unable to read configuration file mysql.txt
2007-04-27 09:58:46.012 Trying to create a basic mysql.txt file
2007-04-27 09:58:46.023 Writing settings file /home/grog/.mythtv/mysql.txt
2007-04-27 09:58:46.222 New DB connection, total: 1
2007-04-27 09:58:46.515 Unable to connect to database!
2007-04-27 09:58:46.515 Driver error was [1/1045]:
QMYSQL3: Unable to connect
Database error was:
Access denied for user 'mythtv'@'localhost' (using password: YES)
QSqlQuery::exec: database not open
QSqlQuery::exec: database not open
2007-04-27 09:58:46.583 DB Error (KickDatabase):
Query was:
SELECT NULL;
No error type from QSqlError? Strange...
(new query)
2007-04-27 09:58:46.635 Unable to connect to database!
2007-04-27 09:58:46.635 Driver error was [1/1045]:
QMYSQL3: Unable to connect
Database error was:
Access denied for user 'mythtv'@'localhost' (using password: YES)
QSqlQuery::exec: database not open
I repeated the install on echunga and let it finish vomiting. 800 lines of these repetitive error messages later, it started mythfrontend normally. It's interesting to note that the first line of the error message is not the one after the empty line; that's in the middle of the message. The first line is Unable to connect to database!. I had tried to fix this nonsense earlier, but it's in a maze of twisty little qt functions, all different, so I gave up.
Spent the rest of the day catching up on private accounts in preparation for hopefully selling Wantadilla. Discovered to my surprise that I might have a very large amount of money which has been due to me for 10 years, coupled of course with the fact that had I invested it then, it would have more than doubled in value. I don't know whether to be happy or sad.
| Friday, 27 April 2007 | Echunga | Images for 27 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
It's been nearly a month since I started a trial subscription to IceTV, as I mentioned at the beginning of the month. I found a couple of reasons not even to use the service if it were free. As I later wrote,
People had suggested to me that the IceTV people are Internet-savvy (you'd expect that, wouldn't you, but so many are not), but I got no reply. Today I received a reminder that my trial subscription would soon expire, completely ignorant of my message. That's a pity: a commercial service needs to offer something that free services don't, and just a slightly more accurate description (and that only on average) doesn't make up for the lack of other information.
Spent a lot of the day writing up documentation, including converting the Waltzing Matilda documentation from the National Library of Australia into groff—unfortunately only for personal use in accordance with the copyright, so I can't show it here. In the process wrote an Emacs function to convert UTF-8 characters into groff escapes (function utf-to-roff in my .emacs file). It didn't take too long, and the results were surprisingly good.
It's still raining, and so I suppose it's time to wash my car. When the drought started, in September of last year or so, I decided to set an example by not wasting water on anything as non-essential as car washing. We've had some rain over the last month, so it no longer looked as bad as in January, but it's still in need of a wash. Parked it outside to wait for the rain to wash it.
One of the fun things about living in the country is the closeness to nature. This evening found what I think is a cicada in the lounge room:
|
|||||||||||||||||||||||
It doesn't look like any cicada picture I can find, though, so I'm not really sure what it is.
Philipp Ost later replied and told me that this is a mole cricket, almost certainly a Gryllotalpa brachyptera.
| Saturday, 28 April 2007 | Echunga | Images for 28 April 2007 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
And the rain continues! From the daily rainfall bulletins of the Bureau of Meteorology, shortened and made to fit this page:
D A I L Y R A I N B U L L E T I N : S O U T H A U S T R A L I A
(Produced 16:25 on Saturday, 28 April 2007)
24 Hours to 9 AM Saturday, 28 April 2007
---------------------------
! ! !
! STATION ! RAIN !
! ! mm !
---------------------------
! ADELAIDE ! 16 !
! ERNABALLA ! !
! ECHUNGA ! !
! MEADOWS ! !
! WOOMERA ! 0.2 !
---------------------------
We live half way between Echunga and Meadows. The zero rainfall looks like this:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Our rainwater tank is full to overflowing earlier in the season than ever before, and we have rivers of rain running down the paddocks. It would be nice to know what the real rainfall was, but the people who predict future weather can't even document current weather.
Quiet day, spent catching up on a few things.
| Sunday, 29 April 2007 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent some time today playing around with Google Maps' My Maps service, and started a map of where I have lived and worked, which was fun but took up far too much time. One of the sad things about web-oriented software is that it's slow and clunky, and so far I haven't found a way to create a backup or do general modifications. For example, I might decide to split it into two maps, one showing where I have lived and one showing where I have worked. How do I do that? Maybe it's available, or maybe Google will come up with the facility, but in general it goes against the “immediate” nature of web interaction.
Philipp Ost writes to tell me that the “cicada” I found the other night is probably a mole cricket. The proportions of the insect in the photo are somewhat different, but there are lots of different species, and maybe it's a slightly different one.
We've been discussing tuner drivers on the FreeBSD-multimedia mailing list. It's a thing I don't know much about, and so I decided to first find some documentation. This is multimedia, of course, so there's not too much. The page on the linuxtv wiki should be the place to look for that sort of thing, but it's very deficient, and so I took a look at the Wikipedia page, which was also a bit flaky, so spent some time tidying that up. It still doesn't have the kind of information I'm looking for (otherwise I wouldn't still be looking for it).
| Monday, 30 April 2007 | Echunga | |
| Top of page | ||
| previous day |
Spent some time today further researching documentation for tuner cards. I could have sworn that I had found something somewhere, but despite the fact that I normally save such links, I couldn't find anything. It seems to me that nowadays the most successful people are those who can search the web most efficiently. While that's definitely an advantage, it seems that limiting the requirement to search for everything should be taken more seriously.
In that spirit, decided to dissect and document FreeBSD's bktr driver, and to my surprise made relatively good progress. That begs its own questions, of course: what's the best way to document a driver?
Message from James Andrewartha about Google's “My Maps”:
There's a KML link [1] for your "My maps" map (Google is getting as bad as Microsoft for naming things), and there's fairly good documentation for KML http://code.google.com/apis/kml/documentation/kml_tut.html
Do you have a comment about something I have written? This is a diary, not a “blog”, and there is deliberately no provision for directly adding comments. It's also not a vehicle for third-party content. But I welcome feedback and try to reply to all messages I receive. See the diary overview for more details. If you do send me a message relating to something I have written, please indicate whether you'd prefer me not to mention your name. Otherwise I'll assume that it's OK to do so.
| Top of page | Previous month | Greg's home page | Today's diary entry | Next month | Greg's photos | Copyright information |
