Next round of logos

If you happen to have any comments on these new designs, please leave them!

I may form a small team of people to whittle down these designs into a final set of 1-3 logos. Please leave a comment if you’d be interested in being part of that team and have some time in the next few days. Or perhaps the feedback will be concrete enough for us to proceed; let’s see what the comments bring.

MusicBrainz_logos_23-04-15

UPDATE: Thanks to our friend Nicolas at Monkeydo.digital

Server update, 2015-04-06

Another release out today, this time with a couple new features for editors to take note of:

  • It’s now possible to add releases without any mediums attached. This is useful for cases where the release is known to exist but the tracklist is unknown. Currently this feature is a bit hidden: you have to remove the default blank medium to expose a checkbox that lets you confirm your intention to submit things that way. Based on community feedback, we can possibly make this more visible in the future. Note that it’s not (yet) possible to add mediums without tracks, only releases without mediums.
  • There’s now a minimum voting period length for destructive edits like merges and removals. Even if such edits get three yes votes, they’ll remain open for a minimum of 48 hours.

Thanks to chirlu (especially for the latter feature) and the MetaBrainz team for their work on today’s release. The git tag is v-2015-04-06 and the complete changelog is below.

Bug

  • [MBS-8137] – Release editor does not prevent duplicate label/catno pairs
  • [MBS-8162] – “Add work” from artist sidebar includes useless artist parameter
  • [MBS-8163] – Merging labels can produce duplicate label/catno pairs
  • [MBS-8300] – Medium title “0” not displayed
  • [MBS-8313] – Can’t remove last attribute from a relationship via the /relationship-editor endpoint

Improvement

  • [MBS-8234] – Enforce a minimum voting period for destructive edits
  • [MBS-8327] – Show an icon for CDBaby links

New Feature

  • [MBS-3235] – Allow adding release stubs (without tracklist)

Server update, 2015-03-23

Today’s release focuses on fixing various editing bugs, particularly in the release editor. For those who use the track parser often, it should be a lot better at retaining track MBIDs after you reuse recordings now.

The entire list of changes for today is below. Thanks to chirlu and the MetaBrainz team for working on these tickets.

The git tag is v-2015-03-23.

Bug

  • [MBS-5108] – Setting end-date is no longer auto-edit
  • [MBS-7719] – “Reuse previous recordings” button not available after using the track parser
  • [MBS-7983] – After adding “translator” relationship, “translated” flag gets stuck for subsequent relationship
  • [MBS-8212] – “Copy the release artist credit to the release group” on the release page is broken
  • [MBS-8272] – Web service doesn’t output language or script for releases that are relationship targets
  • [MBS-8285] – Unable to edit release with deprecated external links
  • [MBS-8286] – Seeding URLs on Add Release is broken
  • [MBS-8296] – It’s now impossible to re-order Release Groups in a Manual Series

Improvement

  • [MBS-7071] – Make it possible to use the Track Parser to fix mistakes without creating new Track MBIDs
  • [MBS-8231] – Use https URLs in emails
  • [MBS-8281] – Remove the knockout-postbox plugin

Spring schema change release: 18 May, 2015 & important Live Data Feed change

I’m pleased to announce our upcoming schema change release on 18 May, 2015. In this release we will implement each of the tickets listed in this fix version:

      • MBS-1347: Implement aliases for release groups, releases and recordings.
      • MBS-4145: Up/down vote for tags — This feature will be our first attempt at getting into “genres”. People have expressed that our tags are vaguely useful for genres, but expressed frustration at not being able to give feedback about the tags. Voting on tags will allow us to find the tags that people find useful, which will allow us to develop a list of tags that we consider to be “genres”.
      • MBS-7489: Artist Credits for Relationships — This feature will allow MusicBrainz to store an alternate artist display name (Artist Credit) for a given credit (Advanced Relationship).
      • MBS-8266: Make medium titles VARCHAR NOT NULL — Fixes a database inconsistency that should have little to no impact on end users.
      • MBS-8279: Remove empty_artists etc. database functions — Another database/code refactoring that should also have little impact on end users.
      • MBS-8283: Remove DB constraint that disallows empty event names — This allows event names to be blank, since many events do not have a proper name.
      • MBS-8287: Log deleted entities that were in a subscribed collection — This feature will give users a notification if one of their subscribed entities is deleted.
      • MBS-8302: Add Live Data Feed access token support — Add support for using access tokens. See below for more details.

UPDATE: We forgot to list the following change, which is already almost ready to go – apologies for the slightly late addition!

UPDATE 2: This change will not affect users of our replicated data at all, since the changes are to non-replicated tables. This is the only reason we decided to sneak this change in after the official announcement.

    • MBS-8004: Extend collections to other entities — This extends the current ability to create collections (user-made lists) to other entities apart from releases and events. That means users can make arbitrary lists (“Artists I’ve seen live”, or “Songs I can play on the piano”), and also subscribe to them to get notified when anything on the collection is being edited.

Finally, I’m not describing MBS-8278, since that is an internal housekeeping reminder and will not really affect downstream users. All in all this is fairly light schema change for us, since we currently have a number of other projects that we wish to undertake in the medium term.

Important Live Data Feed change: After 10+ years of our Live Data Feed being available to anyone on the honor system, we are going to require Live Data Feed users to have an access token to fetch the replication packets for the Live Data Feed.

At the beginning of May we are going to release a new MetaBrainz web-site that will allow all of our current Live Data Feed users to create an account and to generate themselves an access token. Non-commercial users and existing commercial users will be immediately approved and will receive an access token. This access token will need to be add to your MusicBrainz-server (or mbslave) configuration in order for the Live Data Feed to continue to work as expected. Any new commercial users will need to sign up to one of the support tiers that the new web-site will present.

NB: If you are currently using the Live Data Feed legitimately, you should see no disruption to your use of the feed.

Postgres troubles resolved

I am glad to report that our problems are fixed and that our server is back to humming along nicely. The following is posted here so that if some other souls find themselves in our situation that they may learn form our experience:

What we changed:

  1. It was pointed out that max_connections of 500 was in fact insanely high, especially in light of using PGbouncer. Before we used PGbouncer we needed a lot more connections and when we started using PGbouncer, we never reduced this number.
  2. Our server_lifetime was set far too high (1 hour). Josh Berkus suggested lowering that to 5 minutes.
  3. We reduced the number of PGbouncer active connections to the DB.

What we learned:

  1. We had too many backends
  2. The backends were being kept around for too long by PGbouncer.
  3. This caused too many idle backends to kick around. Once we exhausted physical ram, we started swapping.
  4. Linux 3.2 apparently has some less than desirable swap behaviours. Once we started swapping, everything went nuts.

Going forward we’re going to upgrade our kernel the next time we have down time for our site and the rest should be sorted now.

Finally a word about Postgres itself:

Postgres rocks our world. I’m immensely pleased that once again the problems were our own stupidity and not Postgres’ fault. In over 10 years of using Postgres, problems with our site have never been Postgres’ fault. Not once.

Thanks to everyone who helped us through this tough time!