Schema change release, 2017-05-15 (including upgrade instructions)

We’re happy to announce the release of our May 2017 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers.

This is a fairly minor release as far as schema changes go, but please do report any issues that you come across.

Currently, the only visible change for editors is the ability to add multiple lyrics languages to works. We’ve also modified the schema to support dynamic attributes for entities other than works, but the UI for that won’t be complete for another release or two.

Now, on to the instructions.

Schema Change Upgrade Instructions

Note: Importing the latest data dump is always a valid alternative to running ./upgrade.sh on an existing database, if you’d prefer to also get new data in one go. Just follow the relevant instructions in INSTALL.md. The rest of the instructions here assume an in-place upgrade.

  1. Make sure DB_SCHEMA_SEQUENCE is set to 23 in lib/DBDefs.pm.
  2. If you’re using the live data feed (your REPLICATION_TYPE is set to RT_SLAVE), ensure you’ve replicated up to the most recent replication packet available with the old schema. If you’re not sure, run ./admin/replication/LoadReplicationChanges and see what it tells you; if you’re ready to upgrade, it should say “This replication packet matches schema sequence #24, but the database is currently at #23.”
  3. Take down the web server running MusicBrainz, if you’re running a web server.
  4. Turn off cron jobs if you’re automatically updating the database via cron jobs.
  5. Switch to the new code with git fetch origin followed by git checkout v-2017-05-15-schema-change.
  6. Run cpanm --installdeps --notest . (note the dot at the end) to ensure your perl-based dependencies are up to date.
  7. Run ./upgrade.sh (it may take a while to vacuum at the end).
  8. Set DB_SCHEMA_SEQUENCE to 24 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh.
  9. Turn cron jobs back on, if applicable.
  10. Restart the MusicBrainz web server, if applicable. It’s also recommended you restart redis. If you’re accessing your MusicBrainz server in a web browser, run npm install followed by ./script/compile_resources.sh.

For those curious, here’s the list of resolved tickets (excluding MBS-8393):

Bug

New Feature

  • [MBS-9271] – Prevent usernames from being reused

Task

  • [MBS-9273] – Fix the a_ins_edit_note function in older setups to not populate edit_note_recipient for own notes
  • [MBS-9274] – Fix the edit_note_idx_post_time_edit index in older setups to handle NULL post_time

Improvement

  • [MBS-5452] – Support multiple lyric language values for works

Schema change release: Today at 17h UTC

We’re going to start our schema change release process today at 17h UTC.

We anticipate having a short downtime of a few minutes as we”ll need to restart our database server. As usual, we’re not certain when we will start the downtime, but we’ll keep people posted about our progress in IRC and on Twitter.

Once we’re done with the release we will post instructions on this blog on how to upgrade any replicated instances of MusicBrainz you might be running.

Stay tuned!

Picard 2.0 dev available via PyPi

Sambhav’s GSoC project is all about Picard 2.0, and among progress made the devel version is now installable via PyPi: https://pypi.python.org/pypi/picard_dev

To install the dev builds you need to have a Python 3.5 or greater. At the moment it is mainly a port of 1.4.x to Python 3 and Qt5, with support for HiDPI and new icons !

Please note that Picard Dev version uses a different config file than your stable Picard installation. As such the settings and plugins will be on their default configuration.

To use your stable config with the dev version, simple copy your “Picard.ini” file from your MusicBrainz user folder to “Picard Dev.ini” which can be found in the same folder.

Since testers may want to run a stable 1.4.x version along the 2.0 dev one, the executable is named “picard_dev”.

Of course, we encourage people to test this version on every platform they can, and report any issue.

Thanks to Sambhav Kothari for the fantastic job he did on this ! And stay tuned, more to come !

Picard 1.4.2 released

Official MusicBrainz cross-platform music tagger Picard 1.4.2 is now out.

This is mainly a bugfix release, the only notable improvement is related to TOPE/TOAL tags.

Users can get Windows and MacOSx packages from Picard website downloads section.

Bug

  • [PICARD-1053] – Picard does not stop analyzer while moving
  • [PICARD-1055] – picard hangs with: RuntimeError: maximum recursion depth exceeded in cmp
  • [PICARD-1070] – The “Convert Unicode punctuation characters to ASCII” function only works in certain tags
  • [PICARD-1077] – ID3v2.4 text encoding settings are not saved correctly

Improvement

  • [PICARD-969] – Search dialog webservices get queued behind matched album requests
  • [PICARD-1034] – Picard not seeing TOPE and TOAL

Server update, 2017-04-10

This release brings feature parity with the pre-NGS edit search, thanks to work by yvanzo.

Note: The “My Vote” search condition has been replaced by “Voter,” with sub-condition “is me.”

The git tag is v-2017-04-10.

Sub-task

  • [MBS-2673] – Filter by voter
  • [MBS-3362] – Filter out own edits
  • [MBS-3665] – Inform users of appropriate formats to use for expired/created/closed time or edit/Id ranges
  • [MBS-3914] – Filter edit queue by subscribed editors
  • [MBS-5681] – Filter by vote

Bug

  • [MBS-9088] – Search for editor edits fails

Improvement

  • [MBS-9295] – Allow Baidu Baike URLs using current format

Simplification of the featured artist guideline

Hi everyone!

In the past couple years, we’ve steadily reduced the amount of standardisation we do, instead preferring to stick closer to the original release information (except for obvious errors) and let the end users do any standardisation as desired. The main rationale for this is that it’s generally easy to standardise automatically, but impossible to get the original information back: as such, standardisation is best done on demand over the original data. The last big step of this process is to simplify and soften the very restrictive featured artist guideline.

The guideline was originally written when we could only store one artist per track/release, as “add (feat. X, Y & Z) to the track title”. This allowed us to enter the featured artist information on the track title in a standard way in order to deal with it better in the future. And that worked fantastically: in fact, it allowed us to write a series of reports (for release groups, releases and recordings) that make it easier to find entities where the artists need to be moved to their rightful place in the artist field, now that we can!

When we started migrating the info to artist credits, we decided to basically keep the guideline as-is, but start adding the artists to the artist field. So we’d have “Song”, by “Artist feat. X, Y & Z”. This was a huge improvement, since the artists were now properly linked, but such strong standardisation was always a bit heavy handed, and at the same time quite restricted (since it only applied to variations on the word “featuring”, but not to any other linking phrase).

As such, we’ve decided to stop standardising credits using variations of “featuring” as well. The new version of the guideline can be found as part of the artist credit guidelines, and reads:

Featured artists should always be entered in the artist credit, not in the titles. You should generally enter the credit as it appears on the release, omitting any separators (like parentheses) that are intended to separate it from the track title. For example, if the tracklist has “Artist 1 – Song Name (featuring Artist 2)”, enter “Song Name”, by “Artist 1 featuring Artist 2”.

It also gives a few examples:

This decision was taken a few weeks ago, but to avoid disruption we waited until we had a Picard plugin available for anyone who still wants to standardise “featuring” in their own tags. That’s now available (thanks to Sambhav Kothari), so we feel it’s the time to make the change official. If you want to keep all variations of “featuring” as “feat.”, go ahead and install that plugin, and things should remain basically as they were!

One last note: I strongly encourage people not to vote against any edit moving featured artist information from the titles to the artist field, even if it doesn’t exactly follow the wording used on the cover. As always, any clear improvements like this one should be accepted, even if they’re not perfect, and the data can be improved further afterwards.