|
| Greg's diary |
| November 2006 |
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Wednesday, 1 November 2006 | Echunga | |
| Top of page | ||
| next day | ||
| last day |
Quiet day. Yvonne's off to Germany tomorrow, and we spent a some time preparing for that—apart from packing there's also the work that I will have to do which previously Yvonne did. Spent some time working on some coding guidelines; it's a pity that they won't interest anybody outside the project.
| Thursday, 2 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yvonne off to Germany today, which shouldn't have taken much time on my part, but somehow I didn't get started with anything else until early afternoon. More tidy up work; tomorrow we can finally start some real testing again.
Finally took a look at the rainfall bulletin for last month. It's shocking for at least two reasons: firstly, the rainfall was only about 5% of the normal (the L in the Decile column indicates the lowest on record), and secondly the report itself is in conflict both with other information on the same site, and also with reality. For example, no rain was reported at all for Echunga: that seems to be a common occurrence. And surely they must have averages for McLaren Vale, one of Australia's most important wine-growing areas. I wonder how much we can trust the other values.
MOUNT LOFTY RANGES (23C)
Rain (mm) Rain Days Decile
Obs | Avg Obs | Avg
Echunga 70.1 13
Hahndorf 3.2 74.7 4 13 L
Kuitpo Forest 3.2 5
McLaren Vale 1.0 1
Meadows 3.0 75.6 1 12 L
Mount Barker 1.8 68.1 4 13 L
| Friday, 3 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yvonne's gone, leaving me with some extra work to do, though it wasn't as bad as I feared. After my recent web page work, back to testing the video recording application, once again telephonically with Peter Denton, and made reasonable progress. I always like commits that remove much more than they add:
revision 1.9 date: 2006/11/03 05:52:05; author: grog; state: Exp; lines: +21 -113 Rewrite to set the state segemnt. Clean up much cruft in the process.
Weather is still an interesting topic, and I went looking for comparative graphs of rainfall and temperatures in different parts of the country. The Bureau of Meteorology has the data, but it's in tabular form, and I'd like a graph. Spent some time wondering how to get gnuplot to use the data, without success. The problem is that I have rows like this, representing average monthly rainfall in Stirling:
JAN FEB MAR APR MAY JUN JUL AUG SEP OCT NOV DEC ANN No. %age
Yrs comp
36.8 37.5 54.3 96.7 132.4 118.0 175.1 147.2 119.7 91.9 61.7 47.0 1118.2 20.8 100
I want to plot the rainfall by month, but gnuplot expects the data to be in columns, not rows. I'm sure there must be a utility to turn things on their side, but I wasn't able to find one in a reasonable time.
| Saturday, 4 November 2006 | Echunga | Images for 4 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
I've been taking weekends quietly lately, but this weekend decided to do even less. Apart from the normal chores, did very little.
It's been nearly 6 years since Miss Teak broke a leg and had to be put down. We planted a red-flowering eucalyptus on her grave; this year it's (finally!) flowering:
In the evening, addressed an issue that has annoyed me about mplayer for some time: the on-screen time display bears no relationship to reality when displaying MPEGs (recorded or directly) from digital TV. It seems that the time information embedded in the stream does not get converted, so the “elapsed time” seems to be randomly distributed in the range 0 to 30 hours. Made a change to at least partially fix that—simply subtract the time of the first frame from the elapsed time, and things work almost correctly. That can definitely be improved on, though, so I won't publish yet. In passing I'm once again amazed by how simple it is to make this kind of fix to mplayer, despite a desperate lack of comments. Given that there's no other technical documentation, that's a particular challenge.
| Sunday, 5 November 2006 | Echunga | Images for 5 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
I may have been quiet lately, but today I steeped things up and did almost nothing, apart from going into Mount Barker and doing some shopping.
More information about the nature of the blockage in the dam water pipes:
|
|||||||||||||||||||||||
At the left, two parts of a yabbie claw are clearly visible. They must each be about 1 cm long. We've had yabbies in the water system in the past, but I thought they were now all gone.
| Monday, 6 November 2006 | Echunga | Images for 6 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Into town this morning for a scheduled dentist's appointment, and then spent a surprising amount of time shopping. BiLo is now a name of the past; they've been taken over by Coles, not necessarily an advantage from what I experienced today. Couldn't find any coconut cream: the shelves were empty, and all they had were significant quantities of “Lite” coconut cream, which is something I haven't seen before. I strongly distrust anything with “lite” (or even “light”) in its name. Tried to find customer care, but to get to them you have to leave the supermarket. What genius thought that out?
Finally found somebody who said that they were suffering some supply problems, so left them and went to Woolworths, where I found the normal stuff, along with even more “lite” cream. The house brand costs $0.82 per 400 ml, the same price as the “lite”. It's worth looking at the cans:
|
|||||||||||||||||||||||
The normal coconut cream contains 68% coconut, and the “lite” version contains only 23%, almost exactly a third; the rest is water. So if you need 1.2 litres of “lite” coconut milk, you can either buy one can of normal cream and dilute it 2:1 with water, or you can pay 3 times as much to buy 3 cans of “lite”. Why would you want to do the latter?
Down to Bonnetts, where Yvonne's saddle, sent for a quotation, had been repaired—total cost $10. They didn't even do a bad job: it's difficult to recognize where the damage was:
|
|||||||||||||||||||||||
Somehow didn't get much work done today.
| Tuesday, 7 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Peter Jones over in the morning for a talk about installation and updating, and made good progress. It does mean that I'll have to completely overhaul the database design, but that's not as much work as it sounds. Spent most of the day working on that.
| Wednesday, 8 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Over to Hahndorf this morning to investigate the results of some off-site testing. They're not good, and leave us wondering where the project is going.
Didn't get much done today.
| Thursday, 9 November 2006 | Echunga | Images for 9 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
The dam water line is blocked again! It had occurred to me some time ago that the water I pumped up to reverse flush it probably wasn't enough; measured the trough and found that it contained about 475 litres. The pipe to the dam has a 50 mm internal diameter, which corresponds to about 2 litres per metre. How long is it? It's difficult to say, since it's underground, and it's not in a straight line from the dam. but my best guess is about 400 metres, or 800 litres. That would mean that the water in the trough would only reach half way, obviously enough only to dislodge the blockage, but maybe not enough to get it out of the pipe back into the dam. Decided to pump water from the fire fighting tank (which proves to claim to be 2500 gallons, or 11,400 litres; we bought it as a 10,000 litre tank) back up to the dam. That proved to be easier than I had expected, and made me wonder why I had thought of the trough in the first place:
|
|||||||||||||||||||||||
Pumped about half the tank (over 5,000 litres) of water up the pipe, during which time the tiny petrol tank of the pump ran dry twice. What idiocy! What use is a fire pump that requires you to pour petrol around in the middle of a fire?
On the work front, finished off the changes I had started earlier in the week, committed them and shelved the project for the moment. Spent the afternoon cooking; I should have more time for this sort of thing.
| Friday, 10 November 2006 | Echunga | Images for 10 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
My assumptions about the blockage in the dam water supply line were amply confirmed today. Suddenly I had an extra sprinkler, and one of them threw 2 metres further, onto the verandah:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
The extra “sprinkler” was a dripper line that had blown off the connector because of the higher pressure. Let's hope that that's the end of the blockages.
Claire Baker had sent me some updates for the web site of the ICT Council for South Australia, which is dire need of it, so spent some time doing that. Most of the time was just general cleanup of the HTML; it's not worse than that of other sites, but it's really disappointing how bad most HTML looks. Maybe that's one of the down sides of content management systems (which I still can't see as anything except a workaround for lack of availability of a good text editor).
In the afternoon, had intended to look at freevo, which I had recently installed on teevee, but somehow got sidetracked to looking at synergy instead. synergy is a program that shares the keyboard and mouse across multiple systems. Unlike x2x, it works across multiple platforms, not just for X. Also unlike x2x, it doesn't understand X displays, and I spent quite a bit of time trying to make sense of the (relatively voluminous) documentation before discovering that it simply doesn't cater for more than one display per “system” (i.e. IP address). Managed to get it working for boskoop (which until now I had been calling boskopp; the latter is a popular spelling in Germany, but it seems that Boskoop is a town in the Netherlands, so I've had to adjust the spelling accordingly).
Also tried to get it to work with Microsoft “Windows XP”, but the latter didn't have any configuration file, and the GUI setup didn't seem to provide a way to create or import one. That's not a particular problem; I didn't really want to connect it anyway. The good news is that it works in conjunction with x2x, so once I can work out a way to simulate the “Apple” key on my keyboard, all should be well.
| Saturday, 11 November 2006 | Echunga | Images for 11 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Another quiet day. Spent some time writing up the discussion on eggs below, and had my first attempt at running freevo. The documentation is of the usual quality, or maybe a little better. It starts off giving all sorts of details of how to install it, all done automatically for me by the FreeBSD Ports collection, and then doesn't tell you how to start the program. It does tell you how to configure it, which is fortunate. It's relatively straightforward if you want the defaults (NTSC, 800x600 display). Tried with my setup and entered:
=== root@teevee (/dev/ttypb) ~ 31 -> freevo setup --geometry=1280x720 --tv=pal --chanlist=australia
System path first=No
checking for mplayer... /usr/local/bin/mplayer
checking for mencoder... /usr/local/bin/mencoder
... many more of these
geometry must be one of: 800x600 768x576 640x480
Wow! That makes it pretty useless. I suppose I need to go back and try my luck with MythTV again. Or maybe I should learn python and fix it. Continued anyway and was able to point it at my Maybe directory (for stuff that I may look at if nothing else comes up), and found:
That scared me—did it maybe first delete the contents? No, they're still there:
=== root@teevee (/dev/ttypb) /spool/Images 43 -> l Maybe/
total 40652
-rw-r--r-- 1 grog wheel 4700372992 Jul 25 19:45 W26-Ideal-Husband
-rw-r--r-- 1 grog wheel 6675234816 Sep 5 10:34 englar-anheimsins
-rw-r--r-- 1 grog wheel 6068109312 Oct 11 14:40 gycklarnas-afton
-rw-r--r-- 1 grog lemis 6958350336 Sep 23 00:54 l-idole
-rw-r--r-- 1 grog wheel 6978273280 Sep 18 00:55 pasir-bersibik
-rw-r--r-- 1 grog wheel 3641704448 Sep 19 02:00 stupeur-et-tremblements
-rw-r--r-- 1 grog wheel 7583301632 Sep 12 15:05 vertical-de-lete
The problem is, of course, that the thing insists on “extensions”. Once given that, it works, but I still can't display full screen.
|
How to boil an egg
|
Topic: food and drink | Link here |
Yvonne left me with 18 fresh eggs in the fridge, so I've been having a boiled egg for breakfast every day. It's easy to boil an egg, right? That's why none of my myriad cookbooks have details. Somewhere in the back of my head I had this concept of a “3 minute egg”. The first time (not recently) that I tried this, the egg came out almost raw: only some of the white had started to coagulate.
What went wrong? Details, as usual. There are two basic ways to boil an egg:
Put an egg in cold water in a saucepan, bring to the boil, and boil for three minutes. This will give you an egg where (roughly) the white is solid and the yolk is still liquid.
Bring some water to the boil in a saucepan. Add the egg and boil for six minutes. Again, this will give you an egg where (roughly) the white is solid and the yolk is still liquid.
I went looking on the web and found references to both methods: eHow.com gives only the first method, while Delia online gives both, the second with a twist: take the pot off the boil after one minute and leave another 6 minutes (7 in total).
Somehow both of these are missing a number of important points:
The boiling time for an egg is dependent on its weight, and more importantly, its diameter. The eggs I have here range in weight from 44 g to 71 g, and from 40 mm to 47 mm. The eggs in these photos both came in the same box.
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
No recipes I know address the diameter of an egg, and almost none address the weight. The EU regulations divide eggs into 7 classes. Class 7 is anything less than 45g (like my second example), class 1 is 70 g and more, and the others are in 5 g steps in between. My old copy of the American book “The Joy of Cooking” states that the recipes are for 2 oz (i.e. 57 g) eggs, probably rather smaller than most eggs nowadays.
The cooking time depends on the following factors:
The temperature at the surface between the water and the egg. This is easy to specify for the second alternative: it's 100°.
The surface area itself. For a first approximation, we can assume that the heat flow into the egg is proportional to the surface area.
The diameter of the egg. The further the heat has to go, the longer it will take.
The mass (“weight”) of the egg. The cooking time is roughly proportional to the heat flow divided by the mass, and thus the surface area divided by the mass. For eggs of the same shape, the mass is proportional to the cube of the diameter, and the surface area to the square of the diameter, so this ratio is proportional to the 1.5th power of the diameter.
The previous point would be more exact if the heating were very gradual (i.e. the temperature differences small). That's not the case here: in the second case, we have an egg at about 20° being plunged into water at 100°. The first case is more complicated, but even there the temperature of the water rises much faster than the temperature of the egg.
At a first approximation, I'd assume that the cooking time in hot water is proportional to the radius (and thus the diameter) of the egg: in other words, the time taken to get the heat to the middle of the egg depends on how far it has to travel. Combined with the previous factor, this would suggest a cooking time in proportion to the 2.5th power of the diameter.
The previous calculations make a number of implicit assumptions. in particular that the thermal resistance of the shell is the same as the inside of the egg (also assumed to be uniform). But it's a basis for thought.
Even if you assume that the cooking time is roughly proportional to the diameter, the egg with 47 mm diameter would take nearly 20% longer to cook than the egg with 40 mm diameter—that's over a minute difference for the second method. It's difficult to guess what the difference is for the first method.
Eggs are relatively fragile. If you put a cold egg into boiling water, the pressure inside will build up suddenly, and the egg may crack or burst. The larger the temperature difference, the more likely this is to happen.
There's a simple solution for this, but I haven't seen it in English-speaking countries: an egg piercer:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
You put the big end of the egg onto this device and press down; the spike in the middle makes a small hole in the shell, which allows the pressure to adjust.
The cooking time depends on the initial temperature of the egg. Many warn against taking the egg directly out of the fridge: Delia writes:
Don't ever boil eggs that have come straight from the refrigerator, because very cold eggs plunged straight into hot water are likely to crack.
I've already addressed that issue. But what difference does the initial temperature make in the boiling time?
If you put the egg in cold water and bring it to the boil, you have at least two sources of inaccuracy:
The time it takes for the water to come to the boil depends on the strength of the flame and the amount of water. During this time about half of the cooking takes place, as you can see by the comparison of the cooking times for the two alternatives.
The time it takes for the water to come to the boil is also dependent on the number of eggs you put in the water: the more, the longer it takes to boil.
It's difficult to decide exactly when the water is boiling. Is it when the first large bubbles appear? Or when it's boiling vigorously? These two events can be 30 seconds apart.
Delia's idea of taking the water off the boil after a minute also introduces a small inaccuracy: the remaining time depends on how quickly the water cools down. The fact that she adds a minute to the cooking time suggests that this is non-trivial (in fact, I wouldn't expect it to make that much difference), but she doesn't explain what use this twist is.
When removed from the water, the surface of the egg is hotter than the middle. If you don't do anything, heat will continue to transfer to the middle, and it will continue to cook. You can slow this down by running cold water over the egg after removing from the saucepan. eHow mentions this, but Delia doesn't.
What does this mean in practice? I use method 2 because it's more reproducible. Ultimately you're going to have to find your own times, but if you have a box of eggs like the ones shown above, you'll have an idea how to proceed. I've been eating the big eggs so far; when I get to the small ones, I'd guess that they will only need 5 minutes instead of 6.
| Sunday, 12 November 2006 | Echunga | Images for 12 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finally it has rained! Or at least, there was a heavy dew:
|
|||||||||||||||||||||||
On the other hand, if you ask the Bureau of Meteorology, it didn't. From this morning's rainfall bulletin:
(Produced 10:00 on Sunday, 12 November 2006) 24 Hours to 9 AM Sunday, 12 November 2006 STATION ! RAIN |---------------------- ECHUNGA ! HAHNDORF ! 18 MCLAREN VALE ! 16 MEADOWS ! MT BARKER ! 20
This is no isolated incident. When looking at last month's disastrous rainfall results, I have no confidence that the figures given represent the reality.
Spent much of the afternoon with more experimental cookery, specifically things that Yvonne doesn't like. I'd like to make a cassoulet again, but it's almost impossible to get one of the key ingredients, confit d'oie an ingredient so foreign to the English way of cooking that I don't even know how to translate it—neither do any of the references I can find on the web. It's goose cooked and salted and preserved in its own fat.
One of the big problems with casoulet is finding a definitive recipe. There are two basic kinds, the cassoulet tolosain and the cassoulet de Castelnaudary. The quantities and the methods and times of cooking also vary wildly. And the otherwise excellent Time-Life cookbook series that was printed in the 1970s omits the confit d'oie, presumably because of the difficulty of finding it.
So today I tried making a cassoulet-like dish mainly with the intention of getting the quantities right. A good thing too: they were way off. In particular, all recipes seem to specify too few beans.
I started with three sources of recipes:
Time-Life “The Cooking of Provincial France” in two versions (English and German, the latter for usable units of measurement). This was published in 1968 as the first of a series of cookbooks, and in general I've found them very good.
La cuisine du marché by Paul Bocuse, published by Flammarion in 1980.
La Cuisine de Madame Saint-Ange, published by Larousse, this edition in 1982.
These recipes differ greatly in the recipes, and they all seem to have too few beans. Here's what I used:
| Weight | Ingredient | Step | |
| 500g | beans | 1 | |
| 300g | lamb, from leg | 2 | |
| 250 g | pork, from forequarter | 2 | |
| 150 g | duck fat | 3, 8 | |
| 20 g | couennes (pork skin) | 4 | |
| 75 g | smoked ham | 2 | |
| 500 g | onions | 5 | |
| 25 g | garlic | 5 | |
| 170 g | double-smoked Moscow sausage | 6 | |
| 245 g | double-smoked Kransky sausage | 6 | |
| 800 g | tinned tomatoes | 6 | |
| 50 g | bread crumbs | 8 | |
Soak the beans in lukewarm water for 2 hours. The purpose is not to soften the beans, but just the skin. Longer soaking will provoke fermentation.
The beans should be “fresh” (i.e. from the last harvest). Madame Saint-Ange and Bocuse are both in agreement that old beans detract greatly from the quality of the dish. They will split, and the interior will remain granular.
Brown the whole pork and lamb in a frying pan.
Bring 2 litres of water to the boil and add beans, meat and 100 g duck fat. Bring back to the boil and salt lightly (salt tends to harden the beans). Simmer at the lowest possible heat for two hours.
Steam the couennes for an hour, then cut into small strips.
Chop and fry onions in duck or mutton fat until glassy, and then add crushed garlic, fry for a couple of minutes. Reserve.
After two hours, add the sausage and tomatoes, check the salt and boil on low heat for another hour.
Drain the pot, keeping the broth for later, and separate beans and meat. Chop meat into 5 mm slices (Bocuse recommends 3 mm). At this point it became clear that I had too much meat, so I split it into two parts, one for a later cassoulet.
|
|||||||||||||||||||||||
Place a layer of beans at the bottom of a casserole, cover with sausage slices, followed by another layer of beans, the meat, onions and couennes, and a final layer of beans:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
I had already used 500 g of beans where the recipes recommended more like 400 g, but at the end, I had almost none left over for the next cassoulet:
|
|||||||||||||||||||||||
Cover the top with breadcrumbs, pour in the reserved broth to cover, then pour duck fat over the top.
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Bake in the oven until the surface is browned. This didn't work too well for me; the breadcrumbs soak in the broth and don't brown easily. Clearly it needs to be grilled from the start:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
What will I do differently next time? In proportion, there was far too much sausage and onions, and far too few beans and almost no couennes. It also tasted too much on the “smoked” side. Here are the proportions I'll use next time.
| Quantity | Ingredient | Step | |
| 400g | beans | 1 | |
| 200g | lamb, from leg | 2 | |
| 125 g | pork, from forequarter | 2 | |
| 150 g | duck fat | 3, 8 | |
| 50 g | couennes (pork skin) | 4 | |
| 200 g | onions | 5 | |
| 15 g | garlic | 5 | |
| 250 g | double-smoked sausage | 6 | |
| 400 g | tinned tomatoes | 6 | |
| 50 g | bread crumbs | 8 | |
Note that the smoked ham is gone, and that there is only one (unspecified) kind of sausage.
| Monday, 13 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
A couple of people have sent me feedback about the egg boiling article. Tom Maynard comments:
Mayhaps you are overanalyzing your egg preparation technique? AFAIK, eggs are edible in every stage from raw to hard-boiled (and beyond). A perfect 3-minute egg exists in my memory, in my G'ma's kitchen, without any science behind it at all—save 30-50 generations of “technique.”
Clearly you don't need all this background to boil an egg, but it helps to understand the issues. I'm reminded of a fortune cookie in the FreeBSD fortunes files:
Ray's Rule of Precision:
Measure with a micrometer. Mark with chalk. Cut with an axe.
I need to accept the fact that my tools are getting out of date. I've been using mutt for years now, but its weaknesses are beginning to show: it uses an external program, urlview, to select URLs embedded in the message. urlview doesn't understand the format of the text, and it lists all the URLs together. In addition, because it doesn't understand the format, you get all the URLs from a multipart message displayed together, and if it's in quoted-printable, the result is nonsense. For example, from a message like this one:
Date: Sat, 11 Nov 2006 01:26:39 GMT-07:00 From: eBay <savedsearches@ebay.com> Subject: eBay Favorite Search: powermac Item title: Apple PowerMac G4 733 Quicksilver 40Gig CD-RW OS X Zip! Item URL:urlview displays:http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=320047726993&ssPageName=ADME:B:SS:US:1Buy It Now price: AU $499.95 Shipping: Not Specified End time: Nov-13-06 01:13 PST Item title: Apple PowerMac G4 350MHZ 256MB/30GB/VGA Item URL:http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=150057768140&ssPageName=ADME:B:SS:US:1Current bid: AU $85.00(0 Bids) Shipping: Not Specified End time: Nov-15-06 18:12 PST
UrlView 0.9: (44 matches) Press Q or Ctrl-C to Quit!
-> 1 http://pages.ebay.com/help/confidence/name-userid=
2 http://search.ebay.com.au/ws/search/SaleSearch?sosortproperty=
3 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=
4 http://search.ebay.com/ws/eBayISAPI.dll?=
5 http://my.ebay.com/ws/eBayISAPI.=
6 http://cgi1.ebay.com/aw-cgi/eBayISAPI.dl=
7 http://cgi1.ebay.com/aw-cgi/eBayISAPI.dll?Unsub=
8 http://pages.ebay.com/education/spooftutorial/
(many more)
Where are the URLs that were shown above? No idea. One might be item 3, but it's so mutilated that you can't tell. The problem here is that the original message is in quoted-printable, and mutt doesn't decode that for urlview.
In addition, mutt has the problem that it displays on a terminal window, which has a predetermined character set. I'm still using ISO 8859-1, so much stuff is just displayed as ?. Also, it doesn't handle format=flowed correctly. I suppose I could fix it, but I get the impression that there isn't much energy behind the mutt project any more. Everything is going into the GUIs.
OK, I thought, another attempt. Installed sylpheed-claws. Fired up and got Yet Another Horrible Paned Window (and only one of them). The text, on my 1600x1200 display, was miniscule. Fixed that as best I could (the text got bigger, but the menus and frames were in the same flyspeck), moved to another screen (2048x1536) and it was suddenly gigantic! I've already complained about similar problems with firefox. Why is it that text sizing is such a problem for GUI software?
Apart from that, the more I see of these paned windows, the more I hate them. How can people live with an arbitrary subdivision of the screen? The whole idea of windowed environments was supposed to be get away from that sort of problem. Why not a window set, in this case with, say, an index window, a folder menu and one or more message windows, each individually resizeable, and maybe handled as a set by the window manager?
And, of course, there's this “there can only be one” mentality: it seems that you can only start one copy of sylpheed-claws. If you try to start another one, it gives focus to the one already running, even if it's on a different display. This is stupid, pointless and a show-stopper for me. When I'm in the lounge room watching TV, I can start another mutt window and view my mail from there, while the mutt in the office stays as it is. sylpheed-claws would just transfer control to the version running in the office. A waste of time.
Another disappointment is firefox 2.0. I upgraded to it recently and discovered that, even though I have done my damndest to disable this stupid “tabbed browsing” misfeature, it does it anyway under some circumstances, and I can't find a way to disable it. Today I tried updating a WikiPedia article, and pressed Alt-P for the preview. Nothing happened. I had to scroll down to the bottom and press the “Preview” button. When I was finally finished, I pressed Alt-S and was given some firefox function. So now I have lost more functionality. Every change in firefox seems to make it worse. Maybe there's a way to fix it—I hope so—but it wasn't obvious, and the configuration menus don't offer any help. Backed it out and installed the latest version of 1.5 instead.
Where is software development going? Am I really behind the times because I can't put up with things that make my life harder?
| Tuesday, 14 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent a lot of today working on the MythTV port to FreeBSD, based on the work of Stacey Son 18 months ago. He did his work based on revision 0.17 of MythTV, but in the meantime they're up to revision 0.20, and a lot of things had changed. It took most of the day, but finally I got it to build cleanly. Now to see if I can also get it to work, and if I don't find something that drives me crazy about the interface.
Message from Michael Hughes referring to my report about telling me that sylpheed-claws can, indeed, separate its panes into individual windows. Tried that and confirmed that it works—all on the same display, of course. If this seems silly, I really do use two displays for my mutt mail: I do the reading on wantadilla:0.1 (straight ahead in the photo):
|
|||||||||||||||||||||||
and reply via an emacsclient window on echunga:0.0 (to the immediate right, the black monitor in that photo). And, of course, it still doesn't address the “there can only be one” problem.
| Wednesday, 15 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Had intended to work on the MythTV port today, but in the middle of all that got a call and a couple of strangely formatted and formulated mail messages from Hahndorf; looks like our project is moving again. Spent some time looking at the web pages, writing more PHP/MySQL code. I thought I had got the knack of it, but it still took a fair amount of work to get right.
Working on the MythTV port showed that I'm not out of the woods yet. It builds, but doesn't install, and I'm still having difficulty conveying the environment variables (in this case QMAKESPEC) to the underlying build. It works fine if I set it from the shell. The same thing should work via the Makefile if I specify it in MAKE_ENV; but it doesn't. More head-scratching. Also it tried to install non-existent programs, and it looks as if I'm going to have to add some serious post-installation scripts: currently it tries to install the database as the non-existent user mythtv.
| Thursday, 16 November 2006 | Echunga | Images for 16 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Yvonne got back from Europe today, not without a delay which made her miss her connection in Melbourne. She seemed pretty bright, so on leaving the airport, and after marvelling yet again how badly designed the people and traffic flow is, dropped into IKEA, which opened recently just outside the airport. We had just intended to take a look, but ended up buying quite a bit: they have a number of things that we had been looking for (though not egg piercers). One thing that I didn't buy was a corkscrew, though I was tempted:
|
|||||||||||||||||||||||
Back home, picking up a laptop from Peter Denton on the way, and spent the afternoon installing the application on it for demo purposes, in the process discovering a few bugs in the build process.
After a double all-nighter, you'd expect Yvonne to have been exhausted, but in fact she held out as well as I did: it's as if her tiredness washed off on me. Early to bed.
| Friday, 17 November 2006 | Echunga –> Ballarat –> Dereel –> Rokewood | Images for 17 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Chris Yeardley has just moved house (well, about 6 weeks ago, and not really “house”), and we've been keen to see what it looks like, so this morning, despite the fact that it had been less than 24 hours since Yvonne returned from Europe, we set off on a 650 km road journey to Dereel. Stopped in Nhill for food, and made the mistake of ordering some ham and cheese sandwiches; we had forgotten how basic a $3 sandwich can be, and I'd like to do so again.
Chris is still living in a shed while they finish the house, so down to Rokewood to find a bed and breakfast and something to eat—at the local pub, something that reminds me that pubs are not our style. Food was OK, but took 40 minutes to arrive, by which time all our clothing stank of tobacco. Took Chris back home, then in to the bed and breakfast, “Whispering Gums” in Aitchison St., where the hosts (Bev and Jim; never found out what their surname is) invited us in for a “glass of red” and a talk. Late to bed.
| Saturday, 18 November 2006 | Rokewood –> Dereel –> Ballarat –> Echunga | Images for 18 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Up correspondingly late this morning and in to get a breakfast from Bev, including duck eggs (it seems that it's a legend that they have to be hard-boiled, as long as all parts are a little cooked), and enough to feed an army. Then off to Chris' place and took a good look around. It's a nice area, and one of the few places in Australia where you can ride around freely (most of the area is forest), but despite the relative closeness of big cities (32 km to Ballarat, about 110 line of sight to Melbourne CBD, and more like 50 to the outskirts), no ADSL is available.
Chris had just received a letter from Telstra saying that, though the preliminary testing had suggested that she could get ADSL, in-depth testing of the (newly installed) line had shown that it was not possible. She could get satellite if she liked.
What a load of nonsense! As I see it, the terms have the following meanings:
| Preliminary testing | Establishing whether the exchange has a DSLAM. |
| In-depth testing | Checking the cable record to calculate the theoretical attenuation of the line in question, and whether it has a pair-gain system. |
In Chris' case, the exchange is in Corindhap, an estimated 7 km away. That's too far for Telstra's interpretation of ADSL attenuation; they make a sharp cutoff at 4.1 km, as Internode's graph shows. Never mind that the exchange almost certainly has an ADSL 2 DSLAM, but for political or marketing reasons Telstra hasn't enabled it yet, and that ADSL 2 can reach significantly further than ADSL. I wonder how many people are suffering because of this rigid policy.
Even these calculations are unnecessarily conservative, or Internode's graph is wrong. I have seen an extract of the cable record check for my ADSL line, the summary is:
... 1443 meters of 64CPFUT cable at 7.19 dB/Km loss (10.37517 dB) 2 meters of 40PEIUT cable at 11.52 dB/Km loss (0.02304 dB) 2 meters of 40PIUT cable at 13.81 dB/Km loss (0.02762 dB) [Adding 10.5dB of fudge factor for 3 bridge tap(s) greater than 25 meters] Total cable length: 4666 meters Total cable losses: 52.81714 dB at 300kHz
That's 566 metres longer than Telstra services. Looking at the end of the cable, it stops with two 2 metre lengths of cable. That must be the box on the street. After that comes a 100m length of cable to the house, a junction box and another 30 metres to my office. Assuming a loss of 10 dB/km, that would add 0.13 dB, giving total cable losses of almost exactly 53 dB. This is surprisingly close to the 54 dB or so that my ADSL modem typically reports. This gives a downstream margin of 18 dB, which presumably would be enough for another 1.8 km or so (or 2.5 km with a low-loss cable like the 64CPFUT at the top of my example). That alone would make 7 km, without techniques such as ReADSL2. I wonder why nobody is getting up and shouting about the situation. Maybe they are, and I just haven't heard.
None of this means that Chris really can get ADSL, of course. But I have the distinct feeling that Telstra has put the issue onto the “too hard” pile. As the monopoly owner of Australia's “last mile” infrastructure, that's not good enough. The very least they could have done would be to give a reason why their “in-depth testing” revealed that she couldn't get ADSL.
Looked round the property and the house in the morning, then off on the long drive back home. We must be crazy driving 1400 km for just a few hours' visit. After yesterday's disaster with the sandwiches, bought some food at a “Subway” outlet on the way out of Ballarat. I don't particularly like Subways, especially the way they make them in Australia with tired, soggy bread, but the fact that they were only about the same price as the sandwiches in Nhill yesterday makes it more understandable why they're doing so well here.
Took a look around the countryside again, then for the fun of it left the main road (Western Highway) at Horsham and took the road to Edenhope, Narracoorte and Padthaway. It's amazing how little traffic there is off the main highways; between the outskirts of Horsham and Narracoorte, about 150 km, I encountered about 20 cars, only two driving in my direction.
| Sunday, 19 November 2006 | Echunga | Images for 19 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Didn't do much today, mainly catching up after our trip in the last couple of weeks.
While in Germany, Yvonne bought some odds and ends that are difficult to find here, including a meat thermometer. For years I've had a meat thermometer which you stick into the meat, but in the course of those years it has acquired a coating that makes it difficult to read. Similar thermometers are available in Australia, but they're made in America, where they still use antiquated units of measure, and the adaptation to Celsius is an afterthought, so the markings on the scale show temperatures like 54°, 65°, 71°, 77°, 83° and 88°. The one Yvonne brought back was in Celsius, but it was obviously designed for illiterates:
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Presumably the illiterates know their farmyard animals, though. But I still can't guess what some of the graduations on the scale mean, and the lack of display of low temperatures makes me feel uncomfortable; how do I know that the thing isn't off by 10°?
The obvious choice would be a digital thermometer, but the only one I found had problems with the temperature sensor: it was far too influenced by the surrounding temperature, so I had to wrap an insulator around the exposed part. It also overheated and burnt out on one experiment. Nevertheless, we found one at IKEA on Thursday:
|
|||||||||||||||||||||||
We'll see if it's any better.
| Monday, 20 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Peter Jones and some others are off to Brisbane for a demonstration tomorrow, so over to Hahndorf to look at some last-minute details, none of which took very long, and I was out again after little more than an hour.
In the afternoon, more work on web pages with PHP. Rasmus says it's just like C, but he's wrong: the syntax looks very much like C, but the whole feel of the language is different, and as a result debugging is very different. Also, the fact that it's basically a report generator (the output is the most important thing) makes for a different interaction. Still, by the end of the afternoon made significant progress with the most complicated of the pages.
| Tuesday, 21 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Finished my work on Peter Denton's laptop this morning, shut it down and tested a reboot. I couldn't start X! Spent some time investigating, and decided that some of the ports conflicts were the issue, so deleted and reinstalled X and KDE.
That in itself was an issue, because I didn't have both of the install CDs for FreeBSD 6.1-RELEASE. Started burning the second CD when it occurred to me that I didn't need a CD at all; simply:
=== root@echunga (/dev/ttypb) ~ 73 -> mdconfig -a -t vnode -f /src/ISOs/6.1-RELEASE-i386-disc1.isomd0=== root@echunga (/dev/ttypb) ~ 74 -> mdconfig -a -t vnode -f /src/ISOs/6.1-RELEASE-i386-disc2.isomd1=== root@echunga (/dev/ttypb) ~ 75 -> mkdir /cd1 /cd2=== root@echunga (/dev/ttypb) ~ 76 -> mount -t cd9660 -o ro /dev/md0 /cd1=== root@echunga (/dev/ttypb) ~ 77 -> mount -t cd9660 -o ro /dev/md1 /cd2=== root@echunga (/dev/ttypb) ~ 79 -> dfFilesystem 1048576-blocks Used Avail Capacity Mounted on ... /dev/md0 505 505 0 100% /cd1 /dev/md1 574 574 0 100% /cd2
After reinstalling everything (in the case of KDE, this required the -f flag to pkg_add, because there were different versions of MySQL), X still wouldn't start: it turned out that I had installed the production xorg.conf file. Removing that was enough: it seems that the real configuration file was in a different location, but that the production one (/etc/X11/xorg.conf) was found first.
In the afternoon finally started catching up on other things. I really need to work less.
| Wednesday, 22 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Spent most of today looking at remote controls under FreeBSD. I have this remote control that came with the DVICO tuner card; it's unclear what the real name is: the unit itself bears the name “FusionREMOTE”, but the Linux dmesg output states:
hiddev96: USB HID v1.10 Device [DVICO DVICO USB HID Remocon V1.00] on usb-0000:00:10.0-2
It's also not clear which letters are written in capitals and which in lower case; I've also seen “DViCO” and possibly others.
I've already had considerable pain trying to get lirc, the Linux Infrared Remote Control software, to work. There's a partial port for it in the FreeBSD Ports Collection, so decided to play around with that. Discovered that my particular remote control uses the HID (Human Interface Device) interface, called /dev/usb/hiddev in Linux. The corresponding FreeBSD device is /dev/uhid. Played around with uhidctl(1) and added a hex dump feature that showed that repeated data sets the high-order bit of the (16 bit) data word:
Microsoft:0x0001.Button:Button_1=1 [0x1] Microsoft:0x0001.Generic_Desktop:Vno=21502 [0x53fe] Microsoft:0x0001.Button:Button_1=1 [0x1] Microsoft:0x0001.Generic_Desktop:Vno=54270 [0xd3fe]
The data is delivered in bits 1 to 7 from the left; the last 8 bits are always 0xfe. Looking at the data in lircd.conf, this corresponds pretty well. Clearly this was the down button:
begin codes
ok 0x5e
up 0x51
down 0x53
left 0x5B
right 0x5F
...
What about the kernel API? It's described in uhid(4) for FreeBSD. Linux doesn't seem to have kernel man pages; instead, the interfaces are described in the directory /usr/src/linux/Documentation, in this case in /usr/src/linux/Documentation/usb/hiddev.txt. The interface is very different and I spent some time looking at the LIRC code in daemon/hw_hiddev.c, where I found obscenities like:
rd = read(hw.fd, &event, sizeof event);
if (rd != sizeof event) {
logprintf(LOG_ERR, "error reading '%s'", hw.device);
return 0;
}
Looking at the interface API, this probably does represent an error, but where's the analysis? Is the value returned greater than, equal to or less than 0? Where's errno when you need it?
In addition, this code seems to pass parameters via global variables:
pre_code = event.hid;
main_code = event.value;
/*
* This stuff is probably dvico specific.
* I don't have any other hid devices to test...
*/
if (event.hid == 0x10046) {
repeat_flag = (main_code & dvico_repeat_mask);
main_code = (main_code & ~dvico_repeat_mask);
return decode_all(remotes);
}
Round about here, I got sick of even looking. lirc has proven to be a real pain at the best of times. Do I ignore the problem, fix it or write a different interface? Spent some time thinking about that and came to the conclusion that I had to live with the problem, at least in the short term, but boy, is that painful! This code also showed something that could be a problem: Linux refers a struct hiddev_event with the members hid and value. value is clearly the value displayed by usbhidctl, but I don't see anything corresponding to the hid value of 0x10046. Where does that come from?
After visiting Chris, we're wondering whether we shouldn't be considering moving house. There's a lot of value tied up in this house, and we don't really need this big a property. Chris paid only a fraction of the price for her land, and we could build a comfortable house on land like that for about a quarter of what this house could bring. Had a couple of estate agents in to evaluate it; they were so enthusiastic that I wonder why we're even considering moving out.
| Thursday, 23 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on remote controls today, and made reasonable progress. The more I look at lirc, the less I like it. Starting the daemon, got the message
lircd 0.7.2: could not assign address to socket lircd 0.7.2: No such file or directory
Why? Went through the code and checked: it seems that the directory for the socket didn't exist. How much easier it is with this patch:
if(bind(sockfd,(struct sockaddr *)&serv_addr,sizeof(serv_addr))==-1)
{
- fprintf(stderr,"%s: could not assign address to socket\n",
- progname);
- perror(progname);
+ fprintf(stderr,
+ "%s: could not assign address to socket %s: %s (%d)\n",
+ progname,
+ lircdfile,
+ strerror (errno),
+ errno );
goto start_server_failed1;
Now we get:
lircd 0.7.2: could not assign address to socket /var/lirc/lircd: No such file or directory (2)
Is that really so much work? How many people have scratched their heads about this one?
lircd 0.7.2: accepted new client on /var/lirc/lircd lircd 0.7.2: initializing '/dev/uhid' lircd 0.7.2: unable to open '/dev/uhid' lircd 0.7.2: caught signal Terminated: 15
Huh? Why can't it open /dev/uhid? Why did it “catch a signal”? With some patches:
if ((hw.fd = open(hw.device, O_RDONLY)) < 0) {
- logprintf(LOG_ERR, "unable to open '%s'", hw.device);
+ logprintf(LOG_ERR,
+ "unable to open '%s': %s (%d)",
+ hw.device,
+ strerror (errno),
+ errno );
it became blindingly obvious:
lircd 0.7.2: unable to open '/dev/uhid': No such file or directory (2)
Why couldn't that be put in as well?
Presumably the “caught a signal” is lircd's own way of stopping (or committing suicide). I didn't bother to fix that one.
In the process of testing this code, discovered another problem, not related to the software: the DVICO remote control suffers from premature repetition. It's almost impossible to press a button without repeating, and presumably it would blow the mind of the designer of my brain-dead Motorola L6 mobile phone: during the time you have to hold down the “off” button to turn on the phone, the remote control repeats 27 times. This isn't a FreeBSD-related problem, nor an isolated case: it happens on both of the controls I have, and on both FreeBSD and Linux. Ended up writing code to ignore the first two repeats, which still makes it very responsive.
Next was to actually use the functionality with mplayer. That required going back to the inaccurate, incorrect, incomplete and contradictory LIRC documentation. It seems I needed a .lircrc file. Format? Who knows? I found multiple examples, but no documentation. One of the examples was the DVICO/LIRC HOWTO, which included a file which I copied as discussed. No reaction. Why? Well, an obvious reason is that the button names mentioned in that file don't correspond to the button names in the /etc/lircd.conf file. The format appears to be straightforward, but who knows what gremlins lurk? Spent some time looking at that. The format of the file appears to be (caution: once again this is an example, not the (missing) documentation):
begin
button = Right
prog = mplayer
config = pt_step 1
repeat = 0
end
Here the names on the right of the = sign are clearly strings. Right is presumably intended to the name of the “right” button (called right in my lircd.conf), mplayer the name of the program, pt_step 1 an entry in the ~/.mplayer/input.conf file, and the parameter to repeat might mean that further repeats of this button should be ignored (though in this case that seems a bad choice).
This clearly gives me the option of controlling multiple programs from the same remote control, a very useful function. But it also seems to imply that specific buttons relate to specific programs, which is far less useful. The top of the control has four buttons marked “DTV”, “MP3”, “DVD” and “CPF” (whatever that may mean). Clearly the intention is to divert the functionality of the other buttons to one of four programs. How do you do that? I don't know yet.
| Friday, 24 November 2006 | Echunga | Images for 24 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Over to Hahndorf for a project meeting this morning; our concerns of a couple of weeks ago look unfounded, and suddenly it's “all systems go” again. Spent some time after the meeting looking at some issues we have; our prototype machine is still running FreeBSD 5.4, and we have some ACPI issues that no longer exist under 6.1.
In the afternoon, back to the remote control stuff, and found yesterday's assumptions confirmed, including the concerns: mplayer reacts to the remote control even when it's iconified, so if you have multiple mplayers running (something I do frequently), presumably all will react to the remote controls. I need to look at doing something there. Also had permission problems with lirc. By default, the socket is writable by root only:
=== grog@teevee (/dev/ttyp0) ~ 4 -> ls -l /var/lirc/
total 0
srw-r--r-- 1 root wheel 0 Nov 24 17:10 lircd
prw-r--r-- 1 root wheel 0 Aug 23 09:16 lircm
It's not clear why mplayer needs to open this file with write permissions, but it stops it from working. I also don't know wat /var/lirc/lircm is. Clearly it's been there for a while, but I didn't mention any work on lirc on 23 August.
| Saturday, 25 November 2006 | Echunga | Images for 25 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
We're still thinking about moving house—but where to? Previously Yvonne has always wanted to be near a forest so that we could go riding there, preferably without having to transport the horses. That was at least partially because in those days we had trouble loading horses into floats, a problem that's long in the past. And we find that, although part of Kuitpo forest is just down the road from us, we prefer to transport the horses so that we don't always have to ride in the same place.
So: where would be nice to live? It doesn't have to be as close to Adelaide as we are here, but it would be nice not to be too far away, and of course it has to be less than 5 km cable line from a telephone exchange. Today drove around the Fleurieu peninsula, down a back road past Kuitpo Colony to Mount Compass, Victor Harbour and back via Yankalilla and Myponga. Nice landscape, but nothing obviously desirable.
In the afternoon into Mount Barker to look at some display homes. Prices are quite reasonable, but there's a lead time of over 12 months between signing a building contract and moving in. That makes it much less attractive, and the salesman's “you can live in a shed for the year” doesn't exactly fill me with enthusiasm.
| Sunday, 26 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on mplayer today, still trying to get the on-screen display showing correct values. This time I was concentrating on getting the total time correct; frequently it would show values less than half the correct value. I had suspected some kind of overflow, but after tracing through some particularly emetic code, found that the input stream was either supplying incorrect bit rate data, or was being interpreted incorrectly. After that, found that it also gets reported accordingly on mplayer startup. The values seem to have no relationship to the real information; do they come from the stream, or is mplayer misinterpreting them? Here's what I get for the Adelaide TV channels:
ABC HDTV: VIDEO: MPEG2 1280x720 (aspect 3) 50.000 fps 9600.0 kbps (1200.0 kbyte/s) ABC2: VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) ABC TV: VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) 7 Digital: VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) 7 HD Digital: VIDEO: MPEG2 720x576 (aspect 3) 50.000 fps 9500.0 kbps (1187.5 kbyte/s) NINE Digital: VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 15000.0 kbps (1875.0 kbyte/s) NINE HD: VIDEO: MPEG2 1440x1088 (aspect 3) 25.000 fps 15200.0 kbps (1900.0 kbyte/s) TEN Digital: VIDEO: MPEG2 704x576 (aspect 3) 25.000 fps 12000.0 kbps (1500.0 kbyte/s) TEN HD: VIDEO: MPEG2 1440x1088 (aspect 3) 25.000 fps 12800.0 kbps (1600.0 kbyte/s) SBS HD: VIDEO: MPEG2 720x576 (aspect 3) 50.000 fps 7650.0 kbps (956.2 kbyte/s) SBS DIGITAL 1: VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 5000.0 kbps (625.0 kbyte/s) SBS DIGITAL 2: VIDEO: MPEG2 720x576 (aspect 3) 25.000 fps 4500.0 kbps (562.5 kbyte/s)
There seems to be no relationship between the bit rate and the resolution, and in addition some “HD” streams are nothing of the sort. In many cases, the HDTV streams have a slower specified bit rate than the normal resolution. Seven HDTV is a special case: it seems to be very weak, and frequently enough I get nothing at all.
What does this mean for mplayer? Clearly it can't always relate on the specified or calculated bit rate. I think the best choice would be to look at the file size and calculate from there. That would also help where the timer wraps around in the middle.
Also did some work on our project; in this case, mplayer is reading from a pipe, and we somehow need to find a way to get it to flush the pipe when it starts so that it's showing current data and not the data that had collected in the pipe. That's straightforward enough: a keyboard input would do it, but in our case it looks like we'll send the command down another pipe:
=== grog@ceeveear (/dev/pts/2) ~ 121 -> mkfifo /var/tmp/mplayer-command=== grog@ceeveear (/dev/pts/3) ~ 36 -> mplayer /dev/dvb/adapter0/dvr0 -really-quiet -framedrop -input file=/var/tmp/mplayer-command=== grog@ceeveear (/dev/pts/2) ~ 122 -> echo "seek 10" > /var/tmp/mplayer-command
This example was done on Linux, but it works exactly the same way under FreeBSD. Note the two terminals: mplayer writes to the terminal.
| Monday, 27 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
The work we're doing on the black box prototype is more smoothing rough edges than genuine development work; the latter is a separate branch. But it still means making changes to the software, and we don't have any version control. I didn't realize how much that concerned me until I woke up in the middle of the night worrying about it.
First thing in the morning I put it into CVS, the first time I've done this from scratch. The CVS documentation doesn't make it easy: the canonical command is cvs import, but as the name suggests, that assumes that it's an import from another tree, and it insists on giving it a side branch. I couldn't find anything at all to tell me how to create revision 1.1, the first revision in the trunk. Finally found a way, though I still don't know if it's the best: import an empty directory as a new module, then add the source files and cvs add them to the repository. I'm amazed how often even simple things are difficult to find.
The work itself was relatively simple, apart from understanding why some problems were occurring. That was sorted out by the evening, and tomorrow we'll test.
More work on mplayer status lines. Calculating the bit rate isn't nearly as easy as I expected it to be.
Avaya has recently published and distributed for free two books called “VoIP Security for Dummies” and “VoIP for Dummies”, in that order. The idea sounds very good, and even the fact that they have only 64 pages doesn't necessarily detract from them. I had both sent to me, and started reading the first, not a thing that really concerns me. On Friday the second one arrived, and today I tried to read it.
In the past I've complained about poor books on VoIP, both published O'Reilly. The main thing wrong with the first, “Practical VoIP using VOCAL” is that VOCAL was obsolete by the time I got the book. I commented negatively earlier this year on the next one, Asterisk: The future of telephony.
The “Dummies” book is different: it makes the others look good. It's obviously intended as a sales vehicle, but after wading through half the book trying to find some content which was neither uselessly fuzzy nor incorrect, I gave up, still not really understanding what Avaya was trying to sell. A pity: the idea is good, and getting people up to speed understanding VoIP would presumably help them sell things (though, since I don't know what they're selling, I'm not sure). Here a couple of samples:
Page 9:
The VoIP protocols, or simply IP, as many have begun to call it for short, are interoperable.
Page 10:
The IP telephone has a network interface card (NIC) built into it ... The NIC ... provides the device with its physical address on the LAN.To support IP telephony, a server with a MAC address is typically dedicated to load the IPT software that is used to manage all the controls.
At no point in the above text does he mention IP addresses. They come later. But first:
One or more devices known as switches are installed around to form the core infrastructure of the IP Telephone LAN.If you plan to run IP Telephony with your computer data on the same LAN, make sure that you use IPT compatible switches. As with any addressable device on the LAN, the switches used must also be MAC-addressable.
This is, of course, nonsense. I am running two Sipura SPA3000s connected via a 10 Mb/s hub (they're 10 Mb/s only devices) with no server software (because the Asterisk book wasn't good enough to enable me to configure it properly). What the author is probably trying to say (and my guess it's his poor understanding of what somebody else told him) is that QoS is important, and switches should understand it. But that's just a guess. A fact is that up to this point (bottom of page 11) there has been no mention of IP addresses. They come in the middle of page 13:
Unlike the MAC addressing on the LAN side, VoIP traffic on the WAN side uses the IP addressing scheme.
When the packets arrive at the destination LAN, the edge device breaks down the VoIP packets and forwards them to the server that manages the IP Telephony services on the LAN. From this point, the rest of the process is similar to IP Telephony services.
Huh? This is supposed to be an IP Telephony service.
So maybe the intention of the book is to sell Avaya's services, not explain IP telephony in detail. But this level of inaccuracy leaves me wondering if anybody at Avaya knows what they're talking about. What should have been a good advertisement for them proves to be a complete fiasco. They should change the title to “VoIP by dummies”.
| Tuesday, 28 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on the black box prototype today. I had not realized how much progress we have made in the last few months. This machine is at the status of early July, and I ran into all sorts of unexpected problems when making only minor changes.
How do you get mplayer to catch up with an input stream? You can create a command pipe with input file=/pipename, but if you send a seek beyond the end of the current input stream, it hangs for a while and then crashes. In our prototype, that then brings down the entire application. Spent some time trying various options, but didn't find a solution.
| Wednesday, 29 November 2006 | Echunga | |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
More work on the prototype today, and managed to fix most of the problems that we ran into today. I still don't understand why I can't run it under the debugger: it reads from the parallel port, and for some reason the program gets a SIGBUS on the read instruction (in (%dx),%al). Is this a debugger bug?
Another estate agent came around today with a valuation. Not nearly as good as we had hoped; looks like we'll be staying here after all, unless another one comes round with a silver bullet.
Fluffy has been staying away from home for a couple of days now. That's normal enough in this hot weather, but today she returned in a very sick state; we first thought she had been bitten by a snake. Yvonne took her to the vets, where Ashley found fluid in the lungs and an elevated temperature, and put her on a drip. He's not really sure what it is, but suspects an allergy. First time I've heard of serious allergic reactions in cats.
| Thursday, 30 November 2006 | Echunga | Images for 30 November 2006 |
| Top of page | ||
| previous day | ||
| next day | ||
| last day |
Phone call from Ashley first thing this morning. Fluffy died last night only a couple of hours after being admitted. Sadness.
By morning, the dam water tank had refilled, so a lot of water had passed through the water filter. It had also collected a lot of junk, much of it living organisms that I can't categorize:
|
|
||||||||
|
|
||||||||
|
|
||||||||
|
|
||||||||
There's a couple of ones in the last photo that look like a pair of eyes with nothing else. For scale: the red ribs of the filter are about 0.9 mm thick.
Spent the morning investigating the PVR250 port; there's a lot of work needed there.
Didn't finish that before I had to go the Annual General Meeting of the ICT Council for South Australia, during which we elected a new Board of Management. Neither David Raffen, the incumbent chairman, nor Adrian de Brenni, one of the vice-chairs, contested the election, and we had fewer candidates than positions available. The new chairman is Dean Littlefield, who has only been on the board a few months. Clearly changes are on the way.
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 |
