<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>

<channel>
	<title>Tom Gidden</title>
	<atom:link href="http://gidden.net/tom/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<pubDate>Thu, 10 Jul 2008 13:01:17 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
	<language>en</language>
			<item>
		<title>Leaving Three after a year-and-a-half for iPhone 3G</title>
		<link>http://gidden.net/tom/2008/07/10/leaving-three-after-a-year-and-a-half-for-iphone-3g/</link>
		<comments>http://gidden.net/tom/2008/07/10/leaving-three-after-a-year-and-a-half-for-iphone-3g/#comments</comments>
		<pubDate>Thu, 10 Jul 2008 13:01:17 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[apple]]></category>

		<category><![CDATA[iphone]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[O2]]></category>

		<category><![CDATA[orange]]></category>

		<category><![CDATA[pac]]></category>

		<category><![CDATA[phones]]></category>

		<category><![CDATA[three]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=54</guid>
		<description><![CDATA[Back in December 2006, I wrote a post about cancelling my decade-old Orange UK phone contract, in favour of Three.  Now I'm off again.  I finally gave into the lure of iPhone.  As a Mac (power?) user for eight years, and owner (and destroyer) of many of their products, the absence of iPhone in my life is fairly conspicuous.  I always swore that I wouldn't buy the iPhone 2G, though.

On the other hand, I swore I wouldn't buy any iPhone while it was still tied to O2.  I don't like the fact that Apple don't offer an unlocked iPhone, but it looks like it's going to stay that way for the foreseeable future.  I guess my ideal vision would be an Apple MVNO, although I bet tariffs would be sky-high for that, but the paper the bills were printed on would be very crisp (and probably laser-etched aluminium sheets)
The iPhone 3G launch has coincided with the end of the half-price tariff offer I had at Three:  it was basically £15/month for 18 months for 300 minutes of calls.  A month or two ago, it upped to £30, and I had to decide whether to renew or to take the opportunity to switch to iPhone.
My reason for leaving Orange was mainly the fact that I wasn't feeling the love anymore, and I felt my tariff was far too high.  I'm a fairly light mobile user, and sometimes I think I might be better of with a PAYG.
My experience with Three has been fairly good.  Coverage hasn't been quite as good as Orange, but good enough for my purposes.  I've had a couple of dropped calls, and the battery life has been terrible.  I'm fairly sure this is due to the fact that Three is 3G only, and the Nokia 6280 I had really wasn't too good at 3G power consumption.  At least with Orange, I kept it switched to 2G most of the time.
I've never liked the look of O2, and the mess they've made of this launch doesn't fill me with confidence.  The starting tariff for iPhone is double the price that I could otherwise get on Three for a lot more minutes, and I'm not really a fan of smartphones anyway.  I think I might be able to have some fun coding that thing, though.  I've got a history of writing games for web and Palm, and some experience with writing for OS X, I'd be dumb not to have a go with the iPhone.
So, I think my new tariff is going to be the iPhone £30/month one.  It's a reduction to 75 minutes a month, although looking at my past few Three bills, I've only been hitting about 50 minutes a month maximum, so there shouldn't be a problem.  I'm not sure how much I'll use data, but when it comes down to it, £15 extra for 18 months is actually only £300, which I should be able to make back with iPhone-related work.
Decision made.  Unfortunately, getting an iPhone 3G seems not as easy as everyone hoped.  In particular, I have a client who's spitting nails that he's unlikely to get an upgrade to his launch-day iPhone 2G tomorrow morning.  O2 and Apple have monged this launch up pretty badly.  I mean, anyone with any sense will see that the second-most-anticipated mobile phone launch ever (after the iPhone 2G, that is) would be popular.  Secondly, a simultaneous launch in 24 countries?  Free upgrades for existing users?  How could this not end up a fiasco?
I can understand if they can't actually make the damn things quick enough.  However, why no proper pre-order system?  My MacBook Pro took almost a month to arrive after I ordered it, and while I watched the package tracking widget like a hawk for that whole month, at least I knew it was on its way.  O2, on the other hand, say "whilst we are confident that all customers who want iPhone 3G will get one by the end of this summer, initial supply is limited and will be for some weeks.", and then expect you to just check back every so often to see if they've got their shit together yet.
My client spent a lot of this morning on the phone to O2 and Apple Retail.  They're giving conflicting answers on upgrades, with Apple Regent Street almost denying anything's happening tomorrow, while Apple Bluewater are quite happy to talk.  O2 don't seem to have a clue when anyone's going to get a phone.  Meanwhile, I'm not going to trek 10 miles into Bristol at 8.02am just to be told that they don't have any.
So, off to the Carphone Warehouse's website, hoping that they actually might have their act sorted better than O2 and Apple.  Looks like they have them in stock for delivery tomorrow morning.  Fine.
Back to Three for the PAC code, then.  Dial 333 for customer services.  I talked for 20 minutes to a nice chap in India, who called me Mister Jidden, and tried to convince me that the Nokia N95 8-gee-bee is a better phone than the iPhone.  It has a five-gee-pixel camera compared to the iPhone's two-gee-pixel camera, and it comes with a FREE two-five-six-emm-bee memory card!  (I think he's reading from a script here)
Anyway, apparently, the lack of a replaceable battery is the main reason I shouldn't buy an iPhone, according to them.
I explained that I specifically need an iPhone to write software for, and Symbian on the N95 just doesn't cut it.  Would I like to keep the Three contract as a "spare"?   No.   They could offer me a new tariff for £15/month, and it's special!  300 minutes a month, and free voicemail!  ...but that's the same as my current tariff was up until they doubled the price a month ago.
Thanks, but no thanks.  I need an iPhone.
"Well, Mister Jidden, no problem.  You're one of our most special "elite customers", and I can give you an extra offer:  I can reduce that tariff to £12!"
It's not an iPhone though.
How about if someone else in my family wants to take the same offer?  My parents spend about £1.50 on their phones each month, thanks to the Orange Value Promise price-matching Virgin Mobile years ago, so No.
I couldn't really stop the guy... he was on a roll with his script, and I didn't mind letting him go through it.  I needed the PAC number, and the guy was nicer and making more of an effort than Orange did back in 2006.
Got the code by SMS a couple of minutes afterwards, and plugged it into the Carphone Warehouse website.  A short credit check later, and I get a text saying it'll be delivered on my delivery date... tomorrow, presumably.
Oh well.  In conclusion, Three's okay.  I'd actually go as far as to recommend them to others. They're certainly cheaper than Orange and from what I can tell, the other networks too.  I'd be happy to stay with them, especially since my piddlingly small tariff seems to qualify me as "elite", but they don't do iPhones, unfortunately.
I just figured out why I might be "elite", other than spending most of my pre-teen years playing 3D space games on the BBC Micro... I did a couple of "Refer a Friend"s to Three, earning £30 (two months' tariff!) each time.  Either that, or everyone's elite if they're buying an iPhone.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2008/07/10/leaving-three-after-a-year-and-a-half-for-iphone-3g/feed/</wfw:commentRss>
		</item>
		<item>
		<title>MySQL and PDO on OS X Leopard, Intel</title>
		<link>http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/</link>
		<comments>http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/#comments</comments>
		<pubDate>Mon, 30 Jun 2008 14:35:05 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[Techie]]></category>

		<category><![CDATA[apache]]></category>

		<category><![CDATA[dbd::mysql]]></category>

		<category><![CDATA[dbi]]></category>

		<category><![CDATA[leopard]]></category>

		<category><![CDATA[Mac-OS-X]]></category>

		<category><![CDATA[OS-X]]></category>

		<category><![CDATA[pdo]]></category>

		<category><![CDATA[pdo_mysql]]></category>

		<category><![CDATA[perl]]></category>

		<category><![CDATA[php]]></category>

		<category><![CDATA[universal]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=53</guid>
		<description><![CDATA[I don't know if I'm missing something big, but getting Perl, Apache, PHP, PDO and MySQL to play nice on my Mac OS X 10.5 install on my Intel Core 2 Duo (Penryn) MacBook Pro hasn't been easy.  This is partly thanks to Apache being compiled with x86_64 support, and Perl with i386 only.

Anyway, Googling about, I notice that others have tried this arrangement with varying degrees of success.  The easy answer is to install something like MAMP or replace the Apache and PHP installation with a custom build.
However, I prefer to keep my installation as stock as possible, and I'm not a huge fan of proprietary packaging systems like MacPorts and Fink.  Don't get me wrong: those systems do what they're meant to do, and as a long-time FreeBSD user, I appreciate the approach.  However, they don't fit into the Mac mindset too well, plus I'm too lazy to keep them up-to-date.
In other words, I want Apple to do it all for me, via Software Update where possible.  The aim is to keep the stock Apache, PHP and Perl in place, and just add stuff.
The 10.5.3 Apache install does include PDO, but it's fairly crippled: the only drivers are the SQLite ones, even though standard "mysql" support is included.  So, "pdo_mysql" will need to be installed... no problem: just install it as a module.  But which architecture?
Since 10.5.3 Apache is compiled for i386 and x86_64, it'll run by default as 64-bit, requiring the 64-bit MySQL client libraries.
However, the included 10.5.3 Perl build is compiled only for i386, so if you want to build DBD::mysql for Perl as well, you'll need 32-bit MySQL client libraries.
The MySQL 5.1 official Leopard binary isn't currently a universal build, so right now if you download a binary distribution, you have to pick either 32-bit i386, or 64-bit x86_64.  This will knacker either PHP/PDO (64-bit) or Perl/DBI (32-bit)  So, assuming we don't want to replace -- or otherwise mess with -- the stock Apache, Perl and PHP, recompiling MySQL seems the way to go: we need to build a fat MySQL with both architectures.
To do this, download the MySQL source (I'm using 5.1.25), unzip and compile with something like:

MACOSX_DEPLOYMENT_TARGET=10.5 \
CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
./configure \
'--disable-dependency-tracking' \
'--prefix=/usr/local/mysql' \
'--localstatedir=/usr/local/mysql/data' \
'--libexecdir=/usr/local/mysql/bin' \
'--with-comment=MySQL Community Server (GPL)' \
'--enable-thread-safe-client' \
'--enable-local-infile' \
'--with-big-tables'

make

sudo make install

You'll then probably want to do something like:

sudo -s

cd /usr/local

export MYSQL_VERSION=mysql-`mysql/bin/mysql_config --version`-osx10.5-universal

mv mysql $MYSQL_VERSION

ln -s $MYSQL_VERSION mysql

chown -R _mysql:staff $MYSQL_VERSION

cd mysql

ln -s share/mysql support-files

ln -s var data

bin/mysql_install_db --user=_mysql

I'm not sure whether this is the right procedure, but it works for me.  A lot of this will change depending on your requirements and circumstances, so don't blame me if it kills your pets.
Next up is to install the PDO_mysql module.  This is easy. Firstly, download the PHP source.  As of Mac OS X 10.5.3, the current PHP is 5.2.5, but I downloaded 5.2.6 and it seemed fine.  Unzip it, and go into the distribution directory (ie. php-5.2.6)
Then:

cd ext/pdo_mysql

phpize

MACOSX_DEPLOYMENT_TARGET=10.5 \
CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
./configure --prefix=/usr --with-pdo-mysql=/usr/local/mysql

make

sudo make install

You might need to add the following line to /etc/php.ini (creating that file, if necessary):

extension=pdo_mysql.so

Then, restart Apache and you should have a working PDO_mysql driver.
Installing DBD::mysql for the stock Perl is a different matter.  If you just do a CPAN install, then the multiple -arch tags that the mysql_config from your new Universal build of MySQL will return are going to foul it up.  So instead, you can just build DBD::mysql for i386, as Perl is going to be running in 32-bit mode anyway.
There are probably better, easier ways of doing this, but I resorted to just doing a manual DBD::mysql build, stating the flags by hand:

perl Makefile.PL \
 --cflags="-I/usr/local/mysql/include/mysql -Os -arch i386 -fno-common" \
 --libs="-L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lm"

make

sudo make install
]]></description>
		<wfw:commentRss>http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Inverted Index Searching as Stored Procedures</title>
		<link>http://gidden.net/tom/2008/06/17/inverted-index-searching-as-stored-procedures/</link>
		<comments>http://gidden.net/tom/2008/06/17/inverted-index-searching-as-stored-procedures/#comments</comments>
		<pubDate>Tue, 17 Jun 2008 09:38:20 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Programming]]></category>

		<category><![CDATA[Techie]]></category>

		<category><![CDATA[fulltext]]></category>

		<category><![CDATA[Google Code]]></category>

		<category><![CDATA[indexing]]></category>

		<category><![CDATA[inverted-index]]></category>

		<category><![CDATA[mysql]]></category>

		<category><![CDATA[search-engine]]></category>

		<category><![CDATA[searching]]></category>

		<category><![CDATA[stored procedures]]></category>

		<category><![CDATA[triggers]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=52</guid>
		<description><![CDATA[An old colleague of mine has persuaded me to release an implementation of an "inverted index"-based search library, written solely as MySQL Stored Procedures.  Our combined work is now available on Google Code.

It's been a long time since my last post... I've been spending most of my time recovering (still!) and working on a new game project for some old friends.  On the way, I've learned ActionScript 3, Flash, Papervision3D, Box2DFlash, and a whole slew of other fun stuff.  As soon as the project sees the light of day, I'll be announcing it here.
I've also done a bit of consultancy work on the way which catalysed the stored procedure work I'm releasing here.  As I mentioned in a previous post, I had an article published in php&#124;architect Magazine in which I presented some simple code to do database searches in PHP.
The basic concept of this method is to index content in a database table by separating it into words and storing the locations of those words in a separate table.  This is about the most basic form of search engine, other than the "wildcard search" that many database developers seem to use, unfortunately.  Wildcard searches are incredibly inefficient and unscalable.  The other alternative is the MySQL (and MyISAM) specific FULLTEXT approach, which I've never been particularly happy with.
The Inverted Index technique is nothing new, and certainly not rocket science.  However, I find that many (esp. younger) programmers haven't heard of this method, and rely on external libraries, specific hacks (such as FULLTEXT), or usually the dreaded "string LIKE '%foo%'" construction which can stop a MySQL server in its tracks.
It's no substitute for a proper search engine library, such as Apache Lucene, but it does have the benefit of being easily integrated into other queries.  The problem of searching documents is one thing, but sometimes you just need to search an address field, biography field, or something like that, while still searching on other columns as well.  While some external libraries will allow integration with MySQL through UDFs, that adds a whole extra maintenance load and is also not usually possible on shared database servers.
The approach is fairly easy to implement in an application language such as Perl or PHP.  I've been doing it for years.  However, it's still involved quite a lot of setup and maintenance.
Instead, I've written an implementation that does everything within the database itself using triggers and stored procedures.
This allows the programmer to treat the data table as a simple table, and then call a single stored procedure to perform a search.  More complicated queries can be constructed using the same data, but still keeping the same triggers in place to do the dirty work.
While this approach might not be the most efficient way of doing things, I think it's the most self-contained and simplest to use.  It should work on all MySQL storage engines, and I imagine it could be adapted to run on other RDBMSes altogether.
Anyway, I mentioned the code I'd written to my old colleague, Stig Palmquist, and he felt that it was valuable work that could do with being released as an open-source project.  Moreover, he was eager to contribute to the effort. So, it wasn't long before we started a Google Code project, and we've both significantly improved the code since.  It's open-sourced under the Apache License 2.0.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2008/06/17/inverted-index-searching-as-stored-procedures/feed/</wfw:commentRss>
		</item>
		<item>
		<title>EyeTV 3</title>
		<link>http://gidden.net/tom/2008/01/16/eyetv-3/</link>
		<comments>http://gidden.net/tom/2008/01/16/eyetv-3/#comments</comments>
		<pubDate>Tue, 15 Jan 2008 23:51:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[apple]]></category>

		<category><![CDATA[Elgato]]></category>

		<category><![CDATA[Elgato-EyeTV]]></category>

		<category><![CDATA[EyeTV]]></category>

		<category><![CDATA[EyeTV-3]]></category>

		<category><![CDATA[mac]]></category>

		<category><![CDATA[OS-X]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2008/01/16/eyetv-3/</guid>
		<description><![CDATA[I've been a dedicated user of EyeTV for almost two years, to the point that I no longer watch TV on the big screen in the living room.  Instead, I watch almost exclusively on my iBook.  Back in May 2006, I wrote a post about EyeTV 2.2 and its shortcomings.  Today, Elgato have released EyeTV 3.

I haven't posted on my blog for a few months now, as my spare time has been tied up on a super-secret project involving Flash (well, Flex), Papervision3D, Box2D and what for me is some really heavy duty math.  However, after what I found to be a particularly disappointing MWSF 2008 keynote, I noticed EyeTV 3 appear, and I must say, it's worth a mention.  Slamming down &#163;30 was a no-brainer... far more palatable than the &#163;60 they charged for the EyeTV 1 to 2 upgrade.
I also noticed while writing this review that Elgato's 404 page gives out a 10% discount code... Nifty.  Only wish I'd found it a couple of hours ago.
In short, there are things I still don't like about EyeTV, and things I haven't really tried yet.  On the other hand, there are a few features in V.3 that make up for all of that.  In fact, a good chunk of the wishlist in my previous post is now done:

"Smart Playlists" and "Smart Recording Schedules".  I can now set up automated record lists based on complex criteria.
A smarter search engine.  Done.  They've got a full set of criteria there, with an all/any system.
Tuner and recording sharing over Bonjour.  Shared Libraries appear on the sidebar, and the system seems to work well.  I can easily watch recordings on my Mac Mini from my Laptop with little or no delay.  It even works when EyeTV.app isn't running on the serving machine, thanks to a background daemon.  Of course, it'd be far nicer if both machines' tuners could be fully and automatically scheduled and controlled from a single interface, but hey, you can't have everything.

While they've given EyeTV a patchy makeover and added some other minor features, these three alone justify the upgrade for me.
Unfortunately, the other features on my wishlist don't seem to be there yet.  PDC, in particular, would be nice.  Apparently, the Freeview Playback standard supports something similar to PDC, but I see no evidence of it in EyeTV.  This really would have come in handy a couple of days ago, as the popular and eagerly-awaited new Louis Theroux documentary started 15 minutes late thanks to a bunch of fat "sportsmen" throwing darts about.
The other one I'd still really like is a "close" button on the pop-up controller.  It's still far too enthusiastic, popping up at the slightest provocation, and assuming any accidental keypress is a request to change channel randomly.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2008/01/16/eyetv-3/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Replacing the backlight on an iBook G4</title>
		<link>http://gidden.net/tom/2007/10/02/ibook-ccfl-replacement/</link>
		<comments>http://gidden.net/tom/2007/10/02/ibook-ccfl-replacement/#comments</comments>
		<pubDate>Tue, 02 Oct 2007 11:12:44 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Techie]]></category>

		<category><![CDATA[apple]]></category>

		<category><![CDATA[backlight]]></category>

		<category><![CDATA[ccfl]]></category>

		<category><![CDATA[fix]]></category>

		<category><![CDATA[hardware]]></category>

		<category><![CDATA[ibook]]></category>

		<category><![CDATA[laptop]]></category>

		<category><![CDATA[lcd]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/10/02/ibook-ccfl-replacement/</guid>
		<description><![CDATA[For a while I've been noticing significant degradation of the backlight on my dilapidated iBook G4.  So, yesterday, my dad and I spent a few hours replacing the CCFL backlight bulb.

I've had the iBook for over three years now, and over the past couple of years it's been in use pretty much all day every day.  It's my only computer now, other than the little headless Linkstation in the cupboard.  It's been my trusty steed, but it just wasn't built for this kind of workload.
I've also taken it apart more than a few times.  The hard drive has been replaced at least four times -- I've lost count -- and it's even had the motherboard and screen transferred into a new case when the old one wore out.  It's also been back to Apple to fix what seemed to be a broken or loose display signal cable.
Anyway, the main symptom has been a gradual dimming and "colour warming" of the screen, along with a patchy backlight at times.  When I say colour warming, I mean that the entire screen has been getting more red and yellow, with a poor quality white.  In addition, the bottom left quarter of the screen seemed to be distinctly darker than the rest, especially when the screen came out of "reduced brightness", ie. the dimming that occurs halfway before "display sleep".  In fact, I couldn't let the screen dim or sleep without it being much darker on wake up for a while.
I was managing to correct the colour warming issue by tweaking the display colour calibration, but it was getting harder and harder to keep a wide enough gamut for graphics work.
So, after some research, I partially disassembled the iBook's screen case to find out the LCD model.
If you've never taken apart an iBook before, let me tell you: it's really not fun.  It's difficult to do without scratching or damaging the case... even with correct use of the "black plastic stick" (informally known as a "spudger") that Apple insist is the correct tool for the job.  iBooks just aren't really user-serviceable.  For the most part, this isn't a problem, because the memory and AirPort card are accessible from under the keyboard.  However, I've usually had to replace the hard drive instead, which requires almost a complete stripdown of the machine.
NOTE: I must make it clear that the information below is offered purely as a suggestion, and should not be relied upon.  I was taking a risk with this disassembly, and it was largely trial-and-error.  If you use any of this information yourself, then it's up to you, but really don't blame me if you mess up.  It's quite possible I did it wrong, and also possible that you have a different model anyway.  I'm mainly writing this up because no-one else has, and I could have done with some hints myself!  Consider yourself warned.  Definitely Your Problem, not mine.
The case is tightly held together with snap tabs (if that's the correct name), and special sticky tape is liberally scattered pretty much everywhere inside.  All of this needs to be carefully peeled up and reused, if you don't have access to replacement tape like Apple.
Opening up the screen case, on the other hand, is far easier:  just unscrew the four visible hex screws and prize the white case off with your fingernails.  Even my weak-ass fingernails are good enough.  Be careful not to trap the signal cables, though.
From here it gets delicate.  I decided to take this process very slowly, and also asked my tech-savvy dad to sit in and second-guess me all the way, while supplying a second pair of hands.
Handy Hint #1:  When I first replaced the HDD in my old iBook, I forgot to protect the screen, and I also forgot to secure the hanging AirPort antenna plug.  As a result, when I'd put the machine back together I noticed a fairly deep scratch in the middle of the screen.  Very upsetting.  So, before going any further, tape some bubble wrap, cardboard or other protection to the screen surface.  Be sensible, though, and don't go using duct tape or something like that on the delicate surface.  Also, put something soft on the work surface: you'll be putting the LCD face down quite a bit.
On opening the screen, you'll see a lot of tape and stuff.  I carefully removed the obvious bits, along with the foil tape covering the display connector on the back of the LCD.  The aim is to totally remove the LCD unit from the case, so figure it out from there.
I then partially removed the LCD shield:  the thin metal case.  There were four small screws on the sides of the shield holding it in.  I removed the bottom screws and lifted the shield just enough to look at the back of the LCD unit itself.  From this I could see the make and model of LCD:  Chi Mei N141XB-L03 Rev. C1.
From what I could find out, this make/model is meant to be quite easy to disassemble... I'd hate to see what a difficult make/model would be like.
I ordered the correct replacement lamp from Sparesweb for £22.79 all inclusive, and it arrived the next day.
The bulb itself is incredibly fragile.  It's very light and made of very thin glass.  I've seen other web pages suggest buying more than one just in case, and I can see the logic.  However, I risked buying just one.
Next thing is to get to the fitted bulb.  This requires quite a lot of fiddly dismantlement, and there doesn't seem to be anything on the web saying exactly how to do this, at least for this make/model.  So, we approached it very slowly, carefully, thinking and discussing every movement, and picking the correct tool to use, and the best orientation for the screen.
The backlight sits in a channel at the bottom of the screen, and miraculously manages to evenly illuminate the entire screen from there.  I still have no idea how it manages to be so even.
The visible back of the unit is predominantly white plastic which I assume is the main diffuser.  When switched on, this plastic glows white:  it's the bit that you can see through the Apple window in the back case.  On this screen, there's an obvious thin green circuit board covering the top quarter of the back, covered by a stuck-down clear plastic sheet.  This sheet wraps around the top edge of the screen and is stuck down.
The bottom 2cm or so of the screen is a metal panel, held in by two crosspoint screws.  I guessed correctly that the backlight is under this panel.  However, the panel wraps around the bottom edge, and the main LCD metal frame then wraps over the top of this panel to hold it in.
After staring at this for quite a while, coupled with some reluctant experimentation, we decided that it wasn't possible to lift this panel without removing the main frame, and even if we could, the frame would still obscure the backlight.  So, I carefully slit the top edge of the plastic cover over the circuit board, and peeled up two copper foil tabs.  After doing this, the only thing (apparently) holding the frame in place is the little tabs.  These were easily opened as normal by levering with a small screwdriver.
This is where the stress level increases.  I became very aware of the delicate nature of the sheets of plastic and glass involved.  With the main structural device out of the picture, everything gets more worrying.
At this point, the two silicone caps holding the backlight ends were accessible.  The backlight has a pink and a black cable dangling a little plug at one end. The black cable is lightly stuck in place along the bottom edge.  It's also clear at this point that the metal panel I mentioned is, in fact, a channel or gutter, with a tall J shaped cross-section.  The bulb sits in the bottom of this channel, which then acts as the reflector.
In hindsight, I think we did the next bit wrong.  It looks like the channel's intended to stay fixed in place, and the bulb slid out from the side by unsoldering the wires in situ.  Unfortunately, we didn't figure that out.  Instead, we ended up carefully flexing it back and working with the bulb directly.
In our defence, without knowing any better, unsoldering and sliding such a delicate part without knowing how everything's set up inside is just too nerve-wracking.
The cables have very little slack:  especially the black cable.  They are soldered very close to the glass, and then run 180&#176; back on themselves along the tube.  The silicone caps are fairly complex in design, and it's vital to pay attention to their orientation.
We unsoldered the old bulb, and managed to remove it without breaking.  As expected, the bulb was slightly discoloured at one end.  Two tiny clear rubbery (silicone?) rings were threaded on the bulb at 1/3 and 2/3rds of the length, presumably to space the bulb from the reflector.  I carefully worked these down the length of the tube.
I then rolled them onto the new tube at roughly the right positions.  We trimmed the new tube's leads down to approximately 2mm, and carefully soldered the black wire on.  We quickly found that we hadn't angled the black wire back far enough, so the cap wouldn't fit.  After resoldering, it seemed to fit better.  Then, I carefully guided the tube into the channel, and then fitted the pink cable the same way.
After mental gymnastics, plus trial-and-error, we managed to fit the caps in the right way and then got the channel back in place on the screen.  It was a tight fit, and took a lot of patience to get it sitting correctly.
From there, it was just reversing the procedure.  Before finally fitting the shield, we switched on the iBook and tested the screen, fully expecting that we'd broken something permanently... it's just too delicate for it not to go wrong.  Surprisingly, all worked properly.
Once reassembled, we relaxed for a while.  In fact, we took a number of short breaks, just to stay focussed, as it's fairly nerve-wracking doing stuff this delicate and critical to your main (and only) machine.
Upon switch on, I was struck at (a) how bright, and (b) how blue the screen was.  I was worried for a while that there was a signal cable problem and the red signal was failing.  However, after booting, it was clear that all was well.
Initially, and for the first few hours, the bulb was definitely bluer than expected, but this calmed down after a while.  There was also an odd effect that the screen got redder as it was tilted away from the viewer.  This also went away.
Quite quickly, I figured out why the screen seemed so blue.  Firstly, it was because I was so used to a worn-out backlight with an orange cast. The real cause, however, was that I was still using the massively overcompensating ColorSync profile!  Once I selected a generic profile, everything looked a lot better.  Even so, I've chosen a lower colour temperature than I would usually, as the bulb is still quite blue.
After writing that last night, I revisited it just now, comparing it against my external LG Flatron L1730B.  Unfortunately, it doesn't compare that well.  The white is still far more cyan than I'd like, and I just can't get ColorSync to give me a nice, clean white.  It's still better than it was, though.
I seem to remember reading that these CCFL bulbs can sometimes take a few weeks or months to properly settle down, so we'll see.
Conclusion
I must say, replacing this backlight was a real bitch, mainly due to lack of instructions, coupled with the delicacy of the task at hand.  In hindsight, I'd probably just get an entire new LCD panel next time.  It's nice to know that I can replace the bulb myself if necessary, though.  Much more complicated than it should be, but not totally impossible.  Thing is, this is officially not a user-serviceable part, but it wears out over time, and is also likely to wear out well after AppleCare expires.  A bit of a crappy deal if you ask me.
If all goes well, this iBook's going to be retired soon, but I don't want to get another laptop with a CCFL backlight now that LED-based ones are available.  However, the 17" MacBook Pro I want still uses CCFL, so I'm stuck with this iBook for the time being.
Anyway, if you're intending to undergo this task, I hope you find these notes helpful.  Unfortunately, I didn't take any photos while disassembling it which I'm sure would be incredibly useful. However, I had far more critical things to worry about at the time!  Instead, I took these photos after reassembly, so they're not that helpful.  Even so, I've put some notes on the photos on the Flickr pages which could be handy.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/10/02/ibook-ccfl-replacement/feed/</wfw:commentRss>
		</item>
		<item>
		<title>O2 Cocoon: Review, Part 3: Wrapping Up</title>
		<link>http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/</link>
		<comments>http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/#comments</comments>
		<pubDate>Sat, 01 Sep 2007 11:50:03 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[3g]]></category>

		<category><![CDATA[camera-phone]]></category>

		<category><![CDATA[cameraphone]]></category>

		<category><![CDATA[Cellphone]]></category>

		<category><![CDATA[cellular]]></category>

		<category><![CDATA[Cocoon]]></category>

		<category><![CDATA[gsm]]></category>

		<category><![CDATA[Hands-On]]></category>

		<category><![CDATA[isync]]></category>

		<category><![CDATA[mac]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[Mobile-phone]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[music-phone]]></category>

		<category><![CDATA[musicphone]]></category>

		<category><![CDATA[O2]]></category>

		<category><![CDATA[O2 Cocoon: in-depth Review]]></category>

		<category><![CDATA[Review]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/</guid>
		<description><![CDATA[I've been using the O2 Cocoon as my main phone for a few weeks now, and I'm fairly happy with it.  After covering the design of the phone and the music features previously, I'll wrap up by covering the rest of the features.

As I said before, it's a good phone.  In particular, the One Big Distinguishing Feature -- the external display -- does work quite well.  I do, however, with they'd put a "clock" button on the outside.  I haven't worn a watch in about ten years, since I got a mobile with a built-in clock (yes, those used to exist).  As a result, I use my mobile like a pocket watch.  In fact, I probably use my phone more as a watch than as a phone.
On the plus side, the nice big external display works well... except in sunlight as mentioned in Part 1.  However, it's not always on:  it only stays lit for a few seconds, unless it's externally powered.  So, to check the time you have to open the phone, which defeats the purpose of the external display.  The alternative is to fiddle with the music controls, which almost works:  the clock appears after scrolling messages like, "HELLO, I LOVE YOU - THE DOORS - PAUSED".  A simple "check time" button would be more useful.
The firmware is fairly nondescript.  The user interface is basic but clean.  It's not quite as well laid out as the Nokia or Sony Ericsson firmware, but I didn't find any major blunders.
I was discussing the LG Shine with my sister the other day.  One thing she mentioned was the number of button presses to send a text message.  With her old Sony Ericsson, it was just a few presses (plus the message itself), whereas the LG Shine had a minimum of eight or so.  This was a sign of poor UI design, I guess.  I remember that one of the reasons Boo.com failed in the old days was the ridiculously long and confusing path to a successful purchase.  Same with the Shine.
I'm not sure what procedural criteria she used for testing this, but the Cocoon seems to be slightly better than the Shine in this regard.  There were a few bloopers, such as the slightly silly configuration of the shortcut bar.  Like many other new phones, the Cocoon allows you to set up a few shortcuts on the main screen to commonly used functions.  In my opinion, a well laid-out UI shouldn't need this capability, but hey.  Well, in their wisdom, O2 have chosen an odd choice of shortcuts to start with, such as another link to the music player, as if the four buttons down the side weren't enough.
There's also no easy link to the camera.  Some phones, such as my old Nokia 6680, have an external lens cover, which activates the camera function when opened.  Others, such as the Shine and the Nokia 6280 I was using before the Cocoon, have an external shutter button which activates when held down.
The Cocoon has no such button.  Instead, it's five or six clicks through the main menu.
Suffice to say, one of the first things I did was to change the shortcuts.
On the subject of the camera, I must say I think the Cocoon's 2MP camera is not too shabby at all.  It's still just a tiny little chip like other normal phone cameras, but it doesn't seem to suffer from the "stripey graininess" that seemed to affect most mobile phone cameras I've used.  There's some chromatic aberration, the camera controls are a bit clunky, the shutter is a bit slow, and it's all a little bit soft and blurry, but other than that it does the job.
That sums up the Cocoon quite well.  It does the job.  It could do the job better, but it doesn't make me want to violently turn it into little white and black pieces, and believe me, some phones will do that to you.
So, what's the big thing I really don't like about it?
Mac compatibility
The Getting Started guide that comes with the Cocoon is quite upbeat:  "O2 Cocoon is also Mac friendly", it says.  Bollocks.
What they mean is that you can mount the phone as a USB drive, and then use the Finder to drag music files to/from it.  Later on in the book, they reveal that you need third-party software to use iTunes to manage it, and "Unfortunately it is not possible to synchronise calendar or contacts."
This is a big problem for me.   I damned the LG Shine for lack of Mac support, and I must do the same for Cocoon.  Both of these phones are oriented towards posers, especially the white and curvy Cocoon.  So why alienate the biggest gadget posers of all, us Mac users?
You see, one very nice feature of Mac OS X is that it comes with iSync:  a framework for data syncronisation between the Mac and devices such as mobile phones.  Out of the box it supports a fairly wide range of phones, and although Apple can be quite slow at updating that list, when it works, it really does work.
With a few clicks, I can have my address book and iCal calendar synched with my phone, and vice versa.  No software installation is necessary, and all it requires is pairing the phone over Bluetooth.
This capability alone has brought sales to Apple, as more than one person has seen me sync my phone and iPod and wanted that ease-of-use enough to go down to Apple Regent Street and buy an iBook.
For PC users, an third-party utility is necessary.  In my experience, the quality of this software ranges from terrible to bearable, but never quite as good as iSync.  I've had the embarrassing misfortune of wrecking a client's Windows installation trying to get such software running on their PC.
The Cocoon allegedly comes with its own software suite which includes this functionality.  I'm not really in a position to test or evaluate Windows software, so I can't tell you how good it is.
What I can tell you is that a manufacturer can add support for their phone to iSync merely by creating a configuration file or two.  They just need to specify the particular oddities and specifics of their firmware to iSync, and then it takes care of the rest.
This means that when a new Nokia, Motorola or Sony Ericsson phone is released, there's a good chance that an enterprising hacker can whip together a usable config file in a few minutes, just by finding a similar supported phone and tweaking the file.
Since iSync doesn't support any LG or Pantech phones, this quick hack route isn't possible for the phones I've reviewed.  However, with enough technical information on the Cocoon, I reckon a fully functional driver could be put together in a week or so.  Certainly far less time than was spent on the PC Suite.
I contacted O2 about this issue, and got the following response:

Although O2 are committed to Mac support we are unable to support iSync at this moment in time. However it is possible for Mac users to still update and change their music by dragging and dropping files to and from the phone.
We are actively investigating iSync support for both Cocoon and all future O2 branded devices.

This is admittedly better than the lack of reply to a similar query I sent to LG, but until I see working iSync support, I'm not completely convinced.
In the meantime, I'm stuck with transferring my contacts via the USIM from my old phone, so they're all truncated, divided and generally munged.
I've made purchase decisions based solely on iSync compatibility (or lack thereof) before.  I didn't buy my Nokia 6680 until there was iSync support for it.  Looking at the web stats for my LG Shine review I can tell you that I'm not alone in thinking this is important.  There are enough hits coming from Google searches such as "LG Shine isync", "LG Shine Mac" and "shine phone isync doesn't work" for me to assume that someone would be fairly popular if they hacked such a file together for the Shine, and I reckon the same would be true for the Cocoon.
So, hurry up, O2.  Demand iSync compatibility from your OEM, or at least demand the technical information necessary for third-parties to add it.  Talk to Apple and see how they can help.
Anyway, on that note, I'll wrap up.
I'm going to carry on using the Cocoon.  All things considered, it's an above average phone with some very useful features.  I still don't think it's as good as they think it is, but it's a darn sight better than some of the other phones I've used in recent years.  When I get around to it, I'll try shoehorning my contacts into it, using one-by-one Bluetooth if necessary.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/09/01/o2-cocoon-review-3/feed/</wfw:commentRss>
		</item>
		<item>
		<title>O2 Cocoon: Review, Part 2: Music</title>
		<link>http://gidden.net/tom/2007/08/23/o2-cocoon-review-2/</link>
		<comments>http://gidden.net/tom/2007/08/23/o2-cocoon-review-2/#comments</comments>
		<pubDate>Thu, 23 Aug 2007 19:34:40 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[3g]]></category>

		<category><![CDATA[camera-phone]]></category>

		<category><![CDATA[cameraphone]]></category>

		<category><![CDATA[Cellphone]]></category>

		<category><![CDATA[cellular]]></category>

		<category><![CDATA[Cocoon]]></category>

		<category><![CDATA[gsm]]></category>

		<category><![CDATA[Hands-On]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[Mobile-phone]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[music-phone]]></category>

		<category><![CDATA[musicphone]]></category>

		<category><![CDATA[O2]]></category>

		<category><![CDATA[O2 Cocoon: in-depth Review]]></category>

		<category><![CDATA[Review]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/08/23/o2-cocoon-review-2/</guid>
		<description><![CDATA[The first part of my review of the O2 Cocoon was mainly about the hardware: the look and feel of the thing you hold.  This time, I'm going to look more at the phone's music features.

When it comes down to it, the Cocoon is really just a normal mobile phone.  It's not a smartphone, but it will do the normal things a modern phone does.  It's got Java, calculator, calendar, notepad, voice recorder, and so on.  It's got a browser, which seems to be fairly functional.  It's got a camera... two, in fact, as is common with 3G phones.
It also has music player functionality.  O2 seem to be positioning the Cocoon as a music-oriented device, with external player buttons, stereo speakers, halfway-decent earphones, and so forth.
This is nothing new, though.  We've had music-oriented mobile phones for years now, and none of them have really worked too well.  As far as I'm concerned, I always end up thinking, "Hmmm... nice try, but I think I'll stick with my iPod."
Considering my personality type, I was fairly late to the game when it came to iPods.  I've been a Mac user since 1999, and I've had a reasonably large MP3 collection since 1997.  Even so, I didn't own an iPod until 2004, partly because I was working either at home, or living very close to work.  With the lack of a long commuter journey, I never really needed anything to keep me entertained.
Nowadays, I swear by my iPod, and sometimes at my iPod.  I'm onto my seventh now, thanks to AppleCare warranty and my negative aura towards hardware, plus the proximity of Apple Store Regent Street and a fully-functioning credit card.
I'm also now consigned to a lifetime of going to the gym regularly so my bad back doesn't seize up.  I'm one of those people who would never exercise voluntarily, so I have to have something to listen to to keep me from getting bored.  I went through a stage of listening to music at the gym, and then stand-up comedy... I have pretty much everything Audible.com has when it comes to Robin Williams, for example.  Then the Ricky Gervais podcasts.  Now it's "Real Time with Bill Maher", and the weekly SModcast from Kevin Smith and Scott Mosier.
So, the real test of the Cocoon was to see if it could manage to replace my iPod at the gym.
I usually have my iPod in one of those silicone cases clipped to my waist, and an Apple iPod remote snaked up under my tee-shirt with my Shure E2Cs plugged in.  The Cocoon doesn't come with a proper case, and there isn't a mad rush on eBay to start churning them out.  Never mind:  that's what pockets are for.  For the music player to work, the hands-free kit needs to be plugged in.  This is a fairly basic one-button + microphone affair, all modelled in curvy rubberised plastic, with a standard stereo jack socket on the end.  As mentioned last time, it comes with a matching jack splitter, which is a neat addition.  However, I'd rather they'd spent the money on better earphones.  They're of the in-canal kind, with three differently-sized pairs of ultra-soft sleeves.  The cable is short so the headset blob including microphone sits at roughly mouth height.  The problem is that the sound quality is grotty for the short time they stay in my ears before falling out.  This might not be their fault, however... the insides of my ears seem to be made of teflon.
Unlike the Apple iPod remote, the headset is basically controls-free... one button for play/pause (and answering incoming calls).  This means I have to reach in and get the Cocoon out to change tracks.  The external controls are basic:  forward, reverse, play/pause and Radio on/off.  They're quite slow to react, and the external LED display is a little limiting when it comes to navigation to say the least.  Instead, I flip open the phone so I can see what I'm doing.
The 'Now Playing' interface is not laid out particularly well.  Many of the functions use the normal phone menus, but the actual playing interface uses the main navigation keys.  Left and right on the main pad give previous/next track.  Up and down control volume, which is an odd choice, since the main volume knob is less than an inch above.  Centre is play/pause.
What's odd is that the tracks are listed in the display vertically, but selected using the left/right keys.  I've accidentally increased/decreased the volume a few times when I meant to change track.  On the other hand, the side buttons are arranged vertically and are equally accessible at this point.  In other words, I'm slightly annoyed by the pointless duplication, especially since it's unintuitively implemented.  This redundancy means we don't have control over track rating, shuffle, repeat, and so forth from the main interface, and have to faff around with menus instead.
The menus do contain a few bits and pieces, though.  Along with the more mundane sleep timer and 7-band equaliser, there's the choice of "Solid Sound", "Super Bass", "Super Surround", "Extreme Surround" and "X-Treme Ultra Surround To The Max". Okay, I made up that last one.  There's also "Stage Sound", offering "Studio", "Concert Hall" and "Stadium" modes, which translate to various levels of echo and distortion if you think your music is just a little bit too high-quality for your tastes.
For podcast listeners, such as myself, there are a few major problems:  Firstly, it's very easy to quit Music Player while paused -- for example, by closing the phone -- and thus "Pause" becomes "Stop".  Secondly, if you do "Stop" the track, the Cocoon won't remember where you were.  The iPod treats podcasts and audiobooks differently from music tracks, and stores your last position in the track before stopping.  So, if you need to stop for a while and return later, you can pick up where you left off.  Thirdly, the fast forward is sloooooow.  So, if you do stop a podcast half-an-hour in, it'll take two or three minutes of holding down the button to get back to where you were.  To compare, the iPod uses the click-wheel to scrub through a track, and the scrubbing speed accelerates with use.  I can scrub through half an hour of SModcast in less than five seconds.  With the Cocoon, I'd managed to walk home from the gym in the time it took to pick up where I was.
This is because, unlike the Cocoon, the iPod is a dedicated media player.  It's also because phone firmware tends to be designed by people who aren't really thinking about how the device is actually used in real life by real people.
What we want a proper convergence device:  something that manages to be a camera, a music player, a PDA and a phone, without actually compromising any of those.  If you want good pictures, buy a camera instead.  If you want a good GPS unit, buy a Garmin instead.  If you want a good music experience, buy an iPod, a Zen, a Zune, or an Archos instead.
Every single attempt to converge these things ends up being a disappointment.  The only thing that's come close seems to be the iPhone, and even that seems to be a whole slew of compromises at the moment.
The Cocoon is stuck in the same kind of mud.  The music player works, but it's just not really quite right.  All the boxes are ticked, but it's just not an iPod replacement.
One thing it does have over the iPod, though, is external speakers.  They're pretty tinny, but they're good enough for listening to spoken voice in a quiet place.  Unfortunately, not good enough for Radio 4, though:  the FM radio only works when the headset's plugged in, or the Cocoon's in the Nest, for some reason.  As I've mentioned before, when "nested", the phone can act as a clock radio.  Unfortunately, it's fairly quiet compared to the average &#163;10 Alba standalone unit from Argos.  It would wake me up, but I can't speak for heavier sleepers than myself.
It also has removable storage:  the internal 2GB of storage is supplemented by a microSD slot capable of taking another 2GB.  Dumping music on the Cocoon from my iBook was okay: when you plug the Cocoon in via USB, it asks whether to connect to "Sync", "Music Player" or "Transfer Files".  Both "Music Player" and "Transfer Files" work, but the upshot is that a new drive appeared called "Cocoon", on which I could dump my music files.  Not as easy as the dedicated iTunes/iPod sync, but understandable, I guess.  I can't say how well it works on a PC with Windows Music Player, because as you know by now, my hands start burning whenever I touch a PC.
Did it pass the gym test?  Not really.  It certainly didn't make me stand up and shout "Why have I been putting up with carrying two gadgets around with me all the time?!?  I must leave now to dispose of my iPod in a suitable manner!"
The bottom line is that if you don't have an iPod, or you really don't want to carry around two devices, then the Cocoon will suffice as a music player / phone combo.  I'm not going to say any more than that, because I don't think the features are significantly better than the other music-capable phones I've had.  The Cocoon accessories are less plasticky, except for the earphones, and the external controls are sometimes useful... but it's just not quite there yet.
Since the Cocoon's firmware is nothing too special (as I'll cover later), I assume it's just a standard firmware Pantech use on their other phones, with a few tweaks mandated by O2.  In my opinion, O2's tame scandinavian designers should pay just as much attention to the interface of the phone as they spent on the outside.  It's this kind of HCI attention-to-detail that makes the iPhone such a big deal, and something the other phone manufacturers will have to figure out if they don't want to get thoroughly shown up by Apple.  Apple doesn't need multi-touch to trounce phones like the Cocoon... they just needed common-sense.
My review might sound quite damning, but it's really just a comment on pretty much all current phones.  They all suck in different ways, but when it comes to music playing, they all seem to suck in similar ways.  As I mentioned last time, the Cocoon is quite a nice phone... but the software is nothing special.
Incidentally, after using it for over a week, on the whole I still prefer the Cocoon to any of the phones I've used in the past few years, including the LG Shine.  I'm just not totally nuts about it.  It's certainly better than the hated Nokia 6280 I bought on contract, but I must say, the 6280 still has one feature that the Cocoon (and the Shine) don't, and I'm still missing it.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/08/23/o2-cocoon-review-2/feed/</wfw:commentRss>
		</item>
		<item>
		<title>O2 Cocoon: Review, Part 1</title>
		<link>http://gidden.net/tom/2007/08/21/o2-cocoon-review-1/</link>
		<comments>http://gidden.net/tom/2007/08/21/o2-cocoon-review-1/#comments</comments>
		<pubDate>Tue, 21 Aug 2007 22:02:05 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[3g]]></category>

		<category><![CDATA[camera-phone]]></category>

		<category><![CDATA[cameraphone]]></category>

		<category><![CDATA[Cellphone]]></category>

		<category><![CDATA[cellular]]></category>

		<category><![CDATA[Cocoon]]></category>

		<category><![CDATA[gsm]]></category>

		<category><![CDATA[Hands-On]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[Mobile-phone]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[O2]]></category>

		<category><![CDATA[O2 Cocoon: in-depth Review]]></category>

		<category><![CDATA[Review]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/08/21/o2-cocoon-review-1/</guid>
		<description><![CDATA[As you might have gathered from some of my previous posts, I do enjoy playing with new mobile phones, and I really enjoy ranting about them at length on the internet.  So, I was stoked to receive an email on behalf of O2 offering to let me try out their new "Cocoon" music phone.

I've been playing with it for a few days now, and I must say I like it.  I don't love it, though, as it does have some flaws.  It's got one massive flaw -- which you might be able to predict from my other posts -- but one feature which might just swing it for me.  More on that later, though.
O2 have commissioned this phone themselves, rather than just branding an existing OEM model.  They've handed it to a goatee-growing, polo-neck-wearing Swedish design agency, who have obviously put together a bunch of unfeasible design sketches and then passed it on to manufacture by Pantech, a huge Korean phone maker who we've barely heard of here in the UK.
I'm not sure where the name "Cocoon" came from, though.  It reminds me of an old Dilbert cartoon where it turns out the only two codenames left for new projects are "PHLEGM" and "PLACENTA". 
The phone is a curvy white semi-minimalist design, reminiscent of Marvin in the film version of The Hitchhiker's Guide to the Galaxy, or the shagging robots in that Björk video by Chris Cunningham.  You might think it matches the Apple iPod/iBook white aesthetic, but it doesn't really.  Apple go more for rectangular rounded glossy white plastic, while the Cocoon goes for smooth curves with crisp edges and a more "satin" finish.
The whole thing's really built around a single distinguishing feature: the five-character 16-segment blue LED display on the front.  Invisible when off, but bordered by a few inset symbols, it glows behind the white surface rather pleasantly with a relatively deep blue.  I'm in two minds about the blue:  would it look simpler and better if white LEDs had been used instead?
So, to start with, we get a minimalist white cardboard box, with the word HELLO embossed in the same sixteen-segment font across the front.  The lid flap is neatly held down by a rare-earth magnet hidden somewhere in the box, and then reinforced for good luck by a nasty VOID sticker.  Opening the flap reveals a panoramic picture of something-blossoms which I totally ignore in favour of the phone itself sitting nestled there.  A small plastic tab on the side marked "PULL" reveals the side tray, full of accessories.
The phone itself is a clamshell phone, with a comfortable spring to it, and a thick hinge.  It closes with a solid "thunk", rather than a "snap" thanks to the rubber buffers inside.  The outside is white plastic, and fairly featureless, until you notice a few fiddly details, like the camera, flash/"lantern", black volume wheel, battery panel, lanyard post, and inset indicator symbols.
The sides and the inside of the phone are black and covered in buttons and widgets, such as the stereo speakers either side, the do-everything "port", a slider to release the battery/SIM panel, a microSD slot, and control buttons for the music features.
Inside, we see the standard arrangement of screen, earpiece and video-call camera on the upper half, and keys and microphone on the lower half.  In between, there's a little-used volume wheel built into the hinge which works well from either side.
The main phone and navigation keys are flat but with slight ridges and dimples in places for touch.  The keys are very slightly backlit in a pale sickly green.   The main navigation device is a flat four-way clicker with centre button, along with two multi-function keys and the two hook buttons:  in all, a very standard layout.
When the phone is open, it forms a graceful curve which the Swedes obviously spent long nights sketching with markers.  Unfortunately, this leaves the phone a little uncomfortable to make calls with:  the flat edge and face of the earpiece doesn't contact the ear at a good angle, leaving the call either tinny, or the phone pressed close against the cheek.  Score one for design -v- practicality.  However, this isn't really a big deal.  I've had a three-hour conversation using the Cocoon and it only bothered me to start with.
So, now onto the elephant in the room... the LED display.
To me, this just looked like a gimmick.  We've seen phones with external displays before, and they're just nothing to write home about.  Okay, this one's got a neat docking station (the "Nest", as they refer to it), but I had a desk charging station for my Nokia in 1996.  Whoop-de-doo.
The Cocoon fits sideways into the Nest in what seems to me to be a thoroughly mixed metaphor.  The designers have taken a leaf out of the iPod's book when it comes to connectivity.  There's a single port on the side of the phone, akin to the iPod's "Dock Connector", which acts as a connector for the headset, charging, docking, and even FM radio antenna.  The USB cable plugs either into this port, or into the identical connector on the back of the Nest, with the Nest plugging into the phone with the same type of plug.  The other end of the cable is a standard USB plug that either goes into the computer or into a mains-plug charger.
They've even taken the idea of removable plug pins from the iPod charger, including an oddly-hinged UK three-pin adaptor, and a similarly-bendable European two-pin adaptor.  I don't blame them for copying the iPod, because the iPod did it right, and anyway Apple probably weren't the first to do it either.  Anyway, the arrangement is pretty much identical in topology to the iPod setup.
This brings up the issue of overcharging the battery:  the Cocoon's manual points out that full charge/discharge cycles are far more conducive to battery lifetime than quick top-ups, and yet the Nest encourages this bad behaviour.  While the Nest is plugged into the mains, it will charge the phone, regardless of the point in the discharge cycle.  And, if you're using this thing as an alarm clock, you want it to remain charged.  Unsurprisingly, the manual doesn't cover the issue to this depth, so I'm a little at a loss on what to recommend.
Along with a headphone jack socket, the Nest has two of the multi-function ports on the back: one for the power/USB cable, and one for the FM radio antenna.
Annoyingly, the Nest is lightweight and a bit too small.  If you lift the phone, the Nest invariably comes with it.  You have to hold down the Nest to remove the Cocoon, and since it's so slim, you end up pushing sideways on the cable plug.  I think including a hefty lump of depleted uranium in the base might've made it easier.  Failing that, they should've made it bigger to give something to push against, and made the Nest's docking plug fit looser.  Instead, I'll probably end up Blu-Tacking the whole thing down.  (Incidentally, as I discovered while taking an abortive set of pictures of the Nest, Silly Putty sticks like glue to the rubberised base of the Nest... I ended up having to break out a range of solvents to get rid of it all.)
So, while the Cocoon is nestled in its... Nest... it sits there blinking the clock, just like a blue-hued alarm clock.  While the Nest is powered, the Cocoon will keep the clock showing, so it functions perfectly as a bedside or desk clock.  In fact, it's better than my existing alarm clock, a PURE Sonus-1XT DAB Radio which, while designed with accessibility for the visually-impaired in mind, manages to have an illegibly low-contrast screen. The Cocoon also hasn't crashed yet, unlike the Sonus.
[NOTE: I'm not visually impaired; I just got it for the sexy female voice-synthesis.  I also seem to have a disturbing tendency to buy alarm clocks that end up crashing.]
The big deal -- and I really do mean Big Deal -- about the LED display, is that it's also used for other things.  Okay, this is no great surprise, but until you use it, it's not clear how staggeringly cool this is.
When I get an incoming call or text, I hear the ringtone, look over, and see the name of the caller scroll across the screen.  I can happily ignore the call without having to go across the room, pick up the phone, open it and start pressing buttons.  Incoming messages are partially read out across the screen, which I suppose could be a little embarrassing in a public place...
I can walk into the room and notice the little blue LED above the clock backlighting the debossed "missed call" light.  A meeting reminder will display the subject of the meeting.  The possibilities abound.
For years I've been wondering why combined cable television and phone companies (ie. all of them?) don't integrate Caller-ID into the TV STB.  If I'm watching a show, it would be handy for the name and/or number of the caller to come up on screen with the "Busy" option on the cable remote, rather than having to get up and check the phone, or, heaven forbid, answer it.  This Cocoon/Nest layout isn't quite that, but it's a start.  I don't have to get quite so distracted by my mobile phone as usual.
Of course, this functionality also happens while the Cocoon is away from the Nest, but then it's just like every other mobile's external display, and not quite as big a deal.  Fatally, the LED display is totally invisible outdoors in daylight, even when overcast.  The white plastic is just far brighter than the subtle blue LEDs could ever be.  I wonder if the same form factor and concept could be better utilised with a reflective display technology like electronic ink...
O2 have been fairly generous with the accessories.  We get a headset cable as usual, with a plug for that multi-function port, and a standard stereo jack socket with tiny microphone hole and a single button.  Since this is meant to be a music-oriented phone, and therefore a potential iPod replacement, I would have preferred a stereo jack socket built-in to the phone itself, rather than having to drag more cables around.
Considerately, they've also thrown in a stereo jack doubler to allow two people to share the phone.  Nice touch.  I also notice that when these accessories are all finished in the same black faux-rubber and also curved in the same way so they form a willowy shape when used together.  Again: nice touch.
Along with all of this comes the earphones.  Rather than the grotty fall-out-of-ear types that came with the LG Shine, they've included in-ear-canal ones with three sizes of ultra-soft sleeve.  The cable is very short to keep the headset microphone high, and the separate earpiece cables are asymmetric so the weight of the headset only tugs on one of your ears.
I'm going to cover the other aspects of this phone in a day or two, but so far, I'm fairly happy with the hardware.  Most of it is nothing special, and it does seem a little over-designed at times.  However, I can't stress enough how neat the Cocoon is while "nested".  Such a simple idea, and not a particularly new one at that.  However, they gone done it right.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/08/21/o2-cocoon-review-1/feed/</wfw:commentRss>
		</item>
		<item>
		<title>LG Shine KU970: The 3G Shine</title>
		<link>http://gidden.net/tom/2007/07/20/lg-shine-ku970-3g/</link>
		<comments>http://gidden.net/tom/2007/07/20/lg-shine-ku970-3g/#comments</comments>
		<pubDate>Fri, 20 Jul 2007 12:08:32 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[2g]]></category>

		<category><![CDATA[3g]]></category>

		<category><![CDATA[camera-phone]]></category>

		<category><![CDATA[cameraphone]]></category>

		<category><![CDATA[Cellphone]]></category>

		<category><![CDATA[cellular]]></category>

		<category><![CDATA[firmware]]></category>

		<category><![CDATA[gsm]]></category>

		<category><![CDATA[Hands-On]]></category>

		<category><![CDATA[KE970]]></category>

		<category><![CDATA[ku970]]></category>

		<category><![CDATA[LG]]></category>

		<category><![CDATA[LG Shine: in-depth Review]]></category>

		<category><![CDATA[LGShine]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[Mobile-phone]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[nokia]]></category>

		<category><![CDATA[shine]]></category>

		<category><![CDATA[Shine-Phone]]></category>

		<category><![CDATA[Slide-Phone]]></category>

		<category><![CDATA[vodafone]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/07/20/lg-shine-ku970-3g/</guid>
		<description><![CDATA[Thanks again to the LG Shine Blog, I received an LG Shine KU970 mobile phone to review.  This is the newer 3G version of the KE970 I reviewed earlier this year.

I've been eager to have a play with the 3G Shine since I received the 2G one six months ago.  As luck wouldn't have it, I had just switched from Orange to the 3G-only Three network a month or so before.  So, I couldn't use the Shine I received as my primary phone.  Instead, it's had an Orange PAYG SIM installed which I must admit I've mainly used for getting cheap cinema tickets.
As I said in my previous review, the Shine is -- for the most part -- a great phone.  It's physically attractive and pleasant to use; the software is clean and well-designed; and overall it's an unassuming little unit.
Receiving the Shine coincided with my growing realisation that, gadget freak as I am, I'm actually happier with a "dumbphone" than a smartphone.  Writing blog entries and playing Texas Hold-Em while walking across a tightrope over the river Amazon might sound appealing, but making and receiving calls is far more important to me.  In my experience, smartphones tend to be slow and more prone to crashes, while also being large and unwieldly.  I started to miss the old days of the tiny little Nokia 8310, and firmware that actually responds to keypresses instantly.  For a while it seems that the more advanced (esp. Symbian-based) phones I've had are completely incapable of reacting to the red button when you've accidentally conferenced your ex-girlfriend with 999, for example.
So, the 2G Shine was a breath of fresh air.
Here comes the 3G version
To be honest, there's very little I can say about the 3G Shine.  Physically, it's almost identical.  There's the addition of the secondary video-call camera, neatly done.  Inside the back case, there's a small reconfiguration of the layout, including the removal of the external memory slot, replacing it with hardwired memory instead.  A few manufacturing tweaks and a little bit of subtle network partner branding, but otherwise it's the same.  Same size, same shape, and from what I can tell, same weight.  This is not a bad thing... the Shine was a neat enough package as it was, so the fact that they've managed to cram the 3G kit into the same form factor is impressive, and a testament to how close 2G and 3G technology are finally coming.
So, what about the other differences?  This is where I drop the clanger:  I don't know.  This is solely down to one thing... the firmware.  The 2G Shine I received in January was a pre-release unit with generic firmware.  Nice, simple and clean.  The 3G Shine I received seems to be a release unit, utterly crudded up with Vodafone customisations.
(It's externally branded with the "Proximus" logo, so I'm assuming this one's got Benelux firmware, but knowing Vodafone, it's probably the case everywhere.  I don't know for a fact what the release firmware is or will be like on other networks in other countries, but I'm just going on what I've got here)
I'm always disliked vendor's custom firmware.  I've never used custom firmware that's any better than the generic, and it's usually slower, crashier and far more limiting.
While I've bitched about Orange screwing with the firmware before, I've always appreciated that it's nowhere near as bad as the massacre Vodafone regularly perpetrates on everything they get near.  They tend to rip out handy features, mess with the UI, and then scatter a liberal helping of "Vodafone Live!" nonsense everywhere.  On some phones, they even go to the extent of excluding the "Live!" button from the keylock, which is just plain stupid, and at worst, a machiavellian way of ramping up bills through accidental data usage.
So, in my opinion, the Vodafone customisations on this Shine have destroyed any usability plus-points I've mentioned before.  They've cut out the nice, clean anti-aliased fonts in favour of a hideous jagged console font.  They've added a tonne of crap to the main menu, making it harder to navigate quickly.  They've reassigned action buttons to illogical places.  They've removed a lot of the customisation functions.  Least importantly, but perhaps most disappointingly: they've removed all the ludicrous but fun tunes and other nonsense.  And with all that, it seems that the only thing they've added to the mix is the excretable forementioned "Live!".
This has annoyed me to the point that I just don't want to use this thing.  I was fully intending to use it as my primary phone for a week or so, but I just couldn't do it.  It's too damn disappointing.  I actually prefer my Nokia 6280, which is truly surprising.
In conclusion...
I'm sure that if I was comparing the two units with generic firmware, I'd be raving about the 3G Shine, while still bemoaning the lack of Apple iSync and a couple of the other points I mentioned last time.
Instead, I'm putting this thing back in the box.  It may be harsh, but it's what I would be doing if I'd bought it for real.
Shame on you, yet again, Vodafone.  SHAME!!!  With your heavy-handed alterations, you've ruined a lovely product.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/07/20/lg-shine-ku970-3g/feed/</wfw:commentRss>
		</item>
		<item>
		<title>iTunes Library Regeneration</title>
		<link>http://gidden.net/tom/2007/05/10/itunes-library-regeneration/</link>
		<comments>http://gidden.net/tom/2007/05/10/itunes-library-regeneration/#comments</comments>
		<pubDate>Thu, 10 May 2007 12:48:43 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Techie]]></category>

		<category><![CDATA[bug]]></category>

		<category><![CDATA[ipod]]></category>

		<category><![CDATA[itunes]]></category>

		<category><![CDATA[podcasts]]></category>

		<category><![CDATA[rant]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/05/10/itunes-library-regeneration/</guid>
		<description><![CDATA[The final major thing that "I Don't Like About iTunes and iPod" has annoyed me from Day One:  the monolithic bloaty binary library, and the accompanying tidy-but-inefficient XML backup.  For a small library, it's no problem, but mine has major issues.  Heck, and I don't even consider my ~40GB library to be particularly big!

Over the past few months, I've noticed that iTunes has been getting slower and slower.  It's clear that iTunes doesn't scale particularly well.  For anything under, say, 5000 tracks, it starts up quickly.  If you go much above that, it gets sluggish on startup.  Searches start getting slower too.  This doesn't happen linearly, either.
The binary library file was also significantly larger than the XML library file.  As a rule, I've noticed that the XML tends to be a little bit smaller, but my binary file was almost twice the size of the XML.  In this case, I felt it was worth regenerating the library.
Okay, the usual procedure for this (rather drastic) action is to shut down iTunes, and purposefully corrupt the binary library file.  iTunes will then rebuild the binary from the XML "backup" when it next starts.  If you just delete the file, it'll assume you don't have a library and will wipe the XML too.  So, I tend to move the old binary into a backup directory and then create a new dummy file.
In the past, this has tended to work well.  Occasionally there are a few quirks:  in an old version of iTunes, I seem to remember the play counts got trashed.
This time, there was a problem.  My Podcasts section was empty!  The files were still there, but they didn't appear on the list.  I then noticed that there was a new static playlist called "Podcasts" with all my old podcast files, but as as normal audio files rather than categorised podcasts.  These items didn't appear anywhere in the Library section: just the playlists.  So, it's not seemingly possible to delete them from iTunes.
I tried adding the Podcasts again from the iTunes Store, foolishly hoping it would notice the existing files.  Unfortunately, it just downloads fresh copies instead, naming them with a " 1" suffix.
So, I deleted the files manually, and then used the excellent Super Remove Dead Tracks from Doug Adams's site.
This problem highlights the design bloat I spoke about in my previous post.  Back before podcasts, audiobooks, video and all the other stuff appeared in iTunes, everything was neatly kept in the Music Library, and it all worked.  It was possible for the filesystem and iTunes to get out-of-sync with both missing and excess files in the iTunes Music folder, but on the whole, it worked well.
Nowadays, the addition of these new media types to the increasingly-inaccurately-named iTunes has complicated everything.  There's no central folder of everything and stuff can seemingly fall through the cracks.  If a Podcast isn't in the Podcasts list, it won't appear anywhere.
I think Apple should build a new piece of software, called iMedia or something like that, for managing everything currently handled by iPod, iTunes, iPhoto, iPhone, Apple TV and Front Row.
They should also consider using something intrinsic to the OS -- such as Spotlight -- to manage the libraries themselves, rather than relying on easily-breakable and easy-to-desynchronise monolithic files.  At the very least, they should rework it using Core Data, and if I had my way, also add "proper" RDBMS support to Core Data so I can use MySQL as my music library index!
In the process, they should reconceptualise the whole thing.  How should a digital hub operate?  It should work well with multiple libraries at the same time, with network nodes as data suppliers, so families and housemates can share media.  It should allow offline media integration, such as Delicious Library, so I can organise and manage my books and DVDs too.  Ideally, I'd want it to be able to control DVD jukeboxes, so I could build the mother of all home entertainment media servers around a single Mac Mini and a bunch of external jukeboxes, sources and filestores.  It should be open enough to allow companies like Elgato to fully integrate stuff like EyeTV.
That's the kind of innovative thinking we've come to expect from Apple.  Instead, we've got bloated, inflexible creeping featurism of the kind we've come to expect from Microsoft.
Oh, one more thing.  I'm on iTunes 7.1.1 on OS X, and it's crashing more than it did before.  I've had it bomb out a few times while converting videos for iPod.  Not good.
In conclusion, I must say that I still prefer iTunes and iPod to the alternatives... by a long way.  They're just not as good as they could, or should, be.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/05/10/itunes-library-regeneration/feed/</wfw:commentRss>
		</item>
		<item>
		<title>iPod Video Conversion in iTunes</title>
		<link>http://gidden.net/tom/2007/05/10/ipod-video-conversion/</link>
		<comments>http://gidden.net/tom/2007/05/10/ipod-video-conversion/#comments</comments>
		<pubDate>Thu, 10 May 2007 12:48:14 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Techie]]></category>

		<category><![CDATA[bug]]></category>

		<category><![CDATA[ipod]]></category>

		<category><![CDATA[itunes]]></category>

		<category><![CDATA[rant]]></category>

		<category><![CDATA[unicode]]></category>

		<category><![CDATA[video]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/05/10/ipod-video-conversion/</guid>
		<description><![CDATA[The kludginess of video conversion for iPod in iTunes is another one of the things "I Don't Like About iTunes and iPod".  I don't like the conversion process, and I particularly don't like the bug I think I've found.

Even before I got an iPod Video, I managed to accumulate a few videos in my iTunes collection.  Mostly music videos, in various formats, but a few other things too.  I've got a few from the iTunes Store, which transfer to the iPod just fine.  However, most are different formats and need re-encoding.
Apple have not made this as easy as they could.

"Movies" and "TV Shows" have their own sections in iTunes, but music videos appear in the music list.  This is inconsistent with the iPod, on which music videos get their own section in the "Videos" top-level menu.
As a result, it's difficult to focus just on the music videos for conversion.  You can use a Smart Playlist, but you don't get full control of the items in a playlist:  for example, you can't delete items without going to the main library list.  This is important later, after conversion.
You can't change the type of a video by bulk editing.  On import, my non-iTunes-purchased videos came up as "Movies" rather than "Music Videos".  To change this (and therefore decide where they appear on the iPod), you have to "Show Info", select "Video" and then change the "Video Kind" dropdown.  This function does not appear in the "Multiple Item Information" window usually used to edit groups of items.  The keyboard shortcuts for this procedure are also non-optimal, and this all translates to a lot of mouse work.
After a track is converted using "Convert Selection for iPod", it is not marked in any way.  The original is not unticked, tagged or labelled.  Instead, you have to look at the kind, such as "QuickTime movie file" or "MPEG-4 video file", and it's possible those are the same.  Otherwise, it's up to the Date Added column.
As the original files aren't disabled, they still trigger the warning dialogue on the next sync, saying that they're incompatible with the iPod.  The originals in my opinion should be unchecked so they don't get synced.  I'd ideally export the files out and then remove them altogether.  However, as there isn't an easy way to select those originals avoiding the converted versions, it's a chore.

Okay, all of those are design flaws.  Fairly annoying ones, too.  I've been of the opinion for a while that both iTunes and iPhoto were great packages in their day, but are in dire need of redesigns and rewrites.  They've lost their simplicity and elegance.  They're bloated.
The next thing, however, is a bug, demonstrated by this screenshot.  A number of the converted videos appear with blank names and artists on the iPod.  They play fine, but they're just not there.
In addition, it's also made the band's Music Videos entry appear six times:  three with the correct name, and three with a blank.  All six menus contain the same items, as above.
Upon investigation, all of these files are named fairly oddly.  They appear fine in the Show Info "Info" panel, but on the "Summary", there's a quirk:  the names are spaced out, and the file path has alternating underscores.  Checking the file paths and the iTunes Library XML file gives similar results:
I've seen this kind of thing before.  It looks like it's almost definitely a Unicode interpretation error.  As with most other modern string-handling APIs, NSStrings inside OS X (Cocoa) are stored with (at least?) two bytes per character, rather than the old-style one byte per character.  It's easy to make the mistake of failing to convert this back and assume one byte per character.
In the example above, the artist name -- R&#246;yksopp -- is clearly not plain ASCII, so I wouldn't be surprised if the programmers of iTunes's conversion interface failed to test for this problem.  However, I did also encounter the problem with some videos with plain English names and artists, too: my copy of Leonard Nimoy's "The Ballad Of Bilbo Baggins" also came up blank.
To fix this problem, I just went into each item's "Show Info" in turn and retyped the names.  Fine for the few items I imported, but not if I'd had any more.
I think Apple's point with all of this is that you should buy all your videos from them.  Mine mostly came from "enhanced limited edition" CDs instead.
Incidentally, in the shots above, you might notice two different versions of the incredible "Remind Me" video by R&#246;yksopp.  I've discovered that there are (at least) two subtley-different versions of this video, and the one on the iTunes store isn't quite as good.  Apart from the gratuitous cartoon boobie shot, the non-iTunes version has a couple of little hidden jokes in the background, and a few more scenes.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/05/10/ipod-video-conversion/feed/</wfw:commentRss>
		</item>
		<item>
		<title>iPod Photo Bloat</title>
		<link>http://gidden.net/tom/2007/05/10/ipod-photo-bloat/</link>
		<comments>http://gidden.net/tom/2007/05/10/ipod-photo-bloat/#comments</comments>
		<pubDate>Thu, 10 May 2007 12:47:57 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Techie]]></category>

		<category><![CDATA[bloat]]></category>

		<category><![CDATA[iphoto]]></category>

		<category><![CDATA[ipod]]></category>

		<category><![CDATA[itunes]]></category>

		<category><![CDATA[rant]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/05/10/ipod-photo-bloat/</guid>
		<description><![CDATA[In the process of replacing my iPod, I've noticed a couple of things "I Don't Like About iTunes and iPod".  After my previous rant about iPod reliability, I'm now onto the sloppy programming behind iPod's photo functions.

So, I started transferring all my media to the new unit.  The music went across fine.  Videos, not so much, but more on that later.  Photos, however, were taking hours to transfer.  iTunes was "optimising" the photos.  I remember this taking a while back when I got the previous iPod, but I'd forgotten how slow it was.
I've got about 19GB of photos, all neatly keyworded in iPhoto.  Since I got my iPod Photo two-and-a-bit years ago, I've kept a copy of my collection on my iPod: usually with "Include full resolution photos" ticked.
So, what's it doing?
It's decompressing the photos into YUV format at iPod screen resolution.
Each photo, regardless of the original file size is "thumbnailed" to a new file of about 851K on the new iPod Video, and marginally less on the iPod Photo and the Nano.  This is allegedly to offload some of the processing effort from the iPod to the host computer, so the iPod doesn't burn through batteries trying to do the instant photo scrolling thing.
Problems with this approach:

It takes a long time to convert all my photos.  I've got an iBook G4 1GHz, not an eight-core Big Mac.  Since the screen size is different on the new iPod, the whole process has to be done again.  I'm also not convinced it's thumbnailing particularly efficiently.  I bet ImageMagick would be faster.
It uses up a lot of space on the iPod.  Okay, I'm not likely to use up the 80GB any time soon, especially since my iBook doesn't have the disk space to store all that anyway.
It uses up a lot of space on the host machine: in my case, 9GB extra!  That's almost 10% of my laptop's HDD.
iTunes/iPhoto isn't well-behaved enough to clean up after itself.  The thumbnails have a nasty habit of sticking around.  If a photo is deleted, there's no guarantee the thumbnail will be deleted.  If you change iPod model (like I did), the old, useless, wrong-sized thumbnail will stay there.  If, after noticing this bloat, you disable some or all Photo syncing, the cache still sits there.  Considering how long the process can take, I understand this design decision, but I don't necessarily agree with it.
It takes ages just to transfer these thumbnails compared to transferring the (smaller!) originals.  Now that they've canned FireWire over the slower, less reliable USB2.0, iPod syncing is sluggish.  Piping this crapload of excess data around really doesn't help.

The thing is, I really don't think any of this is necessary!
Now that the iPod Video is better specced, why can't it do its own thumbnailing, and cache them locally?
And at the very least, why do they have to be possibly the least efficient file format?  JPEGs aren't hard to decode, and while I could understand the need for keeping lower resolution thumbs on the iPod, I can't see why JPEGs wouldn't do.  While admittedly the iPod uses hardware to decode video, it still manages to do some reasonably sweet 3D graphics in the new iPod Games, and I don't think they shoehorned a Radeon into the iPod, so the thing's capable of doing maths, to say the least.
As far as the hard drive is concerned, the standard reply is to get a bigger drive.  I've already got a 100GB drive in my iBook, and I still cling to the concept of portability, so an external drive is out.  If there was a good reason for this, I'd think about being more selective, but it's just waste and sloppy programming on the part of Apple.
It seems probable that Apple crammed in this functionality with the underpowered iPod Photo, and then failed to update the codebase.  I accept that the Nano might not have the oomph to do the work and would need the offloaded conversion, but then again, the Nano's not going to store a huge cache anyway!  When it comes to the larger, more powerful iPods, it should act differently.
I'm sure Apple aren't losing any sleep over this problem:  they're too busy working on the OS X-based iPhone and the inevitable touchy-feely non-phone-iPhone iPod that will accompany it.  That thing will presumably be able to do the thumbnails itself.
It still doesn't excuse the sloppy coding that's currently there.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/05/10/ipod-photo-bloat/feed/</wfw:commentRss>
		</item>
		<item>
		<title>iPod Reliability</title>
		<link>http://gidden.net/tom/2007/05/10/ipod-reliability/</link>
		<comments>http://gidden.net/tom/2007/05/10/ipod-reliability/#comments</comments>
		<pubDate>Thu, 10 May 2007 12:47:48 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Techie]]></category>

		<category><![CDATA[80gb]]></category>

		<category><![CDATA[hardware-failure]]></category>

		<category><![CDATA[ipod]]></category>

		<category><![CDATA[ipod-video]]></category>

		<category><![CDATA[itunes]]></category>

		<category><![CDATA[rant]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/05/10/ipod-reliability/</guid>
		<description><![CDATA[Last week, I got a new iPod Video 80GB from eBay, and in the process of transferring my media a number of things caught my attention.  Some of these are known about already, but they're things "I Don't Like About iTunes and iPod".  I'm covering these in a few separate posts, as I've got quite a bit to say on the subject.

Firstly, the failure of the old iPod.  Okay, this bit's the average iPod rant... nothing new here.
I've bought three iPods for myself now: a 20GB G3, a 60GB Photo, and this new 80GB Video.  However, I've owned more like six, thanks to AppleCare warranty replacements.  Although I'm known for having a "negative aura" when it comes to hardware (and am seen by some of my peers as the ultimate hardware tester), I've been careful with the iPods.  All have had an approved skin or case (usually an silicone iSkin), and have been treated well.  I haven't gone hiking, underwater or into space with them, or even regular commuting.  No significant drops either.  Even so, they keep failing.  I still haven't experienced the infamous battery problem, as none of my iPods have lasted long enough.
Last time, I took my 11-and-a-half month old iPod Photo 60GB on holiday with me to the Caribbean.  It started the "click of death" about one day into the trip.  I checked the warranty and I had only about a week left:  it would expire before I got back to civilisation.  So, I called my friend Henry to ask him to call AppleCare and ask them to let me buy the one-year extension when I got back.  They did.
Promptly, the iPod started working again.  I have no idea how Apple managed to reset the warranty trip remotely.  I'm guessing they have a satellite to do this.
Anyway, it worked fine all year.  There were no signs of failure, so I couldn't really get it fixed.  Last month, the extended warranty ran out again, and shortly afterwards, the click of death started again.  Within a day, it wasn't reliable enough to sync.
So, off to eBay I go.  To justify the cost of a new iPod, I sold my seldom-used PSP and games, plus the old iPod (clearly marked as faulty) and accessories which don't fit the new iPod anyway.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/05/10/ipod-reliability/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Mechanics Experiments with &#60;canvas&#62;</title>
		<link>http://gidden.net/tom/2007/04/03/mechanics-with-canvas/</link>
		<comments>http://gidden.net/tom/2007/04/03/mechanics-with-canvas/#comments</comments>
		<pubDate>Tue, 03 Apr 2007 11:54:20 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[Blogroll]]></category>

		<category><![CDATA[General]]></category>

		<category><![CDATA[Programming]]></category>

		<category><![CDATA[Techie]]></category>

		<category><![CDATA[canvas]]></category>

		<category><![CDATA[collision]]></category>

		<category><![CDATA[inertia]]></category>

		<category><![CDATA[javascript]]></category>

		<category><![CDATA[mass-moment-of-inertia]]></category>

		<category><![CDATA[mathematics]]></category>

		<category><![CDATA[maths]]></category>

		<category><![CDATA[mechanics]]></category>

		<category><![CDATA[moment-of-inertia]]></category>

		<category><![CDATA[polygons]]></category>

		<category><![CDATA[rigid-body-dynamics]]></category>

		<category><![CDATA[trigonometry]]></category>

		<category><![CDATA[verlet]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/04/03/mechanics-with-canvas/</guid>
		<description><![CDATA[A couple of months ago, I spent a few weeks playing with &#60;canvas&#62;.  The main reason was to write a game (currently on the back burner, but not "cold" as yet), and also to re-learn some simple mechanics and trigonometry I've forgotten since c.1993.  I've put together a little bit of code ("testbed") which lets me put together simple interactive diagrams.  Due to the lack of text support in &#60;canvas&#62;, unfortunately I can't label everything diligently.  My old maths teacher, Mr. Slatter, would be horrified.

I mainly got sidetracked trying to calculate the scalar, or mass moment of inertia of an arbitrary polygon.  This would be used to calculate what happens when something hits a polygon.  Unfortunately, I couldn't find any pertinent information about it, and a lot of conflicting (or just plain wrong) stuff confusing it with other things with similar names.  I even rootled through the garage and found my trusty 3rd Edition of Stroud, which got me through A-level maths.  Anyway, I finally found the answer and then took a break from the code.  I should really get back to it sometime.
After seeing some experiments done by my friend Martin, I've thrown caution to the wind and decided to publicise my egregious lack of mathematical knowledge, along with my hacky approach to non-browser-portable Javascript.  So, below is a cut-n-paste list of the experiments... comments are extremely welcome.

These pages are simple Javascript experiments with various geometric situations to try things out.
They are most likely to work in Firefox, but will probably run fastest in Opera if at all.  Safari is okay, as is Camino.

Experiment 1: Intersection between a stationary circle and a polygon.  Comparison of line normals against direction to intersection points gives whether the circle is inside or outside the polygon.  Uses the circle/line intersection test.
Experiment 2: Collision of circle in motion against a line.  Uses similar triangles to work out collision "time", and then reflects both C and C-prime in the line to give new positions for constraints.
Experiment 3a: Intersection of a circle in motion against a polygon, including corners.  Uses two methods: similar triangles technique for collision against edges, and circle/line intersection test for collision against corners.  Uses the first collision, using simple minimum finding.
Experiment 3b: As above, but using simpler algorithms.
Experiment 4: Oliver Humpage kindly wrote some PHP code simulating a simple collision between a point and a polygon.  I've translated this to the same framework I've used here.
Experiment 5: First step in calculating mass moment of inertia (MMI): triangulation of simple (but not necessarily convex) polygon using Ear Cutting.  This is non-optimal, but since the search for a simpler mechanism an open problem, I'm okay with going for the O(n2) solution since we're only doing this once (as long as the polygon doesn't change shape), and we're only doing it for a small n.
Experiment 6a: MMI test, using bh3/36, which doesn't seem right.  Comparison circles are also given.  One problem here is confusion between (scalar) {mass,polar,area} moments of inertia, probably thanks to structural engineers making a mockery of the terminology.  In particular, I think the author of this page has picked the wrong one (possibly "area" rather than "mass").  Wikipedia's not helpful on this point, and my calculus isn't really up to the task.  Finding a formula for the MMI around the centroid of a triangle (in 2D) is proving difficult.  I'm not sure if this value will even help:  the parallel axis theorem only works for axes in the plane of the shape, while we're trying to get it around an axis normal to the plane of the shape.
Experiment 6b: The above method doesn't seem to work, so trying a different method.  Seems to work well, although the figures go weird when the triangle is "inverted", ie. the vertices are anticlockwise.
Experiment 6c: Brute force approach, by gridding the triangle and treating each point as a point mass.  This should give an approximation for comparison of the other experiments.  Interestingly, there seems to be a relationship between the approximation and the largest (pale blue) circle (bounding circle around the centroid).  For an equilateral triangle, the approximation is about half that of the circle, and for a sliver-like oblique triangle, it's about 27%.  I suspect the range might be &#188; to &#189;, in inverse relation to the largest angle of the triangle (60&#176;&#8658;&#189;, 180&#176;&#8658;&#188;), but not necessarily inverse proportional.  The sliver, of course, tends to that of a thin rod, given by (ml2)/12.  As the rod has no area (our current analogue for mass), it gets tricky.
Experiment 6d: To compare the results of 6b and 6c.  Seems to match very well.
Experiment 7: Combines Experiment 5 with Experiment 6d to demonstrate the use of the MMI calculations on the arbitrary simple polygon.  The methods are functionized, and also parameterized to allow a different rotation axis point to the triangle's centroid: in this case, the polygon's centroid.  It demonstrates that the method from Experiment 6b is correct and general enough to use for the polygon.  This confirms the mass moment of inertia of a simple polygon around an axis normal to the plane of the polygon and through its centroid!
Verlet Experiment: Test of point-based verlet integration mechanism.  Simulates all objects as point meshes.  Too slow for use in a Javascript-based game, I think.
Mandelbrot: To demonstrate to Steve how canvasses work.  WARNING: Runs badly in anything but Opera.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/04/03/mechanics-with-canvas/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Transferred from GoDaddy to Dreamhost</title>
		<link>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/</link>
		<comments>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/#comments</comments>
		<pubDate>Mon, 12 Mar 2007 19:09:02 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[Techie]]></category>

		<category><![CDATA[dreamhost]]></category>

		<category><![CDATA[godaddy]]></category>

		<category><![CDATA[hook]]></category>

		<category><![CDATA[hooks]]></category>

		<category><![CDATA[perl]]></category>

		<category><![CDATA[post-commit]]></category>

		<category><![CDATA[postcommit]]></category>

		<category><![CDATA[subversion]]></category>

		<category><![CDATA[svn]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/</guid>
		<description><![CDATA[I finally got sick enough of GoDaddy to buy a Dreamhost account and transfer (nearly) everything over to that account.  Although I've only been using it for a few hours, I know I'm going to be far happier with it... especially the Subversion support.  Setting up a post-commit hook as described below has made maintenance a lot easier.

Writing off the $50 or so I spent on my GoDaddy account doesn't make me cry, and thanks to a handy coupon code, the new account only cost me about $90 for two years.
My main reasons for transferring over are:

Subversion support
SSH shell access
rsync support

I am so sick of running a slow and crappy ftp mirror to update my files, and a tedious process to upgrade Wordpress and other packages.  With the above features, this is going to be a lot easier.
Dreamhost's web admin interface could be a bit quicker, but it's cleanly organised and full-featured.  Everything operates as expected, and it didn't take me long to get set up.
The only thing that took me more time than I would have liked is getting post-commit hooks set up on Subversion, so my web projects are kept up-to-date.  All I wanted was a simple svn update run in a few directories of the web tree whenever a commit is performed.  As this seems to be a frequently asked question, here's what I encountered:

Errors don't seem to be logged, so it's mainly just fumbling in the dark.
When accessed through http: (rather than file: or svn+ssh:), the hooks are run as dhapache, the web server user.
Simply tweaking the permissions of the checkouts to 777 doesn't seem to help that much.
The hook is going to be chown'ed to you, rather than to dhapache.  You could rename post-commit.tmpl, but then you'd have trouble chmod'ding it +x.
Running setuid (yick!) would get around that problem...
...if you could run scripts (as opposed to binaries) setuid'ed. (Yep, I forgot that one)
...or if you could be bothered to write them in C, or at least wrapper them with C.
It's all a moot point, because Dreamhost seem to be undoing setuid flags on a cron, or something similar.  Possibly on some form of pre-execution check by dhapache.  Not sure.

I tried putting the updates in post-commit itself, but found instead that it's far easier to put them in a CGI script and just use curl inside the post-commit instead.  I suspect the post-commit execution has a bogus environment in some way, so I hand it off to the CGI, which is easier to debug.

#!/bin/sh
/usr/bin/curl -O http://mywebhost.dreamhosters.com/_svn_update.cgi

The CGI is going to run as you, rather than as dhapache, so the setuid isn't necessary.  My CGI looks something like:

#!/bin/zsh
set -f
echo Content-type: text/plain
echo
foreach f (/home/mywebhost/svn/_live/*) {
        /usr/bin/svn update $f
}

Now all I need to do is put a bunch of checkouts into ~/svn/_live, and symlink them into my web directories where necessary.  I've also thrown in my zshrc file for luck.
I've chosen to use file:/// checkouts rather than http:// for performance, so it's probably best not to try to use them as read-write checkouts... mixing protocols when using hooks is not fun in my experience. Currently, this updates all checkouts if one of them changes, which isn't particularly efficient.  I'm going to rewrite it using $1 instead.
I'm sure there's probably a better way of doing all of this, without the intermediate kerfuffle, but this works fine for now.
UPDATE (March 16, 2007):  I had another play with it.  I think it's possible to get the apache user (dhapache) to correctly perform an svn update on a checkout owned by dhapache, but it doesn't do exactly what I want... I really want the checkouts executed by my user, for various reasons.  I also tried some other approaches.
Anyway, I reverted back to the old idea: that of using CGIs, and using $1 to determine the repository in question.  I've rewritten the script in Perl (and the corresponding hook), so I can use regular expressions to untaint the parameters.  I'd usually pick Perl for an obvious scripting job like this, but PHP would work fine too.
The real overhead is filesystem performance, rather than the CGI call.  As DreamHost uses an (obviously overloaded) NFS setup internally, Subversion updates are slowwww (at least this week), even when using file:///.  So, fixing the script to only update the specific repository has sped it up a bit.
Incidentally, this script could easily fail dirtily if run at the same time as other stuff going on.  I've had to manually run 'svn cleanup' on the _live checkouts.  Maybe locking will help...]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/feed/</wfw:commentRss>
		</item>
		<item>
		<title>Game Idea: Cowboys and Indians</title>
		<link>http://gidden.net/tom/2007/03/07/cowboys-and-indians/</link>
		<comments>http://gidden.net/tom/2007/03/07/cowboys-and-indians/#comments</comments>
		<pubDate>Wed, 07 Mar 2007 23:31:32 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[cowboys-and-indians]]></category>

		<category><![CDATA[game-idea]]></category>

		<category><![CDATA[game-ideas]]></category>

		<category><![CDATA[rpg]]></category>

		<category><![CDATA[wild-west]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/03/07/cowboys-and-indians/</guid>
		<description><![CDATA[Through Digg, I found a site called My Game Ideas, where you can post (unsurprisingly) ideas for computer games and let others comment and rate them.  Anyway, this prompted me to post an idea I've been mulling over for a couple of days:  Cowboys and Indians meets GTA. UPDATE: Unfortunately, it looks like I failed to notice Red Dead Revolver, which looks to be a more sucky version of what I was thinking of.

My idea:
An open world third-person game with RPG elements in the mold of GTA:San Andreas, with a Wild West theme, done relatively stereotypically, but not comically.
Based on your actions, you become an outlaw, a sheriff, a cowboy, a trader, or an explorer, or a mixture of those roles. Possibly a parallel development thread in an Indian tribe, too.
Wanted level is permanent and only reduced by doing time or by compensating with good deeds: becoming a deputy or sheriff; "cleaning up the town"; foiling a robbery, etc. Being lynched is a serious risk.
Your actions also will affect the growth of the settlements you visit, with buildings being built or torn down while you're out of the area. Misbehavin' too much in one town may cause it to become a ghost town. Establishing a trading route, either directly, or by providing protection on the way, causes towns to grow.
Mini games and missions would include lassooing; herding of cattle; gunfight duelling; protection; escorting; bounty hunting; stagecoach and bank robbing; prospecting; mining; hunting; train robbing (and protection); building a posse; and so on.
The landscape could be largely procedurally generated, as there would be a lot of prairie and desert. It should be as large as possible.
"Vehicles" go from a decrepit burro through to "Silver" as in The Lone Ranger, along with the railroad, stagecoaches, wagon trains, etc. Concern for your trusty steed's hunger, thirst, fitness and health -- along with your own -- is critical.
Weapons would include muskets, six-shooters, shotguns, bow-and-arrow, bare knuckle fighting, whip, lassoo (operated by rhythmic rotation of the analog stick), and sticks of dynamite.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/03/07/cowboys-and-indians/feed/</wfw:commentRss>
		</item>
		<item>
		<title>LG Shine KE970: Everything Else</title>
		<link>http://gidden.net/tom/2007/01/25/lg-shine-ke970-everything-else/</link>
		<comments>http://gidden.net/tom/2007/01/25/lg-shine-ke970-everything-else/#comments</comments>
		<pubDate>Thu, 25 Jan 2007 14:47:44 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[6280]]></category>

		<category><![CDATA[6680]]></category>

		<category><![CDATA[camera-phone]]></category>

		<category><![CDATA[cameraphone]]></category>

		<category><![CDATA[Cellphone]]></category>

		<category><![CDATA[cellular]]></category>

		<category><![CDATA[gsm]]></category>

		<category><![CDATA[Hands-On]]></category>

		<category><![CDATA[KE970]]></category>

		<category><![CDATA[LG]]></category>

		<category><![CDATA[LG Shine: in-depth Review]]></category>

		<category><![CDATA[LGShine]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[Mobile-phone]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[nokia]]></category>

		<category><![CDATA[shine]]></category>

		<category><![CDATA[Shine-Phone]]></category>

		<category><![CDATA[Slide-Phone]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/01/25/lg-shine-ke970-everything-else/</guid>
		<description><![CDATA[Okay, I've covered the the physical aspects and the audio aspects, so now it's time to wrap it up by looking at the camera, the software and finally the phone-call-making bits of the LG Shine.

The Camera
In my experience, phone cameras are universally crap.  However, it looks like 2007 is the year that the manufacturers get their act together and start creating some decent picture-taking kit.
The Nokia N95 seems to be leading the field with a 5MP camera, and a gajillion other features such as GPS.  The LG Shine doesn't try to compete at this level, but they've managed to cram in a "Schneider Kreuznach certified" 2MP camera.
This doesn't immediately impress me, though.  My existing Nokia 6280 comes with two cameras:  one on the front for video calls, and a 2MP unit on the back for photos.  The Nokia 6680 I had before then used the same two-camera arrangement, with a 1.3MP camera on the back.  It also had the added bonus of a sliding lens cover to keep the dust out.  All four cameras were terrible... to the point that I just gave up trying to take photos with them, as I just got angry when I saw the results.  No matter how cool the impromptu subject was, I couldn't look past the streaky, grainy, unfocussed, blown-out images.  I ended up taping closed the 6680's lens cover so it would stop unlocking accidentally whenever I put the damn thing in my pocket.
So, how good is the Shine?  Much better.  Much, much better.
For a start, the camera actually focusses.  It's got manual focus, auto focus and macro.  A half-press on the shutter button triggers the auto-focus:  just like a "real" digital camera!
So, to get into the camera functions, you can either go through the Multimedia menu, or you can just hold down the shutter button on the side.  Once you're there, the live image appears, full-screen, and the whole interface turns sideways.
"Options" pulls up an overlay of settings menus as expected.  Using the scroll bar to navigate lets you adjust:

Shot mode: Macro, On, Off
Resolution: 320x240, 640x480, 1280x960, 1600x1200
Quality: Super fine, Fine, Normal
Flash: On, Off
Self timer: 10 seconds, 5 seconds, 3 seconds, Off
Save to: External, Phone
Multi shot: 6shot, 3shot, 1shot
Metering: Centred, Combined
Colour effect: Negation, Mono, Sepia, Colour
White balance: Fluorescent, Cloudy, Incandescent, Daylight, Auto
Shutter tone: Off, Tone 3, Tone 2, Tone 1
Reset settings: Yes, No

In addition, the exposure can be changed with the scroll bar from -2.0 to 2.0 in 1.0 increments, and zoomed gradually from x1 to x2 with the ends of the bar.
When ready, a half-press of the shutter button will focus and hopefully lock focus, and then a full-press will take the picture...
...a second later.  That's the Achilles Heel of this camera.  The shutter lag is baaad.  Disabling auto focus has no effect, and it's not an exposure thing either:  even in bright sunlight, it lags.  I tried reducing quality, resolution, changing metering, and everything else I could find.  No luck.
What makes this even worse is that compared to a dedicated digital camera, such as my Canon Powershot A75 or my Canon EOS 300D, it's a pretty lightweight unit, and with the positioning of the shutter, you don't get a particularly solid grip on the thing.  As a result, the picture you frame and the picture you take could be significantly different.
Now, shutter lag isn't a new thing.  All cameraphones I've used suffer from it.  Hell, most consumer digital cameras seem to suffer from it, or at least, used to suffer from it.  It's just a shame they didn't manage to fix it for this one.  I don't (particularly) mind if a camera takes a while to dump the image to storage after the shot has been taken, as long as it does actually take the shot when I want it to.
For now, I'd switch it to "Multi shot", which takes three or six photos in quick succession.  It still takes a second to get going, but once it does, it rattles through them at a fair rate.  Unfortunately, to do so, it reduces resolution to 640x480 (0.3 MP).
Moving on... image quality.
The pictures produced by the Shine are good.  Of course, not up to the quality of a good consumer dedicated camera with a proper big lens, but as good as those slimline units with small lenses you can get for about £100, I think.  It utterly thrashes the Nokia 6280 (and by implication, the even-worse 6680), as you can see from the pictures below.  There's only so much that can be done with a small lens as the light-gathering capability is limited.  So, a well-lit room or natural sunlight makes a big difference.


Nokia 6280
LG Shine


However, as far as I can tell from the photos my old boss used to get me to download from his phone for him, these things are often used to take pictures of drunken boobs (in more than one sense) in darkly-lit bars.  I haven't had the opportunity to take the Shine out to a bar to snap boobs, but I did test it in darker conditions.
Now, with the other cameraphones I've mentioned, this just results in technicolor streaking (of the bad kind).  Noise is rife, and the picture is barely visible.  Even in a relatively low-lit room at night, the streaks ruin it all.  It looks to me like the Shine doesn't suffer from this.  Sure, it has image noise at low light conditions, but with a lens small enough to fit in a phone this thin, it's a damn good effort.  Plus, the image noise isn't that unattractive.  It's more like blurry grain than typical multicolour digital speckles.
The thing I'm really pumped to see on this thing is the Macro (close-up) mode.  It's sad to admit, but I want to use my cameraphone mainly for taking pictures of whiteboards before I rub them out, and documenting things like where screws go before I take them out of the thing I'm disassembling.  I'd also use it to take pictures of business cards, serial numbers and other things that absolutely require Macro focussing.  The LG Shine brings it.  The Macro mode works.  It can focus within two inches before it starts getting blurry.
The flash is an odd one.  It actually operates more like a lamp, in that it doesn't actually flash.  Like other camera phones, it's actually just a dazzling white LED.  When the flash setting is on, the LED stays lit.  While this would run the battery down faster, I'd imagine, it does obviate the need for a red-eye mode.  It also means it'd come in handy in the event of a power cut.
I didn't really test the video camera capabilities, but I note that it can record clips at 176x144 resolution, with a subset of the still camera options.  You can also use it as a voice recorder.
One other minor issue which shouldn't make a blind bit of difference to anyone but a geek like me is the fact that the Shine doesn't include EXIF metadata with photos taken by it.  What this means is that on, say, Flickr, you can't see what photographic settings were used for the photo, or even what kind of camera took it.  This is a bit sloppy on the part of LG, as far as I'm concerned.
To conclude, I think they've done a great job on the camera, especially considering the size of the phone.  It doesn't compare too badly to a dedicated digital camera of a similar size and weight, and it has the added bonus of actually being a phone too.
There are two major flaws, though:  firstly, the shutter lag I mentioned, which they may be able to correct in software.  Secondly, the camera function suffers a great deal from the screen visibility problems I mentioned in my previous post.  In outdoor daylight conditions, the screen is barely legible, and without an optical viewfinder, it's impossible to frame the shot.  By sheer luck, I managed to take the picture on the right, in bright sunlight using macro mode, but I haven't shown you the many other shots that didn't turn out purely because I couldn't see what was being taken.  Unfortunately, they can't fix this problem.  The mirror-like screen is one of the key selling points of this phone, and is admittedly beautiful.  However, it's got disadvantages, and this is one of them.
Finally, the rest of the features
I've put off reviewing the more mundane parts of the LG Shine, such as actually making calls, even though they're the most critical parts of it.  I think this is because making calls on a mobile is no longer a big deal.  Most phones are much of a muchness, with similar call quality and adequate battery life.
To be honest, I can't really judge battery life too well on this thing.  I'm used to power-hungry 3G phones, and I also haven't been using this phone to make more than a couple of test calls.  On the other hand, I've been playing with a lot of features.  As a result, the fact that I've charged it three times in the past five days is of absolutely no value at all.  What I can tell you is that the unit comes with a Lithium Ion 800mAh battery.
Call quality is fine.  Meh.  I just can't think of anything else to say on that subject.  Sorry.
The software, on the other hand, I can rabbit on about for ages.
The user interface is good, with very well-designed graphics and exceptionally clear text.  I don't feel the aching need to install some wacky theme or skin on this unit, as the graphics are neat and pretty.  It comes with some stock wallpapers and animations (Flash SWF files, no less!), but they're not incredibly inspiring.  It's interesting to note that most of them are stereotypically "girly" with flowers and petals and things, reflecting what seems to be the target market of the Shine.  There is, however, a manly "car" animation, including sparkly highlights for those of us macho men who still appreciate good design.
The menus are well laid out, with a better overall organisation than that on recent Nokia phones.  However, it's still fairly conservative, with the standard hierarchies in place, such as "Profiles" (activate / personalise), "Settings" and "Call History".  It's just not a big deal.  As well as being able to navigate with the scroll bar, almost all options have a digit next to them for navigating with the keypad.  Even with the smooth keypad, I still find this nicer and faster to use than the scroll bar.
The whole phone interface is fairly responsive, with no major lags involved.  It's not instant, but it's a lot better than the second-long pauses some of the Series 60 Nokias suffer from.
The call-making interface is fairly standard, but still well thought out.  Manually dialling is neat, with big colourful digits appearing in one of four different animated styles.  I've chosen "digital style", giving me seven-segment "LCD" style digits.  Accidental calling is quick to cancel, which is better than the Nokias.  On the occasion that I've misdialled, or accidentally pressed Green on a contact, the Nokias have failed to drop the call until the line starts ringing.  If that was an accidental emergency call, I'd be in trouble.  The Shine drops the call as soon as the "drop call" button is pressed.
Text messaging is organised and although it's let down, again, by the lack of tactility of the flat keypad, it's still quick to type stuff.  The predictive text is done right, and I must highlight the good choice of symbol selection they've gone with:  pressing "*" brings up a list of symbols, each with an assigned keypad button.  So, by pressing *9 and then "OK", I get "@".  Using the scroll bar reveals more symbols, including currency, and for some odd reason, some (but not all) Greek letters.  This interface is far better than the painful repeated button-pushes mechanism used by Nokia, which often results in overshooting the one you want.
The contact management function is well done, with ringtone choice and photo for all contacts.  I haven't found any Voice Tagging feature yet, but I never use them anyway.  The phone also includes the ubiquitous Calendar, Alarm Clock and Calculator, along with Stop Watch, Memo, Unit Converter and World Clock.  These are clean and well-implemented, including a full scientific mode for the Calculator.  As I mentioned the other day, the Alarm Clock is a little limited, with no capability to use an MP3 for the alert sound.  Instead, a set of MIDI-esque instrumental tunes are offered.
It looks like they've really gone to town on the World Clock, though.  A full animated 3D Planet Earth is shown, pointing to the various cities.  It's very cute, but a little cumbersome to use, and there doesn't seem to be an option to remember more than one city.  Instead, you can select your "Home City", which has the side-effect of reinterpreting the phone's current time zone.  This means you can't keep local time, while still keeping track of whether it's the middle of the night back home.  I think if I needed this function, I'd start looking for a downloadable application to do the same thing in a more straightforward way.
As I mentioned the other day, the UI is improved by jaunty little sound effects, which haven't become annoying yet.  It's a fine line, but they've leaned marginally on the side of taste, which is good to see.
The Shine includes Java capability, and includes a couple of games.  One is a fairly mediocre "Puzzle Bobble" clone, called "Bubble Soccer".  I'm a huge fan of Puzzle Bobble, so I was very pleased to find it included.  Sadly, using the scroll bar for controlling it just isn't good enough.  The other game is "Fishing".  Since the tutorial is about thirty pages long, and ridiculously complex, I got bored and just gave it a go, and got absolutely nowhere.  These games aren't really going to win any awards, and I hope LG will ship better games on release.
Connectivity is fairly simple.  The Shine includes Bluetooth and also an included USB cable.  When connected via USB, the phone ceases to function as a phone (shutting off all wireless connectivity), starts charging the battery, and just becomes a removable drive.  Since this pre-release phone didn't come with any software I could only use it as a dumb drive, so no interesting syncing capabilities to report.  As expected, the Shine is not supported by Apple's iSync software on the Mac, so I couldn't sync my contacts or calendars over.  This isn't unexpected, though.  Apple aren't particularly good at supporting phones even when they've been on sale for months, so failing to support a pre-release phone is par for the course.
I'm not particularly happy with the charging mechanism.  It involves plugging the cable into that flimsy little port, with no option for a cradle or desk stand.  I can't see any way that an in-car kit would work, either.  A good thing I don't drive, I guess!
So, to sum up...
This phone isn't perfect, but it's the best I've come across so far.  There's only one reason I wouldn't buy this phone right now, and it's that it's a 2G phone.  I'm subscribed to Three UK, which is a 3G-only network.  If I'd got this phone three months ago while I was still on contract with Orange UK, it wouldn't have been an issue.  I've been told that the 3G version of this phone is due out shortly, and I'd love to get my hands on one.  It would almost certainly become my main mobile... that is, assuming I don't get given a pre-release 3G-supporting unlocked Apple iPhone, which I don't think is likely.  I wouldn't even give my old crappy Nokia to a family member: I love them too much.
So, what don't I like about this phone?

Only 2G, but the 3G version should be out quite soon.
Only 50MB of memory.  3G version has 1GB.
Screen is illegible in daylight.
Ringtone/Message tone volume too low:  allegedly fixed in release.
No real choice of message or alarm tones, or sound-effect theme.
Flat, non-tactile keypad: easy to miskey.
Scrollbar is sluggish and fiddly.
Flimsy side port cover.
No standard headphone socket.
Included headset/remote is crummy.
Basic music-playing UI.
Shutter lag.
No EXIF data on photos.
No calling while on USB.
No iSync support... yet.

What do I like about this phone?  Everything else.
The bold entries are things that are significant enough for me to think twice about buying one, but to tell the truth, they wouldn't stop me.  I'd even spend a day or so either hacking up a perl script to sync my contacts, or do it the hard way by individually Bluetoothing the contacts across.
This phone is just that good.
The rest of you lot can get it when it launches in the UK on February 7th, but you're not having this one.  It's my precious.  I wuv this phone.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/01/25/lg-shine-ke970-everything-else/feed/</wfw:commentRss>
		</item>
		<item>
		<title>LG Shine KE970: Sound and Music</title>
		<link>http://gidden.net/tom/2007/01/24/lg-shine-ke970-sound-and-music/</link>
		<comments>http://gidden.net/tom/2007/01/24/lg-shine-ke970-sound-and-music/#comments</comments>
		<pubDate>Wed, 24 Jan 2007 14:12:41 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
		
		<category><![CDATA[General]]></category>

		<category><![CDATA[Reviews]]></category>

		<category><![CDATA[Cellphone]]></category>

		<category><![CDATA[cellular]]></category>

		<category><![CDATA[gsm]]></category>

		<category><![CDATA[Hands-On]]></category>

		<category><![CDATA[KE970]]></category>

		<category><![CDATA[LG]]></category>

		<category><![CDATA[LG Shine: in-depth Review]]></category>

		<category><![CDATA[LGShine]]></category>

		<category><![CDATA[mobile]]></category>

		<category><![CDATA[Mobile-phone]]></category>

		<category><![CDATA[mobile-phones]]></category>

		<category><![CDATA[ringtone]]></category>

		<category><![CDATA[shine]]></category>

		<category><![CDATA[Shine-Phone]]></category>

		<category><![CDATA[Slide-Phone]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/01/24/lg-shine-ke970-sound-and-music/</guid>
		<description><![CDATA[On Monday, I covered the external hardware aspects of the LG Shine I've been loaned.  For the time being, I'm going to skip the actual phone features, and play with the sound effects, ringtones and music features it offers instead.

MP3 Playback
First thing to do is get some music onto the phone.  My track of choice for this test is "Indra" by Thievery Corporation.  While this particular model only includes about 45MB of usable space for music, photos and other stuff, it does include a microSD slot for adding more memory.  An extra 2GB will set you back about &#163;30 right now.
Transferring by Bluetooth wasn't such a great idea: probably thanks to my wimpy little Bluetooth 1.1 dongle, it was taking far too long to transfer the 9MB MP3 file.  So, I hoiked out the USB cable that came with the phone.  When connected, the phone shuts off its GSM functions, thereby ceasing to be a functioning mobile phone.  It then appears as a removable drive on my Mac, presenting a list of folders, such as "Documents", "Images", "Videos" and "Sounds".
Over USB, the transfer is significantly quicker, although still not instant.  If I was using a microSD card rather than the phone's built-in memory, I'd probably want to use a proper USB card reader, rather than connecting to the phone itself.  This isn't particularly unusual for flash-based peripherals: my big, expensive dSLR camera takes hours to transfer files over USB.
T