A couple of things...

First up, much of the feedback that we've received is around the speed that Sleevenotez updates related to when the track you're listening to changes. This is a (very sensible) artefact of the Audioscrobbler protocol (which you can read here if you're that way inclined). The main point in there is that tracks are only scrobbled when they are 50% of the way through, or at 4 minutes, whichever is the sooner. That means that for a 3 minute track it can easily be 2 minutes before Sleevenotez notices that the track has changed, giving the feeling that it is always one track behind.

Luckily version 1.2 of the submissions protocol is in draft right now, and includes provision for a 'currently playing' scrobble at 10 seconds in, which hopefully will sort out the lag once and for all. I can't say how pleased we were to be pointed to this by Paul at SnappRadio - it fair made our week!

Second up, we have finished the iteration planning for iteration 3. This one is all about users interacting more with the application. This iteration of Sleevenotez makes the most of the data collection features of Zythe (the platform Sleevenotez is built on), by providing lots of things to poke at and fiddle with while using the site. This is in reaction to one of the other main pieces of feedback; that, if you were listening to an album by a single artist (rather than radio, compilations or your collection on shuffle) the site became quite static. One of the things we're aiming at is an application that supports the wonderful notion of "Partial Continuous Attention" - hopefully this iteration will take us one step closer.

As always, please keep the feedback coming in. With your help we've found a fair few things that we'd never noticed or thought of (and we love it when you're nice!)

Also, a couple of people have reported not receiving their confirmation codes. Amazon's EC2 servers seem to be listed in pretty much every spammer database out there (something we hadn't really thought of) and so many of the early sign ups won't have received their confirmation mails. If that's you, try typing your email address into the forgotten password box on the homepage and you should get sent your code again, through less spam friendly servers. If that still doesn't work mail us at help@sleevenotez.com and we'll try and sort you out.

Anyhow, for Andy and anyone else who needs help with anything, email help@sleevenotez.com and we’ll get back to you pronto. Andy: I’m looking into your confirmation email issue right now.

All of registration is done now, apart from some low priority admin stuff we are punting to the next iteration. Andy has been working on a number of new data sources too, which look really good. We’ve also fixed a whole load of defects, so the system is much more reliable.

There’s a bunch of UI work to do to polish off the new features ready for a release, which we’ll be doing on Monday, and then we’ll release what we’ve got so far. As Mark said, we’re taking the password protection off again, now that various annoying things have been resolved.

Any other issues you'd like to see fixed? As always, please comment here

This afternoon we've made another major change. We've put Twistd on port 80 and removed our reliance on Squid. We did this to tackle the occasional timeouts, but also to decrease the complexity of our install (we've also removed our reliance on DivMod's excellent Mantissa as we realised that it was unnecessarily complex for our needs). This means that there may be some oddities - we have a feeling it should go quicker (and it's definitely simpler under the hood), but if you see anything odd please let us know by leaving a comment here.

Please remember that it's in pre-pre-pre-alpha state at the moment and so it will look rough and ready in places and like as not it will fail on you somewhere. That said, if you are using it and it fails on you in a spectacular fashion please let us know (by leaving a comment here).

We're particularly interested in the following information:

• What the user you were looking at was listening to, or which artist page were you looking at
• Did you get any message?
• What browser version/operating system are you on

The only proper breakages that we know about at the moment are the weird behaviour (or lack thereof) of the back button in IE and the occasional timeout which presents a rather natty flashing warning. We're looking at them both at the moment and will hopefully have fixes in place soon.

And, yes, we know, some of the data for some of the bands is completely wrong (Nirvana, Parliament, Air, etc etc). We are looking into ways of fixing it, but like as not it will be a community driven thing. We're planning on implementing the tech to support user editing of site content in iteration 3, so please hold on!

edit 18:08 01/09: so we launch, and literally 10 minutes later the audioscrobbler post servers go down, meaning that all our comety loveliness doesn't work. Clearly we need a way of a) testing the status of audioscrobbler and b) communicating any failures to our users...

Iteration 1 is now complete, and this is how we did:

As both Doug and I have blogged about, getting MusicBrainz up and running and correctly identifying tracks proved considerably harder than we thought. We had estimated a velocity of 27 story points in 14 days and achieved those points in 15.5. Not bad, particularly as knowing what we now know I would re-esimate the MusicBrainz related stuff as about 3 times as much.

Iteration 2 will be 16 days (looking like 30 story points). I'll write up which ones we are tackling after our next planning session.

/* Give up if the year is before 1900.
 * Python strftime() plays games with the year, and different
 * games depending on whether envar PYTHON2K is set.  This makes
 * years before 1900 a nightmare, even if the platform strftime
 * supports them (and not all do).
 * We could get a lot farther here by avoiding Python's strftime
 * wrapper and calling the C strftime() directly, but that isn't
 * an option in the Python implementation of this module.
 */

BItten again. Previous projects where I have hit this problem I've been safely able to ignore it. Ignoring Noel Coward, Humphrey Bogart or Duke Ellington's date of birth is going to be difficult. Ignoring nearly all classical music is going to be pretty much impossible. Some thought is clearly required. I have a feeling it's not vitally important to get it 100% right, but something needs to be done if only to disambiguate the two Engelbert Humperdincks.

http://developer.amazonwebservices.com/connect/thread.jspa?threadID=11559

Actually very simple. I managed to make pretty much every mistake going though, en route. Unfortunately when you screw up all you get is a remote image that you can’t connect to - no debugging output whatsoever.

doug.

I wanted replication to be controllable within the sleevenotez application architecture, and more to the point I didn’t want to have to schedule a bunch of cron jobs running perl scripts on our development environments. I’ve ported the dbmirror slave part to twisted with a MusicbrainzReplicationService running on startup that does the full process of replication - ftping to the server, pulling down the packages, unpacking them, parsing them and updating the database.

It works very nicely, and seems to be working as well, more to the point. I’ll be releasing this bit back to the community once I’m sure it’s bug free - it might be useful for others later.