I downloaded the latest version of iTunes yesterday, version 7.6.1, and I shouldn’t have.

It installed OK, but afterwards when I tried to update some tracks, by adding artwork or adding a rating I received the error message ‘The song …… could not be used because the original file could not be found…..’. I got this message on a lot of tracks. You do get the option to find the missing track and all that means is adding the tracks back into iTunes from it’s own folder or even the whole album, but this is a very long process when hundreds of tracks that have gone west.

I had a look at where iTunes thought my music was being stored, via the Advanced tab of Preferences, and that had been reset to the default c:\documents and settings\…….. folder, which is great except that my music was actually stored on an external drive – m:\itunesmusic. Changed that setting to point to the folder on the m: drive, exited out of iTunes, even rebooted the PC and had another look at these failing tracks.

Some tracks were OK but a helluva lot of others couldn’t be found. Hmm… Uninstalled iTunes, Quicktime, Apple Software Update and Apple Mobile Device Support and rebooted. Installed the old version of iTunes – 7.6.0.29, rebooted and restarted iTunes. This time it’s gotta be OK, right? Wrong. Exactly same problems as before.  Did a search on Google and got the usual reimport everything and lose ratings & playlists. When you have about 30,000 tracks that’s not a very tempting prospect.

What’s common across the two versions of iTunes?

The xml file, which contains tracks information for everything I have loaded into iTunes. For some reason in Windows Explorer I couldn’t see the timestamp for when the xml file had been updated, but I assumed it was probably around the time I installed version 7.6.1 of iTunes. Had a look at an entry for a good playable track and an entry for a not playable track and compared them. I noticed that the track that played OK was an MPEG and the track that didn’t play was an AAC.

I did the predictable test of trying to play half a dozen MPEG files and they all played or were accessible OK and then half a dozen AAC files and of course none of them were accessible. Had another look at the xml for the good and bad tracks and noticed that the good tracks had the Kind key of ‘MPEG audio file’ and the track location had an extension of .mp3 (MPEG-1 Layer 3). The bad track had a Kind key of ‘AAC audio file’ and the track location had an extension of .m4a (MPEG-4 AAC audio). Also the AAC files were still pointing back to the C: drive rather than the M: drive. Not sure if I understand this as it appears that as soon as I tell iTunes that its library is on the M: drive rather than the C: drive it appears that the location path is updated in the xml file but it appears to happen only for the MPEG files. I started to get a bit of a sinking feeling about all this.

Did some reading on AAC files and gee was that worrying with all its talk of DRM and encryption keys which are required to play AAC files back, and which I couldn’t do. Am I getting a bit paranoid or has the iTunes software shuffled through my music making a whole load of songs unplayable. I did notice that those AAC songs that I had purchased from iTunes still played OK. iTunes obviously knows which songs I have bought from it’s store and maybe it accidentally decided to delete all other AAC songs as they weren’t purchased from Apple? 

I was able to replace all of the busted songs from a backup of the iTunes music folder I have on yet another external hard drive, and which I had converted all of the tracks to MPEG. What made me convert them to MPEG? Dunno but thank the Lord.

I also downloaded one of those iPod rippers which allows you to copy music from the iPod back onto your hard drive, just in case.

Our project office has moved and for the better. We are now in a much larger open plan office with a lot of other IT people so if nothing else it does stop some of the juvenile behaviour.

We’ve just had 3 days to regression test the system and the part I was responsible for was by far the largest, functionalty wise. I did get some help and we actually managed to pass about 97% of the tests which was a miracle. Lots of happy management around right now. Some of the developers were involved and though they wrote the system a lot of them had a devil of a job proving stuff worked. Odd but true.  

I didn’t realise there was so much dislike of contractors by permies till recently but without us they wouldn’t get anything working.

I have a recurring problem with my Internet radio. Sometimes when I want to listen to English soccer on it I get a canned message saying how they can’t broadcast it for some legal reasons. I know what the problem is. When the radio connects to the BBC radio site it thinks I’m listening from outside of the UK and therefore due to the quaint licenses the BBC manage to get us to pay for it can only broadcast to the UK, hence the canned ‘we can’t broadcast to you’ message.  Now why does it think I am trying to listen outside of the UK when I am not. I assume there are some proxy servers in Yerp somewhere generating a bit of confusion.

A couple of months ago I phoned my ISP’s 24 hour helpdesk and explained to them this situation and the support person said that they didn’t have that sort of information to which I responded ‘you don’t know where your servers are?’. Obviously something happened after that as a couple of days later I could listen to live soccer on the internet radio.

The problem has now returned. No doubt there is one tiny little tweek somebody needs to make so that the outside of UK servers appear to be in the UK. I assume something fell over and when it was restarted the said tweek was not reapplied. This could go on for ages unless more people understand this problem and start phoning BT’s support desk and giving them an earfull.

We’ve had a lousy week on the project with the usual constant screw ups in deployment, bug fixing that introduce more issues than they clear, and more.

Yesterday we had yet another final build that even the developers got to help smoke test. We had some rudimentary scripts for them to run and some of them were run far too quickly. These guys hadn’t used the test harness before, with all of its quirks and foibles, so it was a bit odd that they were able to complete running the scripts so fast. There was the usual deployment issue where half a dozen screens fell straight over. The problem was found within 10 minutes, but it does make you wonder why they don’t have a check list of every single thing that has gone wrong in deployment before to ensure that these issues don’t reappear. Somebody did tell me that they do sometimes write that kind of checklist, but it’s not kept up to date and rarely used. Lessons learnt? Nope.

There is no doubt a difference in attitude between the contractors and the permies. The poor permies have never known IT development work any differently so these constant screw-ups are the norm. Everything to them is garbage, nobody knows anything and nothing works. If anybody does try and make any processes a bit more structured they do their best to destroy it. Write a test script and they hate it and it gets trashed to pieces. I have seen this at other sites where if you bust a gut to produce some testing documentation some people hate it so much they tear it to bits. Dunno. The contractors just shudder.

A month ago the brought in management team made plans for us to have new builds started wednseday afternoon to be completed by 5pm, then smoke tested so that it can be handed to the system testers the following morning. Of course that didn’t work as the builds failed so spectacularly that they would take till friday to finish. Then the smoke test would fail and we would be lucky to get the release before the following wednesday. Then we ended up in a situation where there were constant builds going on and someone somewhere was always smoke testing a release. Some of these guys are plainly out of there depth and just can’t deliver. Or maybe they just like the constant hacking away at the coal face.

I left them well alone to get on with what they do so well and carried on with our backup test environment and did make some progress finding several significant issues for the developers to have a shot at. I can’t but think that a lot of the problems are due to it being such an agile project with so little documentation so that you end up with different people having wildly different perceptions of what the software is supposed to do. Over time peoples understandings of the requirements do coalesce but it’s a darn painfull process.