ListenBrainz: Our new follow page

As promised, here is another blog post about the exciting new Follow page. The goal of this page is to finally make use of the data we collect in ListenBrainz and expose a new feature designed to let our users discover more music.

To use this new feature, you’ll need to link your Spotify account to ListenBrainz. Ideally you should give permission to record your listens and to play Spotify content. But if you’re not ready to dive into recording your listens, start with playback first. N.B. In order to really take advantage of this new feature, you’ll need a premium Spotify account.

Then head over to the recent listens page and hover over the tracks that are listed there. If the user listened on Spotify, then a play button will appear and you can listen to the track. Please note that playing from this page will interrupt whatever you’re already playing on Spotify. If you find that a user is listening to interesting music and you’d like to follow the user, head to the follow page and use the Follow Users section to add this user to your follow list.

When a user in your follow list finishes listening to a track, that track will appear as a line in the Playlist. In theory, you’ll be able to keep listening to what your followed users are playing: the player will attempt to play as many tracks as it can play and to keep the music going. The player also has a previous and next track button that allows you to easily skip tracks that you don’t like. Our team has found this feature exciting and to some extent even has started DJing for each other!

We’re pushing into new territory trying to offer music discovery features and trying out new features that we’ve not seen before. Expect bugs, missing features, and reactions of “why didn’t they do X?”. To be honest, we’re not entirely happy with it and we know that there are features missing. But we felt it important to push this out in order to start getting feedback from you — and we are also excited about the Spotify integration! That said, please continue reading and if you feel that we screwed something up, please open a ticket!

Also, keep in mind that we’re pushing against the tide of the music industry. Established players want to keep everything closed, controlled and in their silo (Apple Music, Tidal, etc). Spotify is slightly more open and allows us to record user’s histories and music playback from web pages, so we focused on working on Spotify first.

This has the unfortunate side-effect of making these new features useful only if you have a premium Spotify account, and following users who are not on Spotify is useless: we don’t know how to play this content. This blows — we know it and we hate it ourselves. But we needed to start with something to show what we’re trying to do and to generate some interest. If people are interested, we can start working in supporting more services and making more of the music in our pages playable.

Finally, the recording user’s listens API endpoint at Spotify has an annoying tendency to fall behind sometimes, which means that the flow of listens from Spotify slows or stops altogether, which is… less than ideal. We’re prodding Spotify to keep the bits flowing if at all possible, but know that all of this is a work in progress.

In fact, the release has already generated a flurry of fixes that we’ll push live before too long. A lot of these sorts of fixes are for problems that you can only see when real-live data flows through the data pipelines: these are tricky features to debug!

Please play with the follow feature and tell us what you think! If you know other services that we can use to play music from the data we have available, please comment! If you find bugs or have suggestions for how we make these features better, please open a ticket!

Have fun and discover some new music,
The ListenBrainz Team

ListenBrainz release: Spotify account linking and our first music discovery features!

For the past few months we’ve been working on enabling ListenBrainz to record your Spotify listening history automatically and we’ve just now released this feature! If you would like ListenBrainz to record your Spotify listening history automatically (and make it public!), go here to link your Spotify account to ListenBrainz. We’ll take care of the rest!

We would like to encourage as many users as possible to record their listening histories in ListenBrainz. With the data we collect and safeguard for you, we will soon start building more music discovery features. Please help our mission and go connect your account now!

This release also adds two new pages: Recent listens and the “follow” page. The recent listens page shows the most recent listens that we’ve saved in ListenBrainz for any user. This is a convenient way for you to discover other users who are currently listening to music.

The follow page is the new feature that we’re really excited about — it allows you to listen to the music that other people are currently listening to — pick a number of users to follow and their recent listens will appear on the page. The new embedded Spotify player can start playing the music as the listens roll in. This allows you to follow your friends and learn about music that they love! We’re going to write another blog post that talks more about the follow page and how we plan to improve that going forward — stay tuned for that.

This release also re-organizes the menu layout a little, moving the most useful features so that they’re easily accessible. Behind the scenes we’ve upgraded to using Python 3.7, starting using some portions of React for our user interface and also found ourselves amazed that this release included 646 commits! We hope to go to a more regular schedule of releases from here on out — this was a big push for us with a lot of infrastructure improvements that were needed.

This release would not have been possible if Monkey (from BookBrainz) didn’t come and help us write the UI for the follow feature. Monkey, iliekcomputers and myself worked relentlessly for weeks trying to push out some exciting features that show off the first steps for what we have planned for ListenBrainz. We’re quite excited for this release and we hope that you’ll enjoy the follow page and discover new music!

Schema change release: May 13, 2019

It’s been a while since our last schema change release in May 2017. To move forward on some features we’d like to add, we plan to have a Spring 2019 schema change release set for May 13th, 2019. This release should not be disruptive to downstream users, as we plan only to augment the schema with some new tables and columns, and not break any of the existing schema.

Here’s our list of tickets for the Spring 2019 schema change, with descriptions of what’s being changed:

MBS-1658: Add a free text field to collection items. This change will allow users of collections to annotate each item with free text, to hold personalized info about the item (for example, that a release is of a specific pressing, was purchased in 1999 at the Village Discount, or was a gift from your mom). This ticket will add a new TEXT column to editor_collection_release and all other entity-specific editor_collection_* tables. It will not add any new tables or modify any existing columns.

MBS-5387: Mark artist credits as having pending edits when they’re being edited. On an artist’s aliases tab, we provide the ability to directly edit artist credits associated with that artist. However, doing so doesn’t indicate anywhere that the artist credits are being changed (we typically highlight entities with pending edits). To resolve this, we’ll be adding an INTEGER edits_pending column to the artist_credit table. This ticket will not change any existing columns of the artist_credit or artist_credit_name tables.

MBS-5818: Make it possible to have ordered collections. Editor’s collections of entities are automatically ordered by field, for example, releases in collection are ordered by ascending release date. Sometimes, one might want to order collector’s items by other criteria, for example, most wanted releases. This change will enable editors to order collection items by hand if they want to. To do so, an INTEGER position column will be added to the editor_collection_* tables.

MBS-7480: Store cover art image file sizes. Knowing file sizes for cover images and their thumbnails would allow us to better detect when a thumbnail isn’t available, and also allow us to display file sizes to the user before they download an image. To do this, we’ll add four INTEGER columns to the cover_art_archive.cover_art table to store the file sizes in bytes: filesize, thumb_250_filesize, thumb_500_filesize, thumb_1200_filesize.

MBS-9428: Allow multiple users to share one collection. In some cases (like a collection of cleaned up entities several people want to keep an eye on, or a radio station’s collection of vinyl the station owns), it would be quite useful if multiple editors could add (and remove) entries from a collection. This would make cooperation easier and hopefully make community projects (such as the Composer Diversity Database project) easier to start and work on. We’ll add an editor_collection_collaborator table linking collections to the editors allowed to make changes in them (only the collection owner will be able to make changes to the list of allowed collaborators).

MBS-9491: Move hard-coded genres to a database table. We recently added genres to MusicBrainz, but they’re currently stored as an object in the server code. This change will move them to a new table genre (id, gid, name, comment).

MBS-10062: Add aliases for genres. Connected to the previous issue, we need a way to be able to specify “hiphop”, “hip hop” and “hip-hop” are all the same thing, and eventually to store translated versions of genres. This will add a table genre_alias (id, genre, name, locale, edits_pending, last_updated, primary_for_locale).

MBS-9973: Add a date added column for collection items. Editor’s collections have no editing history, thus it doesn’t allow to sort items by date of addition to the collection they belongs to. To allow this, editor_collection_* tables will get a TIMESTAMP added column.

MBS-10052: Add new tables for the event poster archive. This will move us another step toward CAA-84, giving us a place to store event posters, logos, and other related images. The schema change here will be to add a new event_art_archive schema, detailed in the comments in MBS-10052. There will be no change to the existing cover_art_archive schema.

The following tickets will also be included, but only involve adding some missing foreign keys, triggers, and constraints to standalone mirrors; these will not be created and have no effect on replicated mirrors.

MBS-9365: Adds a missing foreign key between the event_meta and event tables.

MBS-9462: Adds some missing l_event_url triggers to delete unused URLs.

MBS-9664: Adds constraints to prevent an entity from linking to itself in a relationship.

If you have any questions, please do leave a comment below or on the linked JIRA tickets!

Picard 2.1.3 released

Picard Team is proud to announce MusicBrainz Picard 2.1.3 is now officially released.

It includes a lot of bug fixes, and few improvements, but no major feature.

Thanks to all developers, translators, testers and users who contributed to this version, and especially Philip Wolfer (phw/outsidecontext).
Here is the complete changelog:

Bug

  • [PICARD-323] – Only the discid of the first disc in a release is written to tags
  • [PICARD-455] – Picard setting cover art height, width and depth to 0 for FLAC files –> breaks libFLAC
  • [PICARD-729] – Tracks get stuck at “[loading track information]” on Bad Gateway errors
  • [PICARD-938] – Need two left-arrow key presses to go from track with file to album
  • [PICARD-1178] – Images tagged with extra types that the user has chosen to ignore should not be shown as ‘modified’
  • [PICARD-1288] – Folskonomy tags / genre fallback on album artists tags not working
  • [PICARD-1422] – Windows: Uninstall 32 bit Picard before upgrade
  • [PICARD-1447] – When releasing a new version, appdata should also be updated
  • [PICARD-1460] – Windows installer does not detect running instance
  • [PICARD-1461] – Crash when running with Spanish language
  • [PICARD-1463] – Picard crashes on startup on Windows
  • [PICARD-1469] – Force close when adding songs to larger albums
  • [PICARD-1471] – Artist searches do not show begin and end area
  • [PICARD-1473] – AcoustId lookup fails if fingerprint already in tags
  • [PICARD-1474] – Windows installer shows outdated version string in file properties
  • [PICARD-1475] – Cover art sources do not support HTTPS
  • [PICARD-1476] – Filled up thread pool prevents metadata box updates
  • [PICARD-1478] – Changing MB server requires a restart
  • [PICARD-1480] – Search line input clear button icon is too small

Task

  • [PICARD-1459] – Remove OptionsPage.info method
  • [PICARD-1472] – macOS code signing on Travis CI fails for xcode7.3 image

Improvement

  • [PICARD-1242] – Consider the number of AcoustID sources for linked recordings
  • [PICARD-1457] – “Check for Update” should be in the Picard menu
  • [PICARD-1458] – “Check for Update” should have an ellipsis at the end
  • [PICARD-1470] – Make warning about Qt locale loading less prominent

As usual, packages will be available from Picard website and from GitHub release pages

Bugs can be reported on Picard bug tracker.

Ensembling: Clapper MiniVersion or idiophones!

The first sub-section of the gigantic “Ensemble this” version is already done:

This started out as a “create clapper-tree” ticket, created after dealing with the clapper ticket during from let’s get serious:

Ticket that inspired/started this

  • [INST-621] – Clapper (done in lets get serious)

Much of the initial part of this mini-version was done during let’s get serious. However, after coming back to it later, it became apparent that a more overarching edit and reorganization of idiophones was needed, so the second phase of this work involved linking existing and creating new idiophone instruments and organizing them.

Many of the tickets in this version were created or improved by students during GCI ’18. Many thanks to our students George Omnet and Jayant Dharwadkar, especially!

MiniVersion Clapper tree

  • [INST-630] – Rearrange idiophone tree (was: Create clapper tree)
    • [INST-751] – Boomwhacker
    • [INST-752] – Krap
    • [INST-608] – Add “shaken idiophone” and “scraped idiophone”
    • [INST-606] – Add concussion and percussion under “struck idiophone”
    • [INST-741] – Rearrange idiophone and percussion tree
    • [INST-732] – Research if shakers and rattles should be different
    • [INST-783] – clapstick
    • [INST-602] – Chinese paiban clapper and guban combo
    • [INST-566] – Arrabel

Thanks in great part to the new How to Add Instruments guide, we now had a framework to better objectively review inclusions of instruments. Following that, these instruments were found to be either not applicable (noisemakers not intended for music as such, rather than musical instruments) or to be too much of a novelty instrument:

Closed as not applicable / Reopen if/when musical use is demonstrated

The improvement of the idiophone section isn’t completely done however! Some more work is needed: moving and/or renaming the “tuned percussion” instrument (which is basically equivalent to the “percussion struck idiophones” in Hornbostel-Sachs already anyway) and (possibly) getting rid of “metallophone” (which is almost a duplicate of tuned percussion in function today, and that in meaning is basically just “idiophones made of metal”), which doesn’t seem necessary anymore.

Gamelan! (Photo by Bachtiar Djanan; used under the Creative Commons Attribution-Share Alike 4.0 International license.)
Gamelan! (Photo by Bachtiar Djanan; used under the Creative Commons Attribution-Share Alike 4.0 International license.)

Next, look forward to veena Gamelan!