<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; apple</title>
	<atom:link href="http://gidden.net/tom/tag/apple/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Sun, 01 May 2011 10:35:37 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>Meditations on #Locationgate</title>
		<link>http://gidden.net/tom/2011/04/26/meditations-on-locationgate/</link>
		<comments>http://gidden.net/tom/2011/04/26/meditations-on-locationgate/#comments</comments>
		<pubDate>Tue, 26 Apr 2011 14:48:08 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[Cellphone]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[gps]]></category>
		<category><![CDATA[gsm]]></category>
		<category><![CDATA[ios]]></category>
		<category><![CDATA[iphone]]></category>
		<category><![CDATA[itunes]]></category>
		<category><![CDATA[location]]></category>
		<category><![CDATA[mobile]]></category>
		<category><![CDATA[Mobile-phone]]></category>
		<category><![CDATA[mobile-phones]]></category>
		<category><![CDATA[privacy]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=171</guid>
		<description><![CDATA[Over the past week or so there's been a furore about location tracking in iOS. While it initially appeared to be a fresh discovery of machiavellian intrusion, the story's a bit more complicated than that.

The mainstream media caught wind of this story as a result of a blog post by Alasdair Allan and Pete Warden on April 20. They released an open-source app for grabbing the data from iTunes's iOS device backup files and displaying it on a map. It's a very neat hack, but it's really just taking a simple SQLite database called "consolidated.db" and doing some trivial queries on it.
Alex Levinson points out that this is not new information, though. Allan and Warden do get credit for producing pictures, though: without which the mainstream media would never understand or care.
Levinson also makes some other points, but I'm not sure I'm in complete agreement. For a start, the location data can be remarkably precise. The general belief is that the device is either storing the cell locations rather than the device locations -- a subtle but important distinction -- or it's storing the estimation of the device location based on the known cell location. I'm not sure. However, I've done what pretty much every geek has done this week and imported and converted the data into KML and a variety of other formats, and I've found (in the "CellLocationLocal" table) a row that is apparently the deduced location of an Orange UK Cell Tower (MCC 234, MNC 33, LAC 3103) in my front garden. (Suffice to say, it's not there.)
Will Clarke points out a response from Apple to an inquiry by Reps. Edward Markey (D-Mass.) and Joe Barton (R-Texas). I do vaguely remember something about this new location strategy last year, although I'm not sure whether it was from this or some of the developer information. At the time, I dismissed it, without considering the deeper ramifications.
To understand what's going on, you have to know a little history.
The original iPhone didn't have a GPS chip. Location services used two sources of information from the vicinity: finding nearby WiFi networks and nearby cell towers, and looking up their location with a service run by Skyhook and a separate service run by Google. Skyhook initially seeded their database by basically wardriving the USA, Europe and Japan, and then also accepted submissions from users. Google, presumably, picked up their data using their own wardrive, piggybacked on their Street View cars (and we know how that turned out for them!)
The system worked adequately for looking up nearby restaurants and the like, but not for navigation. iPhone 3G and above include a GPS chip, but even so, WiFi and GSM location is quicker, more power efficient, and better performing indoors and in urban environments. However, it requires Internet coverage to do the lookup. Caching is obviously an option, though.
When iOS 3.2 came out, the situation changed slightly: rather than using third-party databases -- one of which was run by their friend-turned-archenemy Google -- they chose to replace the lookup service with their own.
Here's the clever bit, though. Rather than wardriving the planet, they realised that they had about 40 million data collection devices already in the field: the iPhone itself. So now it's all done by crowdsourcing: the lookup goes both ways now. When your iPhone uses Apple to lookup the known location of WiFi and GSM sources, it can also supply its own GPS data back to Apple for future lookups by other users. F-Secure reports that the batches occur twice a day.
Technically, this is a fantastic idea. Unlike a wardriven service like Skyhook, this one is continually refreshed and expanded. It makes perfect sense. It's a very neat trick.
However, it's mindboggling that Apple thought this was something they could get away with without a clear opt-in by users. I'm sure in some countries, it's even a criminal act. I suspect Germany is one of those countries.
That's not to say that it's a secret: Apple did disclose the service in the updated Terms and Conditions of iOS which I'm sure everyone read(!), the Apple Privacy Policy and a misleading opt-in dialogue box talking about "anonymous diagnostic and usage information". However, it's not reasonable to expect every user to fully understand the connotations of what's going on. At no point does it say anything as obvious as "Oh, by the way, this means your device is continuously tracking its location."
So, why is this happening? It's not just the crowdsourcing, as that doesn't need to be stored once it's been done. Is it caching? It makes sense to cache the location data to an extent, but failing to clear the cache is a bit silly.
Of course, another possibility is that Steve Jobs is -- in fact -- The Dark Knight himself.

This would explain the leave of absence, I guess.
Forgetting the inevitable lawsuits and legal inquiries, did it not occur to Apple that there would be an almighty shitstorm if/when this became public knowledge? If they'd made a big deal of it and had Steve Jobs actually rave in a keynote about how their location database was constantly updated with your assistance, this wouldn't have been a big deal: a few contrarians and Android fans would have whined about it and how they'd never buy Apple again, but on the whole, it would have died down. There certainly would have been far less opportunity for legislators to bollock Apple for it.
This is Apple: a company that has meetings arguing over individual pixels on their UI designs, and yet it didn't occur to anyone to ask whether this whole scheme was morally right, legally right or diplomatically right? It didn't occur to them that it would actively turn customers against them? Are they really that boneheaded?
For me, the question is, do I care? I don't really care whether people will know roughly where I've been, and looking at previously-undiscovered maps of my Orlando vacation (Kennedy Space Center and Walt Disney World), a trip to Ahmedabad and my various jaunts around the UK has been pretty cool. I can, however, understand why others are upset about this, but I think it's mainly due to the surprise and lack of choice, rather than the actual tracking itself: if you knew it was happening, would it really be such a problem?]]></description>
		<wfw:commentRss>http://gidden.net/tom/2011/04/26/meditations-on-locationgate/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Removing Ping from iTunes 10.0.1 (and 10.2.2)</title>
		<link>http://gidden.net/tom/2010/09/25/removing-ping-from-itunes-10-0-1/</link>
		<comments>http://gidden.net/tom/2010/09/25/removing-ping-from-itunes-10-0-1/#comments</comments>
		<pubDate>Sat, 25 Sep 2010 13:37:54 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[itunes]]></category>
		<category><![CDATA[ping]]></category>
		<category><![CDATA[terminal]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=117</guid>
		<description><![CDATA[If you're a fan of Apple's new Ping service, then you'll be happy to see the new Ping Sidebar and Ping buttons appear when you install the new 10.0.1 update of iTunes.  However, some of us think it all worked perfectly well before Apple decided to hop on the Social bandwagon.

Unfortunately, Apple have chosen to make these new features default and apparently mandatory in the new release.  There's no user interface to disable Ping completely, and certainly no user interface to restore the old behaviour.  It turns out that there are some hidden settings though.
Within five minutes of getting the software update, I was already hunting through the iTunes application code for some magic words to tap in to restore the status quo... and my sanity.  I quickly found a number of candidates.
Now, to set these, you'll have to go under the hood, so to speak.  If you're a techie, this shouldn't be a problem, but if you haven't done this kind of stuff before, I must stress that there's an slight element of risk here:  one that's present whenever you open Terminal.  If you're not comfortable with that risk, turn back now and learn to love the Ping.  If you are willing to proceed, make sure you type exactly as I say, taking care to make sure capitalization, punctuation and spelling is correct.
To reiterate: DO THIS AT YOUR OWN RISK.  Don't come whining if you break something.
Also, these instructions apply to Mac OS X only.  I'm sure there are similar settings for the Windows version of iTunes, but I've got no clue how to apply them, and frankly no desire to either.  If you know, please comment on this post for the benefit of others. 
Update: thanks to commenter Nikola and the original Apple forums poster
David Wolf1, here are the equivalent instructions for Windows.

Firstly, quit iTunes.  I'm not sure if this is necessary, but it's a sensible move. You'll need to restart iTunes anyway before this stuff takes effect, and iTunes could undo your tweaks in the process.  Secondly, start Terminal.app.  This is an application that should be in the Utilities folder of your main Applications folder.
This should pop up a terminal window which looks something like this:

Now, type this into that window:
defaults write com.apple.iTunes disablePingSidebar 1
...and hit Enter.  You shouldn't get a response, except for the command prompt repeated back to you (as below). If you get an error, I wouldn't recommending proceeding, but you can check and try again.  The '1' at the end is a one, not a lowercase L.

That should disable the Ping sidebar.  Now for the buttons.
defaults write com.apple.iTunes hide-ping-dropdown 1
That should remove the Ping buttons.  However, the old-style arrow buttons need another setting to restore them:
defaults write com.apple.iTunes show-store-link-arrows 1
That one might sound familiar if you've done stuff like this to a previous version of iTunes... however, it's not exactly the same.  The old setting was "show-store-arrow-links", and it defaulted to 1 (yes).  The new "show-store-link-arrows" setting defaults to 0 (no), presumably to make way for the Ping buttons.  I can only imagine they tweaked the wording just so the old setting didn't confuse the issue (!)
Finally, might I also suggest the following:
defaults write com.apple.iTunes invertStoreLinks 1
This setting switches the default behaviour of the arrow links.  By default (well, by default in iTunes 10.0.0 and before) the arrows would send the user to the corresponding page in the iTunes Store, but you could also hold down Opt and click to be redirected to the corresponding list in your own library.  In my opinion, this was an incredibly useful feature:  you can navigate through your own library so quickly.  The "invertStoreLinks" setting makes this the default, so you just click to navigate.  Holding down Opt while clicking will take you to the store.   I wholeheartedly believe that it was the UI designers' original plan, but Apple's synergistic greed hijacked the arrow for the purpose of hocking more media.

Anyway, I digress.  Once you've set the settings you want, start iTunes, and all should be well.  You can (and should) quit Terminal at this point.
Now, to reset it all to Apple's defaults... you can either do the same lines as above but replacing '1' with '0', or you can delete the settings by changing "write" to "delete" and removing the 1 from the end:
defaults delete com.apple.iTunes disablePingSidebar
defaults delete com.apple.iTunes hide-ping-dropdown
defaults delete com.apple.iTunes show-store-link-arrows
defaults delete com.apple.iTunes invertStoreLinks
(after quitting iTunes, of course)
That should get things back to "normal" and Ping will return in all its glory.  Best of luck to you.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2010/09/25/removing-ping-from-itunes-10-0-1/feed/</wfw:commentRss>
		<slash:comments>84</slash:comments>
		</item>
		<item>
		<title>Extracting pages from PDFs on OS X</title>
		<link>http://gidden.net/tom/2009/01/27/extract-pdf-pages/</link>
		<comments>http://gidden.net/tom/2009/01/27/extract-pdf-pages/#comments</comments>
		<pubDate>Tue, 27 Jan 2009 16:54:18 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[pdf]]></category>
		<category><![CDATA[xcode]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=66</guid>
		<description><![CDATA[I need to slice and dice a lot of images from a number of multi-page PDF files, but I don't happen to have the right bit of ImageMagick installed on my MacBook Pro.  Instead, I took the slightly longer route of writing a utility to do it.

Mac OS X comes with a neat little utility called "sips" which can be used to transcode images and PDFs.  However, I haven't found any way of telling it to choose a particular page of a PDF file.  I've googled a bit on the subject, and couldn't find anything.
Of course, I could manually extract the pages using "Preview" but there's no fun in that.
ImageMagick would also usually do the trick, but I haven't installed GhostScript as part of ImageMagick, so PDF file support is fairly broken.
Anyway, extracting pages should be a fairly simple thing to do, considering OS X's drawing layer is very closely related to PDF.
I've put the code in my Subversion repository here, so you can extract the XCode project by running:
svn co http://gidden.net/svn/ExtractPagesFromPDF/
at the command-line.
The code is very basic, and doesn't handle encrypted PDFs or anything special, so treat it as "sample code".  Also, I'm no XCode/Objective-C/CoreGraphics expert by any means, so this may not be the best way of doing it!  No warranties, blah blah blah.  Use at will and at your own risk.
How to use:

Build the project in XCode
Get the executable file, "ExtractPagesFromPDF" and put it somewhere in your $PATH
ExtractPagesFromPDF myBigDocument.pdf
The subpages should be created in the current directory, with the format %04d.pdf (ie. 0001.pdf, 0002.pdf, ...).  If you have files with those names already, move them out of the way!

Now that's written, I can now use "sips", "ImageMagick", etc. to continue the processing I need to do for the project.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2009/01/27/extract-pdf-pages/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<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>
		<slash:comments>3</slash:comments>
	
		<series:name><![CDATA[Leaving mobile phone company "X" for "Y"]]></series:name>
	</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>
		<slash:comments>4</slash:comments>
	
		<series:name><![CDATA[Elgato EyeTV reviews]]></series:name>
	</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>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>iPhoto, Flickr and EXIF munging using Perl</title>
		<link>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</link>
		<comments>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/#comments</comments>
		<pubDate>Wed, 27 Dec 2006 18:21:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[albumdata.xml]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[cocoa]]></category>
		<category><![CDATA[exif]]></category>
		<category><![CDATA[flickr]]></category>
		<category><![CDATA[flickr::api]]></category>
		<category><![CDATA[geocoding]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[geotagging]]></category>
		<category><![CDATA[iphoto]]></category>
		<category><![CDATA[iptc]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[mac::iphoto]]></category>
		<category><![CDATA[metadata]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[picasa]]></category>
		<category><![CDATA[scripting]]></category>
		<category><![CDATA[xmp]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</guid>
		<description><![CDATA[EXIF/IPTC/XMP tagging of GPS coordinates, folksonomy tags, and other goodness is a nice idea, but unfortunately, iPhoto and Flickr don't play too well together.  Couple this with the fact that any decent support those products now have is not included for photos already imported into them.  So, here are some notes resulting from some experimentation, along with the Perl code I wrote along the way.

(Note: for the rest of this post, I'll refer to all metadata stored in the image file itself such as EXIF, IPTC, XMP, etc. as "EXIF" data.  This isn't strictly correct.  However, using the term "metadata" could be confused with such data held in other files, such as iPhoto's own database.)
For Christmas, my dad bought my mum a decent photo printer: the Canon PIXMA iP5200R.  Very nice piece of kit, with good printouts, and most importantly, easy setup, with no CUPS and Windows -v- Mac issues.  Anyway, as an upshot of this, my dad wants some of my photos for building a Picasa library for her to print stuff from.  Specifically, the photos from the Caribbean holiday we had earlier in the year.
I've been playing with Picasa a bit, and I must say I love it.  It's what iPhoto should be.  It's a good deal faster for a start.  That's comparing my iBook G4 1GHz against my mum's Compaq Deskpro Pentium III 733MHz, which is a few years older.  Secondly, it doesn't use a horrible non-scalable monolithic database like iPhoto does.  Thirdly, it seems to deal with metadata a bit more sensibly.
On the downside, neither iPhoto or Picasa handle collaboration functions very well.  Both have publishing functions, and iPhoto has a read-only "sharing" function, but I mean the true sharing of photo libraries.  My mum and dad have separate computers, but they share a camera, so it would be incredibly useful to have a shared photo library which either could use.  On this count, Picasa wins slightly, because although it has no true sharing ability, there doesn't seem to be anything wrong with two copies of Picasa working on the same directory on a shared drive.  I'm not sure how it would handle conflicts though, due to the lack of locking.  For now, I'll advise my parents not to run it at the same time.
I usually manage all of my photos in iPhoto.  However, due to the lack of decent keywording and other metadata in iPhoto, I ended up adding a lot of metadata in Flickr instead.  As a result, my iPhoto library is woefully out-of-date with my Flickr library, even though it's far more complete as I only upload a subset of my photos to Flickr.  I specifically want to extract Flickr tags back into the files themselves, and ideally rip the Geotagging information I added within Flickr.
While iPhoto is drastically improved by Keyword Assistant, it doesn't store the keywords (read: tags) in EXIF form, but in its own database.  During this investigation I discovered that iPhoto does import keywords from EXIF, and also Geotagging info.  The fact that it doesn't manage EXIF is a fairly annoying flaw, and one that I hope they'll be fixing.  I've heard that Microsoft Vista now does sensible things with EXIF.  iPhoto is, quite frankly, falling far behind other solutions at this point, and I hope next month will bring a new iLife with an improved iPhoto.
So, I had a good look around the 'net for some utilities to try to clear up this mess.  I've had a play with things like Cal Henderson's Flickr::API and Dmytro Kovalov's Mac::iPhoto before, and they're not particularly mature.  Incidentally, Mac::iPhoto also seems currently broken.
Others have attempted using Applescripts.  The ones I found around the 'net are far too slow to cope with the ~8000 photo collection I have.  This is probably due to the sucky design and/or implementation of Apple Events in MacOS.
Instead, I've had a play with PerlObjCBridge, or whatever Apple's calling it.  In Perl, it's "use Foundation;".  This gives access to the Cocoa API within OS X, which I figure is probably the fastest way to manipulate Property Lists.  Since iPhoto stores at least a backup of the database in XML form (specifically Property List form) as "AlbumData.xml", we can use this to cross-reference the data.
The most critical link between my Flickr and iPhoto collection is missing.  This would be a link between each individual photo and its alter ego in the two different collections.  Since filenames aren't necessarily complete or preserved by either iPhoto or Flickr, this is relatively difficult to establish.
I've found that a reasonably good connection is between image creation time/dates.  By matching the EXIF timestamp data within the file stored by iPhoto with the EXIF data extracted from Flickr, you can get a reasonably good correlation.  At this point, it would be a nice idea to shove the Flickr URL for the image into the local EXIF data and get iPhoto to read it.  From then on, there would be an established link.
Well, I got about as far as adding the URL, tags and geocoding to the image, but I gave up when it came to getting iPhoto to read it.  There is a relatively obscure "rebuild" function in iPhoto, triggered by holding down Cmd and Opt while starting iPhoto.  This allows rebuilding of thumbnails and the binary databases (presumably) from the XML.  Unfortunately, it doesn't seem to reread the images for new metadata.  I think this would require actual modification of the AlbumData.xml file to work, which sounds like a far bigger job.
In the meantime, this proves that such a script is feasible, albeit painful.  At the moment, this is a run-once script, so it's not much use for regular usage.
SOURCE CODE:  I am supplying this code freely with the understanding that there is no warranty or guarantee.  Also, I'll go as far as to say that incorrect usage could quite easily delete your photos, destroy your Flickr account, upset Flickr, and kill your pets.  DO NOT USE THIS CODE UNLESS YOU UNDERSTAND IT COMPLETELY AND ARE WILLING TO TAKE RESPONSIBILITY FOR ANYTHING GOING WRONG.  For more details, read the README file.
The most recent version can be obtained from my Subversion repository: iphoto_flickr_exif_munge/.
I also apologise for the quality of some of the code.  It's far more experimental than I'd usually want to release, but I think it might be of use to someone like me in a similar situation.  Rather than just throwing it into the depths of my hard drive and forgetting it, I figure it's probably worth blogging.
My conclusion to all of this is that I really need to get my iBook replaced with something good enough to run Aperture or Lightroom, and then reimport the whole bloody lot.  Painful, to say the least.  I'm also hoping that Google get around to writing Picasa for the Mac.  I think I'd prefer it in the long term.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Mac Flight Tracker widget timezone bug</title>
		<link>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</link>
		<comments>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/#comments</comments>
		<pubDate>Thu, 10 Aug 2006 20:54:07 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[bdt]]></category>
		<category><![CDATA[bst]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[dashboard]]></category>
		<category><![CDATA[flight-tracker]]></category>
		<category><![CDATA[flighttracker]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[nsdate]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[os_x]]></category>
		<category><![CDATA[tiger]]></category>
		<category><![CDATA[timezone]]></category>
		<category><![CDATA[widget]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</guid>
		<description><![CDATA[The Flight Tracker dashboard widget that comes with Mac OS X 10.4 (Tiger) seems to have a fairly major bug.  However, this bug seems to be the result of something quite obscure to do with timezones, and it only seems to manifest itself in the UK during the summer.

I've noticed this problem a few times:  specifically whenever any one of my close friends or family members flies anywhere.  This time, my mother is on her way back from San Diego to Bristol via Newark.  Thanks to the incredibly annoying terrorist attack attempt today, my dad and I were understandably concerned about flight delays, so I pulled up the Flight Tracker.  Unfortunately, the information seems completely wrong.
Turns out, the minutes are right but the hours don't relate to any of the relevant timezones.
Anyway, a little background.  Here in the UK, we have two main time scenarios:  firstly GMT, which is for all intents and purposes, UTC.  We also use BST:  "British Summer Time" which is UTC+1h, and kicks in for archaic agrarian reasons and the "Think of the children!" brigade who are convinced it'll stop traffic accidents.
While the rest of OS X seems okay and correctly uses BST, Apple's Mail.app has always strangely listed incoming mail as being sent relative to "BDT", which comes out as "British Daylight Time", which is fairly meaningless as there's no such thing.  The times are correct, but they just have the wrong abbreviation afterwards.  On researching it, this seems to be the result of bad data from the Unicode people which might have made its way into NSDate.  Anyway, it's usually just a cosmetic thing, and of little or no consequence.
I believe, however, that it's the cause of the Flight Tracker widget's problems.  To test this, I altered the widget to display the timezone, by replacing the bit in FlightTracker.js, in function formatDateForDisplay() that says
var timeStr = date.toLocaleTimeString("short");
with
var timeStr = date.toLocaleTimeString("long");
This reveals that the times are supposedly in "BDT".  I believe this might be the problem.  I think something is reinterpreting this as "Brazilian Daylight Time", which would explain the weird offsets.  I think JavascriptCore or something is referring to the same bad data as Mail.app, probably via NSDate.  I'm not a Safari hacker, and I haven't really investigated that far, so I'm not sure where the problem is.
Looking a bit deeper into FlightTracker.js, I'm not really surprised there's a problem.  The timezone calculation code is fairly messy, with comments such as:
// We're going to be stupid and hard coded about parsing the server provided date strings for now
// ??? for some reason parseInt returns 0 on this but parsefloat works ???
and
// here we do proper handling of the timezone offsets.
// We enter everything in pretending it's UTC time
// and then we convert it to miliseconds since 1970,
// add the timezone offset in miliseconds to it
// and then set this as the new UTC time
There seems to be some string hacking going on at several places to decode the data sent from FlyteComm.  The original data is reasonably well structured, with the timezone offsets being given correctly as -0700 and +0100, which presumably indicate that the times are given as local times of the departure/arrival locations, as per normal for the airline industry.
I'm not completely sure what's going on, as I'm not really set up to debug someone else's widget, especially one with weird custom controls, and barely any code comments.  It's obvious to me that the widget isn't particularly well written, and is one of those things that "just works".  It was probably hacked up for fun by a Dashboard developer, and then fasttracked to the nearest Steve Jobs keynote rehearsal.  As Steve Jobs's Dashboard demos tend to be done at MWSF and WWDC, I doubt this problem has ever really been seen at Apple.  I bet if it was a problem with Pacific Daylight Time being misinterpreted, it'd be fixed immediately!  I've done a little bit of googling, and it looks like the BDT bug has already been submitted to Apple (several times), and it's still there.
When I get a chance, I may try to debug this one further, and perhaps rewrite FlightTracker's timezone code properly using the correct offsets rather than performing nasty magic using getLocaleTimeString().
What I would prefer is that the timezone of each time is given next to the time.  Ideally, they should toggle-on-click or slowly fade between local times (to the flight) and local times to the machine, and possibly relative times ("1 hour ago", "in 53 minutes", etc.)  That would make the tool a lot more intuitive anyway.  I'd rather not reinvent the whole widget, as in all other ways, the widget's really not too bad.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/feed/</wfw:commentRss>
		<slash:comments>18</slash:comments>
		</item>
	</channel>
</rss>

