We’re hopefully back to a normal schedule after the crazy relationship editor testing period! That means we have the usual small amount of bug fixes and improvements this time, including a couple further fixes for small issues of said relationship editor which were not found during beta testing. We also have a text version of the list of historical MusicBrainz events that could only be seen before as bars on our timeline – which hopefully will help remind us to actually update that with new events on a regular basis.
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to CatQuest, chaban, mr_maxis, satanisch_opium, sound.and.vision and yyoung for having reported bugs and suggested improvements. Thanks to salo.rock and an anonymous Albanian translator for updating the translations. And thanks to all others who tested the beta version!
This release mostly consists of small bug fixes and improvements. One bigger bug fix (MBS-12497) involves an issue where it was impossible to apply any edit which would cause an artist credit with any redirects pointing to it to be removed. Sorry about your stuck edits, people! They should now pass.
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to chaban, HibiscusKazeneko, jesus2099, Mineo and sammyrayy for having reported bugs and suggested improvements. Thanks to ikerm2003 and salo.rock for updating the translations. And thanks to all others who tested the beta version!
This is a small release since we’ve been resting (and sometimes fully on holiday) for the summer. The most visible change for website users is that the “Ratings” tab for ratable entities is now a “Reviews” tab, and it also includes ratings and reviews from CritiqueBrainz. We used to only display these for release groups – now you can see them for every entity that supports reviews (artists, events, labels, places, recordings, release groups and works). We’re hoping having this reminder that things can be reviewed will encourage more users to have a say and let us know about their favourite – or less favourite – music!
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to chaban and rdswift for having reported bugs and suggested improvements. Thanks to mfmeulenbelt and salo.rock for updating the translations. And thanks to all others who tested the beta version!
This release is very small, mainly consisting of minor improvements related to genre relationships. We have quite a few of those now, including links to Wikidata and Rate Your Music for pretty much any genre that has matching entries in those sites and links between many genres and their country of origin. We’re also fixing one bug with event setlist display that had probably been there since we introduced events – whoops!
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to chaban and sound.and.vision for having reported bugs and suggested improvements. Thanks to mfmeulenbelt, outsidecontext and salo.rock for updating the translations. And thanks to all others who tested the beta version!
This is a small release in number of tickets, but it finally adds the functionality to add relationships to genres. As such, you can now find out what għana or harsh noise wall actually are by simply reading their Wikipedia extracts. We can also store aliases for genres now, so while we still don’t do anything with that information directly, we do indicate that “hiphop” and “hip-hop” are alternative ways to write “hip hop“. Eventually, the plan is to combine these with the main genre in smart ways.
NB: As a side effect of adding new edit types for genres and genre aliases, the daily subscription emails failed for a few days. After this release the emails are working again, and you should have received the edits for all the missing days in your first email after the update.
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to chaban and selflessself for having reported bugs and suggested improvements. Thanks to Mellthas, mfmeulenbelt, rinsuki and salo.rock for updating the translations. And thanks to all others who tested the beta version!
This release includes the first genre improvements made possible by the May schema change, plus a bunch of small fixes and improvements. Annotation pages have been converted to React; if you notice anything strange with annotations, it might be a new regression so make sure to report it!
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to anshuman73, chaban, Lotheric, selflessself and yindesu for having reported bugs and suggested improvements. Thanks to mfmeulenbelt and salo.rock for updating the translations. And thanks to all others who tested the beta version!
We’re back after a bit of post-schema change rest! Because we were recovering from the crazy schema change times, there’s mostly small fixes here. Two changes (the update to React 18 and the change to allow some very long words to wrap) caused a few issues that were found and fixed in beta, but please do let us know if you find any that slipped through! The implementation of some remaining schema change features (more genre options, moods) will hopefully be released in two weeks.
Thanks to adamselene, CatQuest, chaban, darwinx0r, draconx, Jeluang, sheamuspatt, vzell and yindesu for having reported bugs and suggested improvements. Thanks to mfmeulenbelt and salo.rock for updating the translations. And thanks to all others who tested the beta version!
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
We’re happy to announce the release of our May 2022 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers, and thanks to ikerm2003, mfmeulenbelt rinmon and salo.rock for updating the translations.
This is once again a fairly minor release as far as schema changes go, but please do report any issues that you come across, especially related to the propagation of ratings and tags.
New, user-facing changes with this release include withdrawn-only release groups showing in the official overview again (MBS-12208) and the final disappearance of Amazon cover art (MBS-12200). To this regard, the report of releases that have Amazon cover art but no Cover Art Archive front cover will stay available for editors to check their subscribed entities.
Additionally, several small changes will allow, in the next couple of releases, to store more information about genres (including URL relationships) and to recognize and special-case mood tags (MBS-12190). Another new feature that will start to be used in the API and artist credit pages is the addition of MusicBrainz IDs for artist credits, which allow referring to them with a unique and more persistent ID (MBS-11456). Finally, a few more under-the-hood only changes are made, which should ensure better performance for finding artists, events, etc. for all areas contained in a given one, and less bugs when adding and changing tags and ratings.
The area containment changes make use of a new materialized table. Like the ones we added last year, this table isn’t dumped nor replicated, since it is derived entirely from primary table data. Rather, it will be created during migration (or, in a new install, by running the admin/BuildMaterializedTables script) and triggers will be added to keep it up-to-date once it has been built. These triggers are created on replicated servers, too.
The accompanying new version of the search index rebuilder brings performance improvements for both the main server and mirrors, and simplifies maintenance. See the release notes for details.
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
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 git tag is v-2022-05-16.1-schema-change. The rest of the instructions here assume an in-place upgrade.
Make sure DB_SCHEMA_SEQUENCE is set to 26 in lib/DBDefs.pm.
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 #27, but the database is currently at #26.”
Take down the web server running MusicBrainz, if you’re running a web server.
Turn off cron jobs if you’re automatically updating the database via cron jobs.
If you’re using the live search indexing, stop it and, assuming sir is under the same directory as musicbrainz-server, run cd ../sir && python2.7 -m sir triggers && cd - && ./admin/psql < ../sir/sql/DropTriggers.sql && ./admin/psql < ../sir/sql/DropFunctions.sql
Switch to the new code with git fetch origin followed by git checkout v-2022-05-16.1-schema-change.
Run cpanm --installdeps --notest . (note the dot at the end) to ensure your perl-based dependencies are up to date.
Run ./upgrade.sh (it may take a while to vacuum at the end).
Set DB_SCHEMA_SEQUENCE to 27 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh.
If your REPLICATION_TYPE is set to RT_SLAVE, change it to RT_MIRROR. (The previous terminology will work for the time being, but is now deprecated.)
If you’re using the live search indexing, assuming again that sir is under the same directory as musicbrainz-server, run cd ../sir && git fetch origin && git checkout v3.0.1 && python2.7 -m sir triggers && cd - && ./admin/psql < ../sir/sql/CreateFunctions.sql && ./admin/psql < ../sir/sql/CreateTriggers.sql and rebuild indexes which takes hours (by running cd ../sir && python2.7 -m sir reindex && cd -) then start it in watch mode (with cd ../sir && git fetch origin && git checkout v3.0.1 && python2.7 -m sir amqp_watch)
Turn cron jobs back on, if applicable.
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 ./script/compile_resources.sh.
Here’s the list of resolved tickets:
Fixed Bug
[MBS-5359] – *_tag tables are corrupt and need to be regenerated
[MBS-11760] – Removing the last use of a tag does not always remove the tag
[MBS-12369] – Standalone databases may be missing foreign keys for the documentation schema
We’re back with another smallish release, mostly fixing minor bugs. This is our last release before the schema change on May 16; we are taking a one release break to have more time to concentrate on that. Of course you should still let us know if you find we have introduced any new bugs (er… totally intentional easter eggs that is!), but unless they are very serious, we will probably only fix them during the second half of May.
A new release of MusicBrainz Docker is also available that matches this update of MusicBrainz Server. See the release notes for update instructions.
Thanks to arcresu, chaban and Cyberskull, for having reported bugs and suggested improvements. Thanks to mfmeulenbelt and salo.rock for updating the translations. And thanks to all others who tested the beta version!
As you all know, making our projects better every time takes a ton of work. For years, we’ve done an amazing job of combining individual users’ donations and commercial data users’ financial support to be a sustainable non-profit which finishes almost every year in the black (see our financial reports), which is quite the achievement when even tons of commercially successful companies lose money every year and only survive through new investment. That said, IT is a very competitive field and we can’t pay the most competitive wages, since we’re still a relatively small non-profit. That means we keep losing some of our talented engineers to large companies who can afford to treat them a lot better. After years of this, we’ve decided we need to find additional sources of income.
During the last couple years we’ve been following with growing interest the talk about Web3 and specifically Music3, and how it has become a great way of giving users something they really want and enjoy while raising significant amounts of money in the process. As such, we’ve taken a historical decision: We’re going to sell NFTs of MusicBrainz artist pages! (and book people, don’t worry; if the reception is as positive as we expect, we will expand this to BookBrainz author pages to help finance and accelerate the development of BookBrainz).
If you purchase an NFT of a MusicBrainz artist page, you’ll not only get the NFT itself, but you will get credited on the artist page so that everyone knows that you supported us by purchasing the NFT (and, of course, so that they know who to contact if they want to make you an offer to buy it for themselves). We will track any resales and update the displayed name accordingly.
We can already announce the system we’re planning to use for determining the starting sale price for the NFTs: we will base it on the ListenBrainz count of listens for that specific artist (see the stats for the top artists). For example, given that Radiohead have (as of now) around 840,000 listens, while Def Leppard have around 84,000, we would set the starting price for the Radiohead NFT around 10 times higher than the Def Leppard one. Of course, that’s just the starting price, and resale prices will likely depend also on the specific buyer’s music tastes! We are still working on deciding what the cost-per-listen will be, but expect a new post with more details about pricing soon. You’ll notice this also means that the more usage ListenBrainz gets, the higher the prices; this is intentional, and we expect that this system where the income grows as ListenBrainz does too will help us scale the development as needed.
How will you be able to purchase our NFTs? We weren’t really satisfied with any of the available options, and we want to be in control of the whole process, so we’ve teamed with a group of blockchain experts to build our own blockchain, which we’re naming Ricast. We are aware of the large environmental impact of the most common proof-of-work blockchains, so since we’re an environmentally conscious organization who was never gonna run around and desertify the planet, the Ricast blockchain will operate on a proof-of-stake (PoS) consensus mechanism, which has significantly lower environmental issues. Our PoS NFTs will allow you to support MetaBrainz without feeling bad about it! We will give more details about the Ricast blockchain in a further, more technical post, so for the geekier of you, stay tuned! Together with the Ricast blockchain, we will also be launching its accompanying coin, the rollcoin.
We’re hoping this is a huge success, because it would really help us hire more full time developers to give our users all the new features they’ve asked for for years (and some we know they’re aching for, but have been too shy to say it). We’ve known each other for so long, and we really want to take this relationship to a new level. Trust us, and we’re never gonna let you down!
As a final teaser, here’s the icon for our new coin, the rollcoin:
We understand some of you might be skeptical about this whole idea, whether for technical or ethical reasons. Our founder Robert Kaye goes deeper into our reasons for doing this and why we think it’s the right decision for us at this moment in this video. If you’ve watched it and your doubts are still not assuaged, feel free to start a discussion in the comments below! Don’t worry, we would never tell a lie nor hurt you.