Kartik Ohri joins the MetaBrainz team!

I’m pleased to announce that Kartik Ohri, AKA Lucifer, a very active contributor since his Code-in days in 2018, has become the latest staff member of the MetaBrainz Foundation!

Kartik has been instrumental in rewriting our Android app and more recently has been helping us with a number of tasks, including new features for ListenBrainz, AcousticBrainz as well as breathing some much needed life into the CritiqueBrainz project.

These three projects (CritiqueBrainz, ListenBrainz and AcousticBrainz) will be his main focus while working for MetaBrainz. Each of these projects has not had enough engineering time recently to sufficiently move new features forward. We hope that with Kartik’s efforts we can deliver more features faster.

Welcome to the team, Kartik!

Incident report: January 27th service outage

On January 27th, starting at 4:31UTC we were hit with increasing amounts of traffic from what appeared to be hundreds of different IP addresses mostly belonging to Amazon Web Service IP addresses. At 8:46UTC the inbound traffic overwhelmed our systems and brought nearly all of our services to a standstill.

After investigating the situation and receiving no meaningful assistance from Hetzner (our ISP who advertises DDoS mitigation services as part of their offerings) we blocked three subnets of IP addresses in order to restore our services. At 13:14UTC we put the block in place and our services started recovering.

We reported the issue to Hetzner and to AWS shortly after restoring our service. The next morning we received a friendly email from Andy, who works for one of our supporters at Plex, stating that they received a complaint from AWS. What happened next and how this matter was resolved is told by Andy himself:

Overnight on Wednesday, first thing Thursday morning, we received an abuse report that our servers were flooding an IP that corresponded to musicbrainz.org. We scrambled to investigate, as we are happy MusicBrainz partners, but it was a strange report because we run our MusicBrainz server and hit that instance rather than communicating with musicbrainz.org directly. And the IPs mentioned were specifically related to our metadata servers, not the IPs that would be receiving data updates from upstream. Just as some of our key engineering team members were starting to wake up and scrub in, it started to seem that it was a coincidence and we weren’t the actual source of the traffic and had simply been caught up in an overeager blocking of a large IP range to get the services back up. Never trust a coincidence. We continued to stay in touch with the team at MusicBrainz and within a few hours we had clear evidence that our IPs were the source of the traffic. We got the whole engineering team involved again to do some investigation, and we still couldn’t figure much out since we never make requests to musicbrainz.org and we had already worked to rule out the potential of any rogue access to our servers. By isolating our services and using our monitoring tools, we finally discovered that the issue was actually our traffic to coverartarchive.org, not musicbrainz.org, as they happen to be serviced by the same IP address. And this made much more sense, as we do depend on some API calls to the Cover Art Archive.

The root cause was an update to the Plex Media Server which had been released earlier in the week. There was a bug in that update that caused extra metadata requests to our own infrastructure. We had noticed the spike in our autoscaling to accommodate the extra traffic and already put together another update to fix the bug. That extra traffic on our infrastructure also translated to a more modest increase in requests to some of our metadata partners, including CAA. While the fix was already rolling out to Plex Media Servers, this provided a good opportunity to evaluate the CAA traffic and put our own rate limit in place to protect against future issues. We wrapped up that change in the afternoon on Thursday.

Throughout the ordeal, we appreciated the communication back and forth with our partners at MusicBrainz so that we could work together to investigate and follow leads to find a timely resolution.

Andy from Plex

While this whole situation was very stressful and frustrating to us, in the end it was resolved by a very friendly and technical detective game to identify and resolve the issue. It is always nice when geeks talk to geeks to resolve issues and get services working again. Thank you to Andy and his team — let’s hope we can avoid an issue like this in the future.

We’d apologize for the trouble caused by our IP address block and for our services being unavailable for several hours.

EDIT: We should also mention that all of our services are served from one single gateway IP address, so coverartarchive.org and musicbrainz.org have the same IP address.

MetaBrainz Projects in the news

During the summit this past weekend we talked about posting more updates to our blog. In the spirit of that, I wanted to share two articles where MusicBrainz and AcousticBrainz were recently mentioned in the news: In July the BBC wrote an article covering research from UC Irvine in California:

They found a significant downturn in the positivity of pop songs. Where 1985 saw upbeat tracks like Wham’s Freedom, 2015 favoured more sombre music by Sam Smith and Adele.
The UC Irvine research team analyzed the publicly available data from AcousticBrainz to arrive at this and several other conclusions.

This wasn’t the first time that our project was used to analyze music trends over time and we’re proud that researchers can carry out this kind of work on our public data. In October Insead Knowledge wrote about the gender gap in the music industry:

We also used song credit information from crowdsourced database MusicBrainz to determine how many women and men worked on the writing, production and performance of each song. . . . At first glance, our overall results appear quite simple. In line with past research on creativity, we find no baseline relationship between the novelty of the songs in our sample and the gender identity of the artists involved. Men and women appear to be equally capable in terms of creativity. But when we controlled for genre and, importantly, the gender composition of artists’ genres, the picture changed. Our methods were guided by an awareness that women in music work in a different context than men do: By a kind of gender-slanted gravitational pull, the music industry drives women into certain genres (e.g. pop) and collaborative networks.
We’ve long known about gender imbalances in the music industry and while we’re happy that people are using our data to demonstrate this, we’re dismayed at most of the findings in this article. What is more concerning is that we have a general impression that our community has a slight bias towards adding more information about music created by women, which means that the overall situation may actually be worse than what one can deduce from our data!

As a reminder, all data in MusicBrainz is contributed by members of the community. If you see any situations where women or minorities are being mis- or underrepresented, we encourage you to add this content to MusicBrainz. And if you get stuck, don’t hesitate to ask for help on the forums.

Migration to TimescaleDB complete!

Yesterday I posted about why we decided to make the switch to TimescaleDB and then later in the day we actually made the switch!

We are now running a copy of InfluxDB and a copy of TimescaleDB at the same time — in case we find problems with the new TimescaleDB database, we can revert to the InfluxDB database.

In the process of migrating we got rid of a pile of nasty duplicates that used to be created by importing from last.fm. We also got rid of some bad data (timestamp 0 listens) that were pretty much useless and were cluttering the data. If you find that you are missing some data besides some duplicates, please open a ticket.

The move to TimescaleDB allows us to create new features such a deleting a listen (which should be released later this summer) and various other features that because the underlying DB is much more flexible than InfluxDB. However, right this second there are no real new features for end users — more new features are coming soon, we promise!

Thank you to shivam-kapila, iliekcomputers and ishaanshah — thanks for helping with this rather large, long running project!

ListenBrainz moves to TimescaleDB

The ListenBrainz team has been working hard on moving our primary listen store from InfluxDB to TimescaleDB, and today at UTC 16:00 we’re going to make the switch.

We were asked on Twitter as to why we’re making the switch — and in the interest of giving a real world use case for switching, I’m writing this post. The reasons are numerous:

Openness: InfluxDB seems on a path that will make it less open over time. TimescaleDB and its dependence on Postgres makes us feel much safer in this regard.

Existing use: We’ve been using Postgres for about 18 years now and it has been a reliable workhorse for us. Our team thinks in terms of Postgres and InfluxDB always felt like a round peg in a square hole for us.

Data structure: InfluxDB was clearly designed to store server event info. We’re storing listen information, which has a slightly different usage pattern, but this slight difference is enough for us to hit a brick wall with far fewer users in our DB than we ever anticipated. InfluxDB is simply not flexible enough for our needs.

Query syntax and measurement names: The syntax to query InfluxDB is weird and obfuscated. We made the mistake of trying to have a measurement map to a user, but escaping measurement names correctly nearly drove one of our team members to the loonie bin.

Existing data: If you ever write bad data to a measurement in InfluxDB, there is no way to change it. I realize that this is a common Big Data usage pattern, but for us it represented significant challenges and serious restrictions to put simple features for our users into place. With TimescaleDB we can make the very occasional UPDATE or DELETE and move on.

Scalability: Even though we attempted to read as much as possible in order to design a scalable schema, we still failed and got it wrong. (I don’t even think that the docs to calculate scalability even existed when we first started using InfluxDB.) Unless you are using InfluxDB in exactly the way it was meant to be used, there are chances you’ll hit this problem as well. For us, one day insert speed dropped to a ridiculously low number per second, backing up our systems. Digging into the problem we realized that our schema design had a fatal flaw and that we would have drastically change the schema to something even less intuitive in order to fix it. This was the event that broke the camel’s back and I started searching for alternatives.

In moving to TimescaleDB we were able to delete a ton of complicated code and embrace a DB that we know and love. We know how Postgres scales, we know how to put it into production and we know its caveats. TimescaleDB allows us to be flexible with the data and the amazing queries that can be performed on the data is pure Postgres love. TimescaleDB still requires some careful thinking over using Postgres, it is far less than what is required when using InfluxDB. TimescaleDB also gives us a clear scaling path forward, even when TimescaleDB is still working on their own scaling roadmap. If TimescaleDB evolves anything like Postgres has, I can’t wait to see this evolution.

Big big thanks to the Postgres and TimescaleDB teams!

The ODI publishes two reports on Sustainable Data Institutions

The Open Data Institute has just published two reports: Designing Sustainable Data Institutions and Designing Trustworthy Data Institutions which include insights provided by us regarding our MusicBrainz project.

When I was starting out MusicBrainz and was trying to work out how to make the project sustainable, I would’ve given just about anything to have access to these reports. I am proud that, nearly 20 years later, I was able to contribute to these reports so that others may benefit from our hard work.

I find the section Suggestions for those scoping, designing and running data institutions on page 40 of the PDF version of Designing Sustainable Data Institutions quite enlightening:

  1. Ensure your revenue model aligns with your organisational goals
  2. Understand how your revenue sources will change during your institution’s lifecycle
  3. Consider both financial and non-financial aspects of sustainability
  4. Identify and mitigate future risks
  5. Learn from others

Each of these points represent a whole collections of small lessons that I’ve learned by (often painful) experience of the past years. Also, I feel that these points are not strictly limited Data Institutions, but many also apply to making open source projects sustainable. If you’re in the business of running a data or open source organzation, I would strongly encourage you to read this paper!

Also very interesting is the second report about Designing Trustworthy Data Institutions:

For example, the representative from MusicBrainz said, “[A culture of honesty] builds trust, and this trust builds sustainability”

Compared to sustainability, the concepts of trust were much more clear to me from the beginning. However, that doesn’t make this report any less relevant — especially in current times, I welcome an emphasis on trust!

Thank you to the ODI for including MusicBrainz and doing all of the hard work on these reports!

 

ListenBrainz release 2020-03-28

We’ve just finished pushing a new release to the production server for ListenBrainz. We’ve spent quite a long time working on this because we needed to completely revamp how we were generating user statistics and that process is now finally complete and live. The other good news on user statistics it that we now have a generalized framework for creating them and that should make it much easier to create more user statistics going forward. We’ve triggered the stats engine to produce updated top artist statistics for everyone and those should update for users automatically sometime later today.

This release also includes an improved importer from last.fm, moving it to react and making it more friendly on a mobile device. This particular feature hasn’t been super well tested, so if you find a problem, please submit a bug report.

Next, if your listening history is screwed up for some reason, you can now delete all listens and start over, perhaps with a clean import from last.fm.

Finally, this release includes a pile of security updates to make the overall system more secure, but users shouldn’t notice anything different.

Thank you to iliekcomputers, Mr_Monkey, ishaanshah[m], shivam-kapila, pristine__ and everyone else who was involved in creating this update!

Welcoming Paula LeDieu to our board of directors!

Late in 2019, we finally filled our one vacant spot on our board of directors — we had been holding out until we found the right person and we finally have! And then towards the end of the year we all got distracted by holidays and world events and never got around to formally announcing that we have a new addition to our board.

With great pleasure I would like to announce that Paula LeDieu, an amazingly connected person who seems to know everyone, has joined the MetaBrainz Foundation Board of Directors! I first met Paula when I was bootstrapping MusicBrainz and pondering how to setup a foundation for the project — we would continuously bump into each other at various conferences in the world. Paula’s professional history includes a lot organizations that early on shaped the internet, including the BBC, iCommons and Mozilla. Paula’s professional experience and connections will be a great asset to our organization.

Paula lives in Sydney, Australia, stretching our board of directors across 3 continents and far too many time-zones. Thank you for agreeing to join our board of directors and welcome to the team, Paula!

Upgrading Postgres instead of schema change: 18 May, 2020

Hello!

We’ve long procrastinated upgrading our production Postgres installation and we’ve decided to forego a schema change upgrade and instead upgrade Postgres to version 12.x. (We will migrate to whatever the latest stable version in the 12.x series will be).

This means that on 18 May we will not make any changes to the MusicBrainz schema, but  we will have some amount of down-time and/or read-only time while we upgrade Postgres on our production servers. We haven’t sorted out all of the exact details of how we will carry out this database upgrade, but the date is now confirmed.

If you operate a replicated instance of the MusicBrainz database we STRONGLY urge you to upgrade your installation shortly after we upgrade the production servers. After this release our team may start using Postgres features not available in Postgres 9.5.x, which is our current production version.

As usual for our releases that impact our downstream users, we will post many more details closer to the date and once the migration is complete, we will post detailed instructions on how you can upgrade your own installation.

Please post any questions you may have!

Thanks!

Thank you for your continued support, Google!

We’ve recently received our annual $30,000 support from Google. The brings the total amount donated by Google’s Open Source Programs Office to us to over $470,000 — hopefully next year we’ll cross the half million dollar threshold!

I can’t quite express my gratitude for this level of support! Without Google’s help, especially early on, MetaBrainz may never have made it to sustainability. Google has helped us in a number of ways, including Google Code-In and Summer of Code — all of these forms of support have shaped our organization quite heavily over the past 15 or so years.

Thank you to Google and everyone at the Google Open Source Programs Office — we truly appreciate your support over the years!