MusicBrainz Server update, 2019-11-25

Starting with this release, we read our genres list from the genre table rather than a hardcoded list inside a JSON file. This should have no user-visible impact, but let us know if you encounter any new issues related to genres. (This change should however help us improve genres further.)

We also have a small list of bug fixes and improvements, listed below. One neat new feature is the ability to sort edit searches by date closed or closing.

Thanks to chaban, culinko, drsaunde, jesus2099, mglubb, lotheric, psychoadept, sothotalker, and all others who reported issues or helped test or translate today’s release!

The git tag is v-2019-11-25.

Bug

  • [MBS-7097] – Release listed multiple times in “Non-digital releases with download relationships” report
  • [MBS-10466] – MusicBrainz Happy Birthday wishes doesn’t take into account timezones
  • [MBS-10467] – Pages ported to React do not show the new edit notes banner
  • [MBS-10473] – Static resources fail to build when NODE_ENV=production
  • [MBS-10485] – User profile’s “Statistics Edits (view)” links to bogus URL
  • [MBS-10488] – Regression: User profile subscribe links no longer work

New Feature

  • [MBS-9491] – Move genres to be read from the database

Improvement

  • [MBS-4299] – Warning when merging releases with diff. recording artists should show disambiguation
  • [MBS-10204] – Better overview of user edits on user page
  • [MBS-10471] – Add option to view edits by date closed

React Conversion Task

  • [MBS-9922] – Convert the series public pages to React

MusicBrainz Server update, 2019-11-11

This release contains a new “Voting suggestions” page with some useful, predefined edit searches that ought to help editors find and review edits that need more attention.

We also have some minor improvements and display fixes, detailed below. The conversion of our template code to React slowly continues.

Thanks to cyna, chaban, and all others who tested or contributed to this release!

The git tag is v-2019-11-11.

Bug

  • [MBS-10264] – The date/time display format isn’t localized in some places
  • [MBS-10446] – Historic “Remove relationship” edits don’t display anything useful
  • [MBS-10447] – Historic “remove relationship” edits don’t fail properly if data is missing
  • [MBS-10460] – Remove alias edits don’t store “ended” info, always display “Ended: No”

New Feature

  • [MBS-10299] – “Voting Reports” (pre-set edit searches)

Task

  • [MBS-10389] – Add “Chat” or “IRC” link to footer
  • [MBS-10394] – Convert Add/Remove Alias edit to React
  • [MBS-10395] – Convert Edit Alias edit to React
  • [MBS-10440] – Remove series/delete
  • [MBS-10448] – Add the Dynamic Range Database to the other databases whitelist

Improvement

  • [MBS-3839] – Merge edit pages should have a way to remove some items
  • [MBS-10361] – Allow tabbing straight from edit note field to submit button
  • [MBS-10371] – Update the Songfacts logo used in the sidebar
  • [MBS-10382] – Explain what rename option does when merging
  • [MBS-10403] – Explain when a release should be removed / merging is preferred
  • [MBS-10456] – Show more info when entering artist merges

React Conversion Task

  • [MBS-10206] – Convert user profile to React

MusicBrainz Server update, 2019-10-28

You shouldn’t be afraid of this small release that fixes some bugs and delivers some improvements, making editors’ lives easier!

Thanks to Besnik, CatQuest, dkg, jesus2099, outsidecontext, zexpe, and everyone who tested the beta version, reported issues, or updated website localizations.

The git tag is v-2019-10-28.

Bug

  • [MBS-9468] – Edit search finds no “remove (download for free) relationship” edits
  • [MBS-10408] – Artists are not marked as pending in that recording merge edit
  • [MBS-10420] – My Data Menu’s “All My Edits” links to bogus URL
  • [MBS-10428] – WS: Recording request missing artist aliases
  • [MBS-10429] – Empty aliases element returned for artists in relationships
  • [MBS-10430] – Actions column for fingerprints wraps for translations

Improvement

  • [MBS-2176] – Add a “Finish” button alongside “Next” in release editor
  • [MBS-10356] – Replace <b> with <strong> in messages
  • [MBS-10425] – Allow instrument credits for relationships from/to instrument
  • [MBS-10431] – Remove ‘yourmusic’ from 7digital URLs
  • [MBS-10454] – Block removing an area still in use

MusicBrainz Server update, 2019-10-14

This post-summit release mostly contains bugfixes and small improvements for quality of life, along with continued conversion of templates to React.

Thanks to alastairp, andrebreiler, antonphoton, chaban, dibou, foolip, hibiscuskazeneko, jdamcd, jesus2099, mat813, mineo, okno, rochusw, silentbird, Skeebadoo, and everyone who tested the beta version, reported issues, or updated website localizations.

The git tag is v-2019-10-17-hotfixes.

Bug

  • [MBS-4980] – Releases on the same date aren’t sorted by catalog number
  • [MBS-5322] – Release group browse requests no longer return results in first-release-date order
  • [MBS-9111] – It’s still possible to leave empty edit notes
  • [MBS-10263] – Annotation not removed after it has been downvoted
  • [MBS-10344] – Navigating to artist/ or recording/merge with only 1 item in the queue ISEs
  • [MBS-10345] – /merge loads (brokenly) even if not ready to merge
  • [MBS-10346] – Table of collections has large table cell padding
  • [MBS-10353] – Enable ratings for release browse
  • [MBS-10369] – Database statistics for countries are wrong
  • [MBS-10406] – The WS can still sometimes try to communicate with the template renderer, timing out
  • [MBS-10411] – Inconsistent type for place coordinate
  • [MBS-10421] – Lookup of cluster in browser from Picard generates an server error
  • [MBS-10423] – Internal Server Error when trying to query by release language

Improvement

  • [MBS-3112] – TAB from “Edit note” doesn’t go to “Enter edit” in “Release editor”
  • [MBS-4486] – Disambiguation input field sanitation: Automatically remove leading and trailing parentheses
  • [MBS-4913] – Show how many CAA images we have for a release
  • [MBS-5083] – Release pages: Display recording artist on tracks (recording)
  • [MBS-5479] – Move “Edit relationships” to be a tab by “Edit” on releases
  • [MBS-8566] – Release artist should be selected automatically for all tracks with the same artist name (CD stub import)
  • [MBS-8967] – The duplicate events report should not show events if all of them have disambiguation comments
  • [MBS-10229] – Block smart links
  • [MBS-10240] – Allow specifying that a release has no barcode while seeding
  • [MBS-10347] – “Actions” columns should only take as much space as they need
  • [MBS-10349] – Clarify what “exclusive” vs “inclusive” means in relationship stats
  • [MBS-10355] – Display track artist on recording pages
  • [MBS-10363] – Cancelling merge on merge helper should stay in the same page
  • [MBS-10370] – Add `direction: forward` to all forward relationships in WS
  • [MBS-10373] – Link to How to Write Edit Notes above the edit note fields
  • [MBS-10404] – Limit the total number of tracks that can be returned in a WS release list
  • [MBS-10405] – Switch to XML::LibXML for serializing XML WS responses
  • [MBS-10407] – Add limit/offset parameters to /ws/2/discid

React Conversion Task

  • [MBS-9915] – Convert the artist public pages to React
  • [MBS-9920] – Convert the recording public pages to React
  • [MBS-9924] – Convert the work public pages to React
  • [MBS-10357] – Convert edit diff macros to React

MusicBrainz Server update, 2019-09-12

It’s time for another server update! This release mostly includes small improvements to make the MusicBrainz site show data in places where it was missing and have more clear messages for the users. We have a lot of other small improvements in the pipeline which we hope to release in the next couple of updates, so if this doesn’t help with any of your pet peeves hopefully those will!

Thanks to CatQuest, chaban, danbloo, demosdemon, eey0re, ianmcorvidae, ijabz, jesus2099, Lotheric, murdos, PeterCodar, $nake, SothoTalker for having reported issues, and to every single one of you who tested the beta version and updated website localizations.

The git tag is v-2019-09-12.

Bug

  • [MBS-4478] – Misleading messages when adding new entities through an edit
  • [MBS-10273] – Huge and weird spacing in front of the release year column on artist pages in beta
  • [MBS-10320] – Don’t wrongly nag local users of MB slave server
  • [MBS-10337] – ISRCs and ratings not shown when artist overview consists of recordings only

Improvement

  • [MBS-975] – Permanently (301) redirect from track/ to recording/
  • [MBS-4161] – List blog relationship type under the External links section
  • [MBS-4787] – Permanently (301) redirect http://musicbrainz.org/ns/mmd-2.0# to web service documentation
  • [MBS-5049] – Show edit note syntax help in edit page too
  • [MBS-10269] – Release editor: Open artist credits preview in a new window
  • [MBS-10280] – When deleting user, cancel open edits from newest to oldest
  • [MBS-10291] – Consider “、” as a delimiter when splitting featured artists
  • [MBS-10324] – Lowercase “Takes” with guess case
  • [MBS-10336] – Clarify disc.track on recording pages
  • [MBS-10338] – Show ratings on artists’ recording page

GSoC 2019: Recording Similarity Indexing for AcousticBrainz

For Starters… Who Am I?

My name is Aidan Lawford-Wickham, better known as aidanlw17 on IRC, and I’m entering my second year of undergraduate study in Engineering Science at the University of Toronto. This summer, I had the opportunity to participate in my first Google Summer of Code with the MetaBrainz Foundation. Working on the AcousticBrainz project under the mentorship of Alastair Porter (alastairp), I used previous work on measuring track to track similarity as the basis for a similarity pipeline using the entire AB database.

How Did I Get Involved?

When I started applying for GSoC, I needed to find an organization that paired a challenging learning environment with a project of personal interest. Given my own passion for listening to music, playing music, and exploring its overlap with culture, MetaBrainz quickly became my top priority. I jumped on the #metabrainz IRC channel for the first time, and I’ve been active daily ever since!

From there, the whole community welcomed me with open arms and responded thoughtfully to my questions about setting up my local development environment. I made my first pull request for AcousticBrainz, AB-387, which added the ability to include dataset and class descriptions when importing datasets as CSV files. This allowed me to work alongside my soon-to-be mentor for the first time and further acquaint myself with the acousticbrainz-server source code.

I was excited about my first PR and wanted to contribute more. Not only was this a project related to my passions, but it had already begun to teach me about technologies that I hadn’t used before. I was struck by the possibility to contribute more, and work with great people on a non-profit, open source project. I quickly decided that MetaBrainz was the only place I would apply for GSoC and began to think about proposals. I read through the previous work on recording similarity done by Philip Tovstogan, which was based upon a PostgreSQL solution with shortcomings in terms of speed. With a strong supporting background, high community interest, and my own dreams of the possibilities to come from predicting similar tracks, I created a proposal to build a similarity pipeline using Spotify’s nearest neighbours library, Annoy. The timeline and tasks shown on the full proposal were adjusted throughout the summer, but the general objectives were maintained. Looking back on the summer now, the basic requirements for the project were as such:

  • Using the previous work, define metrics for measuring similarity that will translate recording features from the AB database into vectors. Compute and store these vectors for every recording in the database.
  • Create an Annoy index for each of these metrics, adding the metric’s vector for each recording to the index.
  • Develop methods of querying an index, such as outputting nearest neighbours (similar recordings) to a specific recording or many recordings, or finding the similarity between two recordings.
  • Allow users to query the indices via an API.
  • Create an evaluation that allows us to measure the success of our indices in the public eye, fine tune our parameters, and display index queries via a graphical user interface.

Community Bonding Period

After losing sleep before the announcement, and a huge sigh of relief on May 6th, I was ecstatic to get started.

There was plenty of required reading, and I familiarized myself with the different elements of building similarity into AB. After discussing with Rob (ruaok) and Alastair and cementing our decision to use Annoy as the nearest neighbours algorithm of choice, I took to reading through Annoy documentation and making a small implementation to grasp the concepts. Annoy works blazing fast, and uses small, static files – these are points that would prove advantageous for us in terms of querying indices many times, as quickly as possible. Static index files allow for them to be shared across processes and could potentially make them simple to redistribute to others in the future – a major benefit for further similarity research.

I studied Philip’s previous work, gained an understanding of the metrics he used in his thesis, and reimplemented all of his code to better grasp the concepts and use them as a basis for the summer. Much of Philip’s work was built to be easily expandable, and flexible to different types of metrics. Notably, when integrating it with a full pipeline including Annoy, priorities like speed meant that we lost some of this flexibility. I found this to be an interesting contrast between the code structure for an ongoing research purpose, and the code ready to be deployed in production on a website.

All the while, I kept a frequent dialogue with Alastair to gel as a team, clarify issues with the codebase, and further develop our plans for the pipeline. To build on my development skills, learn more about contributing guidelines and source control, and improve the site, I worked on some exciting PRs during the bonding period. Most notably, I completed AB-406 over a series of 3 PRs, which allowed us to introduce a submission offset column in the low-level table to handle multiple submissions of a single recording. This reduced the need for complexity in queries to the API, decreasing the load on the server. Additionally, I added some documentation related to contributions and created an API endpoint that would allow users to only select specific features rather than an entire low-level document for a recording – aiming at reducing server load.

Last but not least, I got really involved with the weekly meetings at MB! We have meetings every Monday on #metabrainz to give reviews of the last week, and discuss any other important community topics. I love this aspect of the community. Working remotely, it creates a strong team atmosphere and brings us all a bit closer together – even if we’re living time zones apart. During one meeting, we discussed whether or not past GSoC proposals should be available to students. What do you think? This prompted me to share my own experience with the application process at MetaBrainz and look into if/how we could improve it.

… And so it began, we dove into the first coding period.

The Key Components, a Deeper Look

Computing Similarity Metrics

Having explored the previous similarity work from Philip, I used his definitions of metric classes and focused on developing a script to compute metrics for each recording in the database incrementally. Recognizing that we would also need a method of computing metrics for a single recording on submission, I made this script as open ended as possible. After successfully computing all metrics for the first time, we went through an iterative process of altering the logic and methodology to dramatically improve its speed. Ultimately, we used a query to get the batch of low-level recordings that haven’t had similarity computations, complete with their low-level data and all high-level models. Though we revised and found bugs in this script time and time again, I’m confident in saying that with perseverance we finally got it working.

Prior to the beginning of the project I had limited experience working with SQL databases, and this objective pushed me to develop new ways to approach problems, and gave me a much deeper understanding of PostgreSQL.

Building Annoy Indices

With all that vectorized recording data from the metrics computation, nothing sounds better than adding it to an ultra-fast index built for querying nearest neighbours! Feeding the data into an index and watching it output similar recordings in milliseconds became the most satisfying feeling. The Annoy library is a platform for nearest neighbours of all sorts, and it is generally simple: define the index, add items with an identifier and a vector, built the index, save it for later use, load it up, and then use its built-in methods to query for similar items. Easy, right? The added challenge is making this interface with recordings from our database as items, and meeting our needs in terms of speed and alterability when new items are added. Annoy is built without checks in many places, and we required a custom cycle of building, loading, and saving indices to ensure they were operable for our purposes (once an index is built, new items may not be added). At this point, the index model is open to saving new indices with different parameters, which allows us to tune as we further develop the pipeline.

After wrapping the index in a class that interfaced with our needs, we added scripts to build all indices and save them, and scripts to remove indices if need be. Currently, the project has 12 indices, one for each metric in use:

  • MFCCs
  • Weighted MFCCs
  • GFCCs
  • Weighted GFCCs
  • BPM
  • Key
  • Onset Rate
  • Moods
  • Instruments
  • Dortmund
  • Rosamerica
  • Tzanetakis

API Endpoints

Making API endpoints available was a high priority activity and was an exciting aspect of the project since it would allow users to interact with the data provided by a similarity pipeline. Using the index model, I created three API endpoints:

  • Get the n most similar recordings to a recording specified by an (MBID, offset) combination.
  • Get the n most similar recordings to a number of recordings that are specified (bulk endpoint).
  • Get the distance between two recordings.

For each endpoint, a parameter indicates the metric in question, determining which index should be used. Currently, the endpoints also allow varying index parameters, such as the distance type (method of distance calculation) and number of trees used in building the index (precision increases with trees, while speed decreases).

A full explanation of the API endpoints is documented in the source code.

Baseline Evaluation

As I said, an index can be altered using multiple parameters that impact the build speed, query speed, and precision in finding nearest neighbours. Assessing the query results from our indices with public opinion is a top priority, since it gives us valuable data for understanding the quality of similarity predictions. With the evaluation we will be able to collect feedback from the community on a set of similar recordings – do they seem accurate, or should a recording have been more or less similar? What recording do you think is the most similar? With this sort of feedback, we can measure the success of different parameters for Annoy, eventually optimizing our results.

Moreover, this form of evaluation provides a graphical user interface to interact with similar recordings, as a user-friendly alternative to the API endpoints. Written using React, it feels snappy and fast, and I feel that it provides a pleasing display of similar recordings. At this point in the project I was glad to accept a frontend challenge which differed from the bulk of my work thus far.

Documentation and Project Links

Similarity pipeline related:

Additional work:

Going Forward

This summer allowed for us to build on previous similarity work to the point of developing a fast, full pipeline. At this point, there is still a vast amount of work to be continued on the pipeline and I am eager to see it through. In the upcoming year I plan to continue contributing to AcousticBrainz and the MetaBrainz Foundation as a whole. These are areas that I’m interested in continuing to develop for the recording similarity pipeline:

  • Parameter tuning on Annoy indices
  • Adding more metrics to cover other recording features
  • Adding support for hybrid metrics that consider multiple features (this was started by Philip and should be integrated to provide more holistic similarity)
  • Making indices available for offline use
  • Creating statistics and visualizations of vectors for each metric

Wrapping Up

To say the least, this has been a highly rewarding experience. MetaBrainz is a community full of extraordinary, thoughtful, and friendly developers and enthusiasts. I will be forever thankful for this opportunity and the lessons that I gained this summer. I am so excited to meet everyone at the summit this September! I’d like to personally thank my mentor, Alastair Porter (alastairp), for his perceptive guidance, his support, his friendship, and his own contributions to the project. Thanks to Robert Kaye (ruaok) for his support, thoughts, and enthusiasm towards this project, as well as for his dedication to MetaBrainz. Thanks to Google for making this all possible – SoC is a highly unique opportunity to learn about open source software and make new connections! Cheers.

GSoC 2019: JSON Web API for BookBrainz

The time has come to wrap up the very productive and learning summer of the last 3 months as a GSoC student with MetaBrainz.

Hello Everyone!!

I am Akhilesh Kumar, a recent graduate from the National Institute of Technology, Hamirpur, India. I have been working on BookBrainz for MetaBrainz Foundation Inc. as a participant in the Google Summer of Code ’19. It has been an amazing experience and I’ve learned a lot over the summer. I was mentored by Nicolas Pelletier (Mr_Monkey on IRC) during this period. This post summarizes my contributions to the project and the experiences that I had throughout the summer.

Continue reading “GSoC 2019: JSON Web API for BookBrainz”

MusicBrainz Server update, 2019-08-22

Here is our summer vacation homework for the MusicBrainz Server: mainly improving the Guess Case tool, fixing a fair amount of bugs and continuing the migration of templates to React.

Thanks to ferbncode for fixing the Dockerfile that creates a test database. Thanks also to acid2, alastairp, bort27, brianfreud, CatQuest, chaban, cyberskull, florentl, fmera, foolip, hibiscuskazeneko, Jeluang, liftarn, michelv, mineo, murdos, paulakreuzer, PoQStacker, tommycrock, yindesu, zexpe, and everyone who tested the beta version, reported issues, or updated website localizations.

The git tag is v-2019-08-22.

Bug

  • [MBS-2614] – Vote on edits shows expired edits
  • [MBS-5338] – Guess Case doesn’t seem to recognize roman numerals above 10
  • [MBS-5755] – English/Katakana is incorrectly classified as “unlikely language/script pair”
  • [MBS-6087] – Relationship edits for recordings don’t show up on the release edit list
  • [MBS-9028] – Wikidata link makes fetch english blurb even though resulting page is a redirect
  • [MBS-9657] – Remove “with” from Guess Case at the end of a track title
  • [MBS-9837] – Regression: Guess Case button lowercases “Ya” in English
  • [MBS-9976] – ISE on ISWC report when works have been merged away
  • [MBS-10134] – Browse query with incorrect parameters gets submitted to the search server
  • [MBS-10137] – Guess feat button doesn’t change AC on recording pages
  • [MBS-10162] – Alias seemingly ignored for recording, release and RG direct searches
  • [MBS-10250] – User profile link on Spotify shows up as “Stream at Spotify” on the external links bar
  • [MBS-10260] – Video attributes for URL relationships can’t be removed in release editor
  • [MBS-10274] – Docker: musicbrainz-test-database container fails to start
  • [MBS-10278] – Artists with members listed in PossibleCollaborations if they also have other rels

Improvement

  • [MBS-1679] – Don’t display Merge Process in release editor
  • [MBS-2250] – Go back when cancelling merge
  • [MBS-3848] – Guess Case: Support for additional common ETI phrases
  • [MBS-3920] – Extend the “Titles with Featured Artists” reports
  • [MBS-7421] – Properly capitalize iWhatever-like when guessing case
  • [MBS-8065] – Stop Guess Case needlessly standardising “aka”
  • [MBS-8521] – Allow work-level-rels in browse recording request
  • [MBS-8865] – Lower case “rmx” just as “remix”
  • [MBS-9855] – Generalize NotFound templates to one general file
  • [MBS-9981] – Consider “conductor” and “founder” relationships when reporting Artists that may be collaborations
  • [MBS-10143] – Allow querying for tags/genres on discid WS requests
  • [MBS-10156] – Lowercase “remode” and “re‐mode” in ETIs when guessing case
  • [MBS-10161] – Lowercase mono/stereo/quadraphonic in parentheses when guessing case
  • [MBS-10262] – Indicate to user that new RG will be created if RG field is left empty
  • [MBS-10287] – Count tracks (rather than recordings) when determining top work artists
  • [MBS-10315] – Add the LyricWiki icon to links in the sidebar

New Feature

  • [MBS-2663] – Search for edits by non-subscribed entity
  • [MBS-6791] – Search for edits made by beginners

React Conversion Task

  • [MBS-9916] – Convert the event public pages to React
  • [MBS-9918] – Convert the label public pages to React
  • [MBS-10087] – Convert doc pages to React
  • [MBS-10116] – Convert the recording index page to React
  • [MBS-10201] – Convert artist works tab to React
  • [MBS-10202] – Convert artist relationships tab to React

Other Task

  • [MBS-10313] – Reenable CAA images on the homepage for Chrome-based browsers

MusicBrainz Server update, 2019-08-08

This summery release brings one main new feature: collaborative collections! As an editor, you can now share your collections with others. This is mainly intended for community projects, but it can also be a good way to, say, have a shared “Music we have at home” collection with your family, or collect artists with funny names with your friends. You decide how to use it!

To add collaborators to your collections, edit the collection and enter the editors you’d want as collaborators in the appropriate section (suggestion: ask first whether they’re interested, then add them!). Once they’ve been added as collaborators, they’ll be able to add and remove entities from the collection in the same way as you, but they won’t be able to change the title / description: that’s still only for the collection owner to change.

CDs collection shared as a cloak for everyone to see

The release also comes with a bunch of small improvements and bug fixes, including a couple about collections, and continues migrating to React.

Thanks to Ge0rg3 and sothotalker for their contributed code. Also, thanks to chaban, chiark, cyberskull, Dmitry, hibiscuskazeneko, jesus2099, Lotheric, mfmeulenbelt, psychoadept and everyone who tested the beta version, reported issues, or updated the website translations.

The git tag is v-2019-08-08.

Bug

  • [MBS-8867] – Guess Case normalizes “C’mon” as “C’Mon”
  • [MBS-9512] – Changing recording name to empty string should not be allowed
  • [MBS-10100] – ISE without “non-required” attributes for admin/attributes/Language/create
  • [MBS-10133] – Error message when sending an empty query to the WS is unclear
  • [MBS-10212] – SoundCloud URL with trailing slash is not displayed with user name in artist sidebar
  • [MBS-10218] – Regression: Cover Art tab not selected / highlit on release page
  • [MBS-10233] – Regression: ISE when trying to cancel a “add release annotation” edit

Improvement

  • [MBS-8569] – Don’t display ended legal names in the overview page for artists
  • [MBS-9381] – Show user’s own private collections in the list of collections for an entity
  • [MBS-10135] – Support WikiaParoles as its own site rather than LyricWiki
  • [MBS-10139] – Clarify why recording lengths can’t be edited when non standalone
  • [MBS-10210] – Only allow allowed frequencies in language admin form
  • [MBS-10215] – Make ISO number required for script admin form
  • [MBS-10217] – Explain what renaming artist credits does when editing artist
  • [MBS-10219] – Add Muziekweb to other DBs whitelist, with sidebar display
  • [MBS-10222] – Pull legal name alias instead of legal name artist for the relationship Artist-Artist “perform as/legal name”
  • [MBS-10224] – Don’t show the same legal name string multiple times in artist overview
  • [MBS-10246] – Don’t assume all event collections are attendance lists
  • [MBS-10272] – Convert the header / navbar to Bootstrap

New Feature

  • [MBS-8915] – Allow editors to choose delimiter in track parser
  • [MBS-9428] – Allow multiple users to share one collection

React Conversion Task

  • [MBS-9914] – Convert the area public pages to React
  • [MBS-10047] – Convert /oauth2/ pages to React

Other Task

  • [MBS-10131] – Update LyricWiki domain to lyrics.fandom.com

MusicBrainz Server update, 2019-06-30

Today’s release contains some new features/improvements to the web service, several entity index pages being rewritten in React, and tweaks to the edit expiration wording to make it less confusing. See the tickets below for more details.

Thanks to kepstin for helping test the new CORS / OPTION support in the web service.

We’ve also released a number of new changes to the beta server (which as a reminder uses the live, production database), particularly collaborative collections, if you’d like to help test those!

The git tag for today’s release is v-2019-06-30.

New Feature

  • [MBS-10124] – Allow to browse recordings linked to a given work through web service

Improvement

  • [MBS-6033] – Allow CORS preflights
  • [MBS-6072] – WS: Answer OPTION requests
  • [MBS-9732] – Change “expires in” wording/phrasing
  • [MBS-10197] – Remove unneeded data quality edit code

React Conversion Task

  • [MBS-9923] – Convert the URL public pages to React
  • [MBS-10105] – Convert the instrument index page to React
  • [MBS-10106] – Convert the place index page to React
  • [MBS-10122] – Convert the event index page to React