Author: ruaok

April 1st may not be the best date to release a new server, but scheduling would have it that way: The next server update is officially scheduled for April 1st, 2007.

To prevent the next release from becoming a bad April Fools joke, we will need your help to test the new features on the server. Recently we’ve asked people to come check out the new Labels support and the Data Quality support. Now that we’re coming to a close on this new release (there are still bugs to be fixed, but major functionality changes are done) we’d like people to come check it out again and help us test on the staging server.

The following features will be included in the next release:

1. Improved cover art support: A new release-url Advanced Relationship link type has been created. By linking a release to a cover art JPG file at CD Baby or at the Internet Archive, editors will now able to deep link to cover art on sites other than Amazon.com. For more information on this feature, see CoverArtSites. See an example here and here.
2. Data quality: Based on the first round of feedback, we’ve narrowed the data quality levels down to 3 from 4. The staging server has also been loaded with recent data and the ModBot is now running for a more complete test. See below for more comments on this.
3. Label support: Label support has been around and a number of bugs have been fixed. For more info see Labels.
4. Lookup nagging: Nagging tagger users who look up their files at MusicBrainz but who have not donated. If you go to to the taglookup page, you will be constantly nagged if you’re not logged in. If you log in, you will only be nagged every 5th lookup (I suspect that most people will be logged in). If you’ve donated to MusicBrainz, you wont be nagged at all. Designed to be not terrible right off the bat, I am curious to see what people think of this solution. Please point your tagger to http://test.musicbrainz.org and do some lookups to see if you think the current nagging approach will work ok.
5. Bug fixes: Lots of them — see our milestone info for more details.

I have some more comments regarding the DataQuality feature — based on blog feedback I’ve changed the data quality levels to:

1. Low
2. Unknown
3. High

I’m not certain if these are the best levels, but I wanted to throw out some thoughts that go with choosing these names/levels. First, the existing data and all new data that editors have not vouched for needs to have a name attached to it that makes sense. Just applying low data quality to all data by default will be unfair to large swatches of our data. I think one level needs to indicate that no human has vouched for the data and the other levels needs to indicate that someone has looked at the data and given it a thumbs up or thumbs down. Second, I like Low and High, but I am not a big fan of Unknown. What other word can we use that suggests that no human has vouched for this data?

Other suggestions I’ve tried for level names:

• bad, unknown, good
• unverified, unknown, verified

I tend to dislike these levels since labeling our data as bad seems like a poor idea. And verified is questionable as well — what do you verify the data against? So, please take the staging server for another spin and let us know what you think now. We still have nearly three weeks to try and figure our the best way of handling this.

Finally, the change artist/release quality edits are currently still auto edits for everyone — this will be changed before the release.

Thanks!

The attempt to switch the database to the new Sun server has failed and we’re still running with the old set of hardware. For some reason Postgres refuses to run with any kind of acceptable level of performance on this new machine. Thus, we’re setting aside this server for the time being and instead working to bring a replacement server online as soon as possible.

We’re also working with Dell to determine what the problem on the server is, and luckily the servers still have an extended warranty covering them with 4 hour on-site service. However, it appears that we need to diagnose the problem before Dell is willing to send someone out. I’ve run a memory test on the server and it passed all of its tests.

I’m out of ideas. I’m frustrated with Sun and Dell and will no longer waste time on their hardware trying to solve this problem. Instead I will work with whatever hardware I can scrounge up and get the service moved over to our spare server and then we’ll sort out the issues with our glorious servers.

It looks like it will at least be Friday before we can make the next attempt to fix this. Again, sorry for the inconvenience — we’re doing our best to fix this problem ASAP.

Tomorrow January 17th MusicBrainz will be unavailable starting at Noon PST, 15:00 EST, 20:00 UK, 21:00 CET, for at about 1 hour.

The recent problems with certain artists not being found are being caused by a failing motherboard (specific guess: failing DMA controller). Fortunately the database server is still working well and the database has not been affected by this hardware malfunction.

Tomorrow Dave Evans and myself will bring moose, our newly donated Sun Server, online and swap it out for the current database server. Once the new database server is up and running, we will want to monitor it for a while to make sure its doing its job properly. Once we’re convinced that it is doing its job, we will take the site down again and swap the drives in our then-to-be obsoleted database server with our ailing web server and bring the site back up.

After that we can remove the failing server and purchase a replacement motherboard — if you’d like to make a donation to help us cover the cost of the new motherboard (est: $800), we would greatly appreciate your support!

Thanks to Sun for the spiffy server that will get us out of a this bind and a big thanks to Dave Evans for his hard work getting our servers stable again.

I apologize for the inconvenience all this may have caused you.