Connectivity problems resolved

A few of you have reported problems with connectivity to the MusicBrainz site in the last week. With help from various people in Canada and Europe we’ve been able to provide information for Digital West (our provider) to fix the problem. As of 11:38 PST the problem was fixed.

If you are still experiencing problems, please post a comment here or open a bug in our bug tracker.

Thanks and sorry for the inconvenience!

New customer: Cloudspeakers in Utrecht

I’m pleased to announce that I signed a new customer in the Netherlands yesterday! I met the Cloudspeakers team in Utrecht and spent a day discussing their business and how Cloudspeakers can work with MusicBrainz in the future.

After many conversations during the day, we ceremoniously signed the data license contract over an elegant and extremely tasty Indonesian meal. A day well spent!

A big thanks to Chris, Stan, Adriaan, Charlie and Francis! Thanks for inviting me, paying for meals and even my flight to the Netherlands. I look forward to working with you!

Calling all guinea pigs!

I come bringing good news! With the latest version of the server now out in the wild, we’re ready to move on to the next stage of MusicBrainz development. But first a quick refresher…

You may recall, many moons ago I (Oliver Charles aka aCiD2) began work on moving the mb_server codebase from our own in-house framework, to the tried and tested Catalyst framework – along with separating out the HTML into separate Template Toolkit templates. Well, after what seems like an age, it’s finally got to the time where I can start getting some critical feedback from the most important people – you!

As from now, is now running the development branch of this work. It’s important to realise that this new codebase currently has no javascript support. This decision was made because it’s very important we get the website fully functional, and then add bells and whistles on later. We’re starting from a mostly clean slate, so there’s a lot of chance of things breaking, and JavaScript was likely to be just one more headache.

Oh, and I’ve never deployed a server like this before, so please bare with me while I work out any problems running the server. I’m going to London tomorrow and coming back Saturday evening (slightly bad timing, I’m aware) – but I’ll do my best to check any messages that come my way!

However, before you jump straight in and overload us with work – I’d like to lay down some guidelines for providing us with feedback. This will (hopefully) ensure that we can see to these bugs as fast as possible.

Where to report:

Standard practice- report at our bugtracker –

What should you report?

The most important things to report are actions that cause errors to occur, invalid behaviour or features that are simply not available, but are from the main server. You should also report typos and other visual problems – but I will be encouraging people to help fix these themselves (more on this later!).

What information should you provide?

The most critical information is that you can provide us with as much context as possible. Please let us know:

  • Any steps to reproduce the problem
  • Whether you are logged in or not
  • The address of the page that caused the problem
  • As much information as possible from the top of the error page

The last point relates somewhat to Catalyst. Catalyst features improved error handling and can provide us with a stack trace. You should try and include this stack trace, and the errors at the top. Chances are, we’ll be able to reproduce this from the information you provide – but if not, the stack trace gives us one more pointer to where the problem is ๐Ÿ™‚

How should you organise the report?

Generally speaking, just try to fill in as many of the fields as possible. I’ll be reading every single report that comes in, and re-filing it myself where necessary. Ideally, set the component to ‘MusicBrainz’, the milestone to ‘Server: TemplateToolkit’ and assign the bug to me ๐Ÿ™‚


Let the bug crunching begin!