MetaBrainz Blog – Page 28

Picard 2.4.2 released

This release includes even more fixes to previous 2.4.x releases.
It fixes some annoying bugs and improves overall usability.
Documentation links inside the application were updated to point to picard-docs.musicbrainz.org (thanks to the great work rdswift did).

For a full list of changes since Picard 2.3.2 see our release announcements for Picard 2.4 and Picard 2.4.1.

Changes in the 2.4.2 point release:

Bug fixes

[PICARD-1909] – No refresh of metadata on “Use Original Value” or remove tags
[PICARD-1911] – Removing tags does not update list views
[PICARD-1913] – Changing tags of a track without matched files changes original metadata
[PICARD-1914] – Editing track metadata edits data of previously linked file
[PICARD-1915] – An album selected during loading should update the metadata view when loading has finished
[PICARD-1916] – Picard crashes on older releases of macOS due to theming exception

Improvements

[PICARD-1860] – New added tag should open field to enter value automatically
[PICARD-1899] – Update help links to go to http://picard-docs.musicbrainz.org
[PICARD-1920] – Open documentation in options dialog using the platform’s help shortcut (e.g. F1 on Windows or Ctrl+? on macOS)

Thanks a lot to all contributors who made this release possible.

Picard 2.4.1 fixes start issues on Windows 7 and 8

Following yesterday’s release of Picard 2.4 we have a bugfix release that fixes Picard not starting on Windows 7 and Windows 8. Users of those operating systems should upgrade to Picard 2.4.1.

For a full list of changes since Picard 2.3.2 see our release announcement for Picard 2.4.

Changes in the 2.4.1 point release:

[PICARD-1904] – Picard 2.4 does not start on Windows 7 and Windows 8

Thanks a lot to the users reporting the issue and to Gabriel Ferreira for quickly providing a fix.

MusicBrainz Server update, 2020-08-10

After a slow summer month, and hot on the heels of the release of Picard 2.4, an update for MusicBrainz Server has finally arrived, fixing ten bugs, converting almost as many templates to React, making small improvements and bringing a few handy new features.

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 Cyna and loujin for contributing code. Thanks to aerozol, chaban, cyberskull, fabe56, hibiscuskazeneko, ijc, jesus2099, Kid Devine, Nero Apunto, and yindesu for having reported bugs and suggested improvements. Thanks to kellnerd and mfmeulenbelt for updating the translations. And thanks to all others who tested the beta version!

The git tag is v-2020-08-10.

Bug

[MBS-7994] – No distinction made between pregap track and position 1 with number 0 when displaying a release
[MBS-10746] – Edit removing pregap track option not shown in edit history
[MBS-10833] – ISE when trying to load “Wikipedia page” edit
[MBS-10917] – Event ‘Found in X User Collections’ wont expand
[MBS-10923] – Pagination of collections not returning consistent results
[MBS-10927] – Since-removed entity show as being created on “add relationship” edit
[MBS-10930] – ISE when trying to display “microblog” edit
[MBS-10932] – Instagram TV links are not allowed
[MBS-10937] – Average event rating not shown on all pages
[MBS-10943] – Attribute value not shown on “remove relationship” edits for events

New Feature

[MBS-9502] – Test if the barcode already exists when adding a new release
[MBS-10562] – Add alternate phrases for Places yet to open
[MBS-10940] – Allow filtering the artist Releases tab by date and country
[MBS-10949] – Add autoselect + sidebar for Migu Music URLs

Improvement

[MBS-10193] – Update iTunes/Apple Music URL cleanup
[MBS-10925] – Update the VGMdb logo used in the sidebar
[MBS-10926] – Add “Copy to end date” button in relationship editor dialogs
[MBS-10928] – Update the Baidu logo used in the sidebar
[MBS-10939] – Improve Data::Release::find_by_artist to not cause database load issues in production
[MBS-10989] – Update VocaDB cleanup to support new Es (series) format

React Conversion Task

[MBS-10816] – Convert Add Label edit to React
[MBS-10968] – Convert Add ISWCs edit to React
[MBS-10969] – Convert Add ISRCs edit to React
[MBS-10970] – Convert Add Release Label edit to React
[MBS-10973] – Convert Add Relationship Attribute edit to React
[MBS-10974] – Convert Remove ISRC edit to React
[MBS-10975] – Convert Remove ISWC edit to React
[MBS-10980] – Convert Remove Entity edit to React
[MBS-10983] – Convert Remove Release Label edit to React

Picard 2.4 released

The Picard team is happy to announce that version 2.4 of MusicBrainz Picard is now available for download. MusicBrainz Picard is the official tag editor for the MusicBrainz database and helps you get your music collection sorted and cleaned up with the latest data from MusicBrainz.

This releases brings significant performance improvements, improved documentation, new features and many bugfixes.

What’s new?

Better performance and responsiveness

Picard 2.4 features heavily improved performance and responsiveness of the user interface when loading or saving a large amount of files.

Improved online documentation

There is a completely new User Guide for MusicBrainz Picard, which replaces the documentation previously available on the Picard website. This documentation is much more complete and easier to update and maintain.

We are also looking for contributors who help to improve the documentation. If you have some ideas for improvements have a look at the Picard Docs project on GitHub.

Support for tagging WAVE and DSDIFF

Picard now finally supports writing tags to WAVE files. This was previously not possible, as there is lack of a proper standard to tagging WAVE files. Now Picard will allow you to write ID3v2 tags to WAVE files. As this is not supported by all players and tagging tools, Picard can optionally fall back to writing RIFF INFO tags to the files. Just be aware that RIFF INFO is very limited in regards to tags available and support for non latin character sets.

As a new file format Picard now supports DSDIFF (also known by their file extension as DFF) files. These can be loaded and saved using ID3v2. Similar to WAVE there is no standard way for tagging DSDIFF files, but many playback tools which support DSDIFF also support the ID3v2 tags.

Script auto completion and inline documentation

The script editors in the options dialogue (both for file naming and metadata scripts) now support auto completion for function and variable names. In addition there is a new script documentation dialogue, which shows the documentation for all scripting functions without the need to open the online documentation in your browser.

Dark mode support for Windows 10

On Windows 10 Picard now respects your settings for the Windows dark mode. If enabled, Picard will use a dark color theme and optimized syntax highlighting. This work also allows us to further improve Picard for dark themes on other platforms in the future.

Updated translations

With this release a lot of translatable text has been added to Picard, and many translations have been updated.

But not all translations are completed and we always need help maintaining the translations for Picard. Translating is easy and can be done online: Head over to MusicBrainz’s translation page on Transifex and click on “Help Translate MusicBrainz”. Any changes to the translations will be included in the next release.

More changes and bugfixes

Picard 2.4 has many more improvements and fixes. See the full changelog for details on all changes since the last stable Picard 2.3.2.

Download

Picard 2.4 is available for download from the download page. For Windows 10 users installing from the Windows Store an update will come automatically as soon as the new release has been approved by Microsoft.

Acknowledgements

This release contains code changes by Gabriel Ferreira, Laurent Monin, Bob Swift, Philipp Wolfer, RaysDev, Wieland Hoffmann and new contributors Adam James, jcaesar and elvquant.

Special thanks go to Gabriel Ferreira for his excellent work in profiling and improving Picard performance and to Bob Swift, who completely overhauled Picard’s documentation, making it much more complete then it ever has been, and to all the translators who updated their language translations on Transifex.

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!

Picard 2.4 Beta 2

Following the first Picard 2.4 beta we have released Picard 2.4 beta 2 to address a couple of reported issues. Thanks a lot to everyone who tested the last beta and reported issues. The following bugs have been fixed in beta 2:

[PICARD-1864] – Adding single files does ignore existing MBIDs
[PICARD-1866] – Coverart pane does not update during / after saving files
[PICARD-1867] – Guess format fallback is broken
[PICARD-1868] – CAA type selection dialog does not translate “Unknown”

See our previous blog post about Picard 2.4 beta 1 for the changes since the last stable release.

Picard 2.4 beta 2 is available for download from the download page.

Please report bugs on the Picard issue tracker and provide feedback in the community forums.

Please also help translate Picard. There have been many changes to the user interface and existing translations need to be updated for the final 2.4 release. Translating is easy and can be done online: Head over to MusicBrainz’s translation page on Transifex and click on “Help Translate MusicBrainz”.
Once you have registered an account on Transifex you can start translating. For Picard the primary resource to translate is “picard“, but there is also the “picard_appstream” resource which is used for providing descriptions for various Linux software-center applications.

Picard 2.4 Beta 1

Picard 2.4 Beta 1 is now available. There have been some important changes and we would like to gather feedback with this beta release before releasing the final Picard 2.4.

This release contains code changes by Gabriel Ferreira, Laurent Monin, Bob Swift, Philipp Wolfer, RaysDev, Wieland Hoffmann and new contributors Adam James and jcaesar.

Thanks a lot to everybody who contributed to this release with code, translations, bug reports and general feedback.

What’s new?

The most notable change in this release are significant performance improvements when handling large amount of files thanks to the excellent work of Gabriel Ferreira.

We would also like to get some feedback on the new scripting auto completion feature and the scripting documentation provided directly inside Picard. Windows 10 users can also try Picard’s new support for Windows 10 dark mode.

Here is the full list of changes:

Bugfixes

[PICARD-1753] – Fix font size of script editor and log view on Windows
[PICARD-1807] – Wrong error handling when using python-libdiscid
[PICARD-1813] – $title function throws error on empty value
[PICARD-1820] – PLUGIN_VERSION no longer displayed correctly in plugins dialog
[PICARD-1823] – Genre tag ordering is non-deterministic
[PICARD-1826] – “no appropriate stream found” when saving .ogg (OPUS) file
[PICARD-1838] – Files with a .dff file extension are interpreted as DSF files and fail to load
[PICARD-1853] – Crash if tags contain null character
[PICARD-1855] – Relationships not tagged for non-album track
[PICARD-1859] – “ValueError: Invalid literal” followed by crash when opening certain files

New Features

[PICARD-1704] – Support Windows 10 dark mode
[PICARD-1797] – Autocompletion for script functions and variables
[PICARD-1798] – Add support for inline translatable script documentation

Improvements

[PICARD-824] – Expand all option submenus by default
[PICARD-920] – Remember selected options page
[PICARD-1117] – Instrumental recordings of a work should set language to “No lyrics”
[PICARD-1796] – Consider release date when matching files to releases
[PICARD-1805] – Make it easier to add the first script
[PICARD-1818] – Make PyQt5.QtDBus optional
[PICARD-1829] – Add support for disc numbers in cluster Info dialog tracklists
[PICARD-1831] – Mitigate performance impacts of file selection and UI updates during processing
[PICARD-1840] – Instrumental recordings of a work should drop the lyricist credit
[PICARD-1842] – AIFF and DSF: Add support for albumsort, artistsort, titlesort and discsubtitle
[PICARD-1843] – Improve load and clustering performance
[PICARD-1844] – Further improve loading and clustering performance
[PICARD-1845] – Add “lookup in browser” for musicbrainz_discid tag in metadata view
[PICARD-1846] – Metadata.unset should not raise KeyError
[PICARD-1847] – Restructure tag compatibility options
[PICARD-1852] – Make about a separate dialog
[PICARD-1854] – Improve sorting performance in main window
[PICARD-1856] – Use pgettext function in Python 3.8

Download

Picard 2.4 beta 1 is available for download from the download page.

Helping out

The easiest way to help us getting a great Picard 2.4 release is using and testing this release candidate. Please report bugs on the Picard issue tracker and provide feedback in the community forums.

If you are a software developer you are very welcomed to provide fixes and features. Picard is free software and the source code is available on GitHub. See Developing on the Picard website to get started.

MusicBrainz Server update, 2020-06-29

The React conversion is back with this release. We’ve also fixed a regression that listed unrelated “recording of” relationship edits in history of artists, recordings, and releases, and made a lot of people quite frustrated during the last two weeks (sorry about that!). New edits won’t be wrongly listed anymore, and the existing wrongly-listed edits will be progressively unlisted during the following days. Finally, two new data reports have been created, and small display improvements have been made.

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 loujin for contributing code. Thanks to DjSlash, hibiscuskazeneko, insolite, jesus2099, and mavit for having reported bugs and suggested improvements. Thanks to Atsushi Nakamura, kellnerd and salorock for updating the translations. And thanks to all others who tested the beta version!

The git tag is v-2020-06-29.

Bug

[MBS-10825] – Normalization of some Muziekweb links make them invalid
[MBS-10908] – Unrelated “recording of” relationship edits for works show up in history of artists, recordings, and releases

New Feature

[MBS-10770] – Report on relations with dates in the future
[MBS-10895] – Report for mediums with conflicting discID

Improvement

[MBS-10736] – Add autoselect + sidebar for Napster URLs
[MBS-10802] – Right-align columns of Reorder Relationship table
[MBS-10894] – Show label code after selecting label in the release editor
[MBS-10903] – Update Operabase cleanup and validation
[MBS-10907] – Define background color for header and footer too

React Conversion Task

[MBS-10777] – Convert Add/Remove Relationship edits to React
[MBS-10801] – Convert Reorder Relationships edit to React

Introducing the BookBrainz merging tool

Today we come with a big BookBrainz website update that allows you to merge duplicate entities!

Being able to clean up the database is an essential step towards importing public bibliographic records and catalogs from partner websites. As with MusicBrainz, you can visit an entity page on BookBrainz and click on a button to add an entity to a merge queue. You can merge multiple entities in one go easily.

After clicking the merge button you will be presented with a page that lets you review and select the correct information in case of conflicting data. The revision history of merged entities is preserved, and in the near future you’ll be able undo merges.

Your feedback is very welcome! We also have a short tutorial on how to use the new merge tool for the curious.

This latest website update also adds annotations for any information that does not fit into the existing format, some small design improvements and bug fixes.

We’ve also added the ability to search for users on the search page. This last feature will come in handy soon as we introduce collaborative User Collections; stay tuned!