My iTunes music collection has over 1400 albums in it (no doubt plenty of people have more, but still, that’s quite a lot of music).
A couple of years ago I decided to re-encoded all my CDs as Apple Lossless, since the physical discs were going into storage and I wasn’t sure when I’d see them again.
I store my collection on a mac mini, which is my media server. However, I also had a copy on my laptop, which I kept as AAC 256k, to save space (and because, frankly, it’s hard to tell the difference).
I like using the meta data tags properly, and I hate it when people abuse the Album tag to indicate what disc it is (by adding “[Disc 1]” on the end), when they mark an album as “Compilation” when it’s a collection of songs by the same artist (for me that tag is only supposed to be used to group together tracks by different artists), or when they use the Artist tag to name check collaborators (by adding “feat. Joe Blogs” or whatever), so you end up with one album scattered across multiple artists (if you’re going to do that, use the Album Artist tag to unify the album under the main artist).
Over the time that I’d built up the collection, I had spent a lot of time editing the meta data to get it into the format I wanted it. Unfortunately, re-encoding everything undid a lot of this work, and left me with quite a few duplicates - some with my “correct” meta data, some with the rubbish tags from the internet.
I managed to clean up a lot of the problems on the mini, but of course that didn’t fix the laptop. Worse, thanks to iTunes match, the problems started to multiply again. iTunes Match on the mini has become confused on multiple occasions and “forgotten” me, so I’ve had to add the entire collection to it again. At which point it started adding duplicate AAC copies of every album where I’d edited the meta data.
I guess that this is because it had matched different encodings of the same tracks on different machines, in some cases with different meta data. The upshot is that now on my mini I’ve ended up with two copies of a lot of stuff, with both the correct and the incorrect metadata - and my iTunes match collection is now in an almost unbearable mess as a result.
I try to remove the duplicate, but they’re not always easy to spot unless I fix the meta data problems first, because they get filed in different places. I attempt to delete these duplicates from the cloud at the same time, but I’m quite scared that I’ll end up removing the only copy of something from the cloud too, by accident.
It seems to me that the root of this problem is that there’s no ‘authoritative’ place to view your match collection as it exists in the cloud. That and the fact that match seems to take the approach of avoiding touching your meta data whenever possible - which sounds sensible but isn’t if you end up with the sort of mess I’ve got.
What I badly need is a way to view the collection on the web, remove duplicates, clean up meta data, and then sync these changes down onto all my machines. I’m really not entirely sure how it deals with meta data changes right now - I suspect that it basically does nothing, which means that if you ever re-sync your collection, you end up with duplicates again.
For now, things are so messy that what I’d really like to do is delete everything from all but one machine and from the cloud, and start again. Except that I don’t really trust that everything that needs to be stored in the cloud is, and that it’s in the correct format, with the correct data, and that deleting it all from most places wouldn’t end up with me losing stuff.
In a word: “aaaaaaaarrrrrghhhh!”.
I like this post by Matt Gemmell on how to manage your email.
He describes pretty much what I’ve been doing for the last few years.
I’m not as good as I should be about replying quickly to the people who do matter, but I’m considerably better than I used to be since I started being more ruthless about the others.
The only thing I’d add to Matt’s suggestions is to do the following:
In Mountain Lion, the new Messages app replaces iChat.
If you’re the kind of person like me who religiously keeps your email, chat logs, etc, but you have chosen not to do a migration of your data when upgrading to Mountain Lion, you’re going to be faced with the problem of how to import your old iChat logs into Messages.
It turns out that Messages stores logs in:
They appear to be the same format as iChat, so if you move your old logs into this folder, Messages will find them.
Alternatively, you can make a symbolic link to a folder elsewhere and put your logs in there. For example, this will rename the old Archive as “Archive.old”, then make a link to a folder called “iChat” in your Dropbox folder.
> cd ~/Library/Messages > mv Archive Archive.old > mkdir -p ../../Dropbox/iChat > ln -s ../../Dropbox/iChat Archive
This just leaves the Archive.old folder lying around, but you could obviously move its contents into your new iChat folder then delete Archive.old.
My first desktop Mac was a IIcx, bought in about 1989, for the astounding sum of nearly £4000 (to put that in context, it took me a year of working between school and university to pay for it, and I could have bought a new Ford Fiesta for less).
Since then, as a Mac developer, I’ve owned and used many more, pretty much always the top spec of the current generation. There was certainly a time when having the latest, greatest desktop machine was essential (not to mention highly desirable for the sheer geeky joy of it).
However, since going back to indy development in 2010, I’ve only worked on my laptop, and I didn’t have a desktop machine at home for a good few years prior to that, despite regularly working from home on a big game with masses of data.
So the recent speculation leading up to WWDC about whether the Mac Pro would get an update, and the subsequent answer (“not really, well maybe slightly, but there’s something new coming next year”), lead me to ponder what I’d actually want.
Last November I encountered an issue in Xcode whilst attempting a submission.
I was getting an error due to the fact that some embedded bundles in the application that I was submitting were signed with the wrong identifiers.
Xcode, rather unhelpfully, reported this:
“the nested app bundle ECFoundation (Ambientweet.app/Contents/Frameworks/ECFoundation.framework) is not signed, the signature is invalid, or it is not signed with an Apple submission certificate. Refer to the Code Signing and Application Sandboxing Guide for more information.”
I submitted a Radar report, pointing out that whilst having an error message is helpful, it would be even better if it narrowed down the actual cause, rather than suggesting three possibilities and leaving you hanging.
Last week, I got the first response to this report:
“We believe that this issue has been resolved through changes on our side.
Please let us know whether the issue is resolved for you.”
Now first of all, let me say that I appreciate getting the response.
The first sentence is really helpful, as it sets my expectations - if I use the latest Xcode, it’s probably fixed.
The second sentence is a little irksome. If they’d just said “Please let us know if you notice any problems”, I’d be fine with it.
Even as it is, I do realise that it’s probably just a stock response, and I shouldn’t read too much into it, but it does slightly irritate me.
Think about it for a minute. I had an issue seven and a half months ago. It was an issue with submission. Am I really likely to still have something that exhibits that issue?
“What about source control?” I hear you cry (that was you, wasn’t it?). And yes, you’re right, I could wind back in git and get the project into the state it was in then. But hang on, it was a problem with submission. So I’d need to do a submission again. Now forgive me for being a wuss, but I’m not in a great hurry to submit a new version with seven-and-a-half-month-old code. I could probably do it - add a fake new version, hack around the old code to have the right version numbers, perform the submission, cancel it if it worked, and so on.
We’re starting to talk about a bit of an investment in time now though. Maybe only an hour or two, but it’s funny how these sorts of things have a habit of taking longer than you expect. Now I don’t fall into the trap of immediately equating any time spent doing anything in my life with the hourly rate I charge in my working life, but…
And thus we see some of the problems with the bug reporting dance:
All of this leads to the feeling of futility / apathy that I’ve mentioned in previous posts.
I’m sure I could make a test case and satisfy myself that the problem is fixed. Maybe offer further feedback on the solution they’ve come up with. If I happen to encounter it again in passing, I will. If I’d had a personal email from someone on the Xcode team, I’m sure I’d do it right now, no matter how long it took (despite the fact that I wouldn’t be doing anything that they couldn’t do themselves), just because it’s nice to feel involved in the future of the tools that I use.
In the absence of that email though, going out of my way just feels, frankly, like it wouldn’t be worth the effort.