Picard 2.0.3 released: Crash-fixes and scripting improvements

This is a minor release that fixes a lot of crashes and unicode errors on certain platforms. It also reverts a scripting improvement (PICARD-259) which had caused a couple of scripting bugs (PICARD-1207). Scripting now works exactly like Picard 1.4.

As usual, you can find the latest downloads on Picard’s Website.

The change-log is as follows –

Release Notes – Picard – Version 2.0.3

Bug

  • [PICARD-1122] – Preferred release type settings are exclusive and should be inclusive
  • [PICARD-1207] – Move additional files feature fails when source directory contains non-ascii characters
  • [PICARD-1247] – Not all “preserved” tags are preserved
  • [PICARD-1305] – Search dialog crashes picard when record doesn’t have an album
  • [PICARD-1306] – picard crashes when opening the options dialog if the cwd doesn’t exist

New Feature

  • [PICARD-1289] – Allow manually running any tagger script

Improvement

  • [PICARD-1292] – MusicBrainz Picard 2.01 64-bit for windows installs to “C:\Program Files (x86)” by default
  • [PICARD-1302] – Dropping an image from Google image crashes picard
  • [PICARD-1303] – picard crashes when matching a cluster with a release with no tracks
  • [PICARD-1304] – Info dialog for album crashes because track doesn’t have a tracknumber

Regression

  • [PICARD-259] – Make file-specific variables available to tagger script

 

samj1912 out o/

 

Picard 2.0.2 released! Signed macOS builds

This is a minor release that fixes some crashes due to logging events and compatibility issues on Macs running on dual-core processors.

I would like to extend a word of thanks to Francois Ferrand and Ryan McKern, following whose advice, bitmap was able to successfully fix our macOS packaging and code-signing issues, details of which can be found in our recent CFH blog.

As usual, you can find the latest downloads on Picard’s Website.

The change-log is as follows –

Sub-task

Task

Bug

  • [PICARD-342] – Picard is not properly signed for Mac OS X Gatekeeper
  • [PICARD-1212] – Picard 2.0.0dev4 crashing at startup
  • [PICARD-1300] – Picard crashes when logging lots of events

samj1912 out o/

Call for help: Picard 2.0 macOS packaging

Hello everyone,

As you might know, we recently released Picard 2.0 stable. One of the major problems with the macOS version of the same is that is very unreliable. It works perfectly on some systems and doesn’t on others with the same macOS version. See PICARD-1212 for example.

Another major problem we are facing is code-signing Picard 2.0. In order to ensure that our macOS users have a seamless experience, we paid for an Apple dev account, but we are unable to code-sign Picard.  See PICARD-1296

If you have experience with either and are willing to help, please email us at – support@metabrainz.org or join us on irc at #metabrainz (freenode).

 

Picard 2.0.1 released! (Windows and macOS users rejoice)

Note – There are no changes for Linux users, so they can safely skip this release if they want.

Given the massive feedback about the shortcomings of the Windows and macOS versions of Picard, we decided to do a minor release addressing some of the issues with our executables.

As usual, you can find the latest downloads on Picard’s Website.

The change-log is as follows –

Bug-fix

  • [PICARD-1283] – Fingerprinting not working on macOS in Picard 2.0
  • [PICARD-1286] – Error creating SSL context on Windows

Improvement

  • [PICARD-1290] – Improve slow start up times by moving to a non single file exe
  • [PICARD-1291] – Use an installer for Picard 2.x windows exe

Basically, the Windows executable is now a proper installer and some missing SSL dependencies are bundled with it.

The macOS builds also include the missing AcoustID fingerprinting binary.

The startup time for both the Windows and macOS version has been improved as well.

Have fun tagging your files!

samj1912 signing off o/

 

Picard 2.0 released

Hey people, samj1912 here again o/

This time we are announcing the release of a new Picard!

Official MusicBrainz cross-platform music tagger Picard 2.0 is now out, containing many fixes and new features and much needed upgrades!

The last time we put out a major release was more than 6 years ago (Picard 1.0 in June of 2012), so this release comes with a major back-end update. If you’re in a hurry and just want to try it out, the downloads are available from the Picard website.

If you have been following our Picard related blogs, you will know that we switched up our dependencies a bit. Python should now be at least version 3.5, PyQt 5.7 or newer and Mutagen should be 1.37 or newer. A side effect of this dependency bump is that Picard should look better and in general feel more responsive.

A couple of things to note – with Picard 2.0, Picard Windows builds will be portable standalone binaries. Also, we will only be supporting 64-bit Windows officially because of lack of resources to build a 32-bit image. The macOS requirements were also bumped up for the same reasons, with macOS 10.10 being the lowest version that is supported.

As such, Picard 1.4.2 will be the last version that is supported for both Windows 32 and macOS 10.7-10.10. You can find it in the Picard downloads section as well.

You can find a detailed change-log on the Picard webiste.

The highlights of this update are –

  • Retina and Hi-DPI display support
  • Improved performance
  • UI improvements

We would like to thank all contributors, from all around the world, who helped for this release: Laurent Monin, Sophist, Wieland Hoffmann, Vishal Choudhary, Philipp Wolfer, Calvin Walton, David Mandelberg, Paul Roub, Yagyansh Bhatia, Shen-Ta Hsieh, Ville Skyttä, Yvan Rivierre and also all of our translators!

Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.

Note:  If you are facing errors while tagging releases on Windows, do take a look at this FAQ about SSL errors.

Releasing our new Solr search infrastructure

Hey folks, samj1912 here again o/

As you might know, we recently did a massive upgrade of our search infrastructure. If you have not been following our Solr updates, definitely check out our other blog detailing our search server journey and the improvements and changes that come with the new search.

We have had a beta run with Solr this last week and fixed most of the show-stopping bugs. As such, we have been stress testing our Solr search by replaying our production logs on it, live.

Solr search seems to solvr almost all our qualms with search and as such, we have made the decision to use Solr for our production search servers.

The purpose of this blog post, as nicely worded by our BDFL Rob is –

Speak now or forever hold your pickle. In a week, the ole search servers gets it.

And it’s basically that, if you haven’t experimented with Solr search, please read our earlier blog to know what’s what. If you find any bugs, please report them on our ticket tracker. In case there are no new show-stoppers reported, that must absolutely be fixed before we switch to Solr on the main website, we will be killing the old search servers and replacing them with our brand new Solr ones in a week.

Apart from that, we have made a discourse thread to report any minor improvements in the search results.

Another thing, I’d like to remind everyone is that, with our switch to this new Solr infrastructure, the version 1 web service (ws/1)will soon be discontinued. As announced earlier, we will keep it alive till 31st July 2018 but it will get the axe on 1st August 2018, 12 pm GMT.

MusicBrainz Search Overhaul

Hello people o/, samj1912 here.

I am extremely glad to announce that we are finally launching our Solr search on the MusicBrainz beta server!

Just a little history before I announce the new features and toys you get to play with:

Solr started as something that could replace our existing search infrastructure. If you have been a MusicBrainz user for a while, you might know that our search has quite an indexing latency and it takes as much as 3 hours for new edits to show up in the search results. In part because updating the search index involved doing an entire re-index of the database. With the high latency and the resources it took, the current search server left much to be desired.

Another area that our current search lacked in, was showing popular results and search ranking. Searching for a famous artist or place returned results that contained a lot of noise, and more often than not, contained results that weren’t relevant to what the user had in mind when they searched for it.

These were the two major problems that motivated us to shift to a better infrastructure for our search needs.

Thus, MB-Solr was born.

It has been in development for quite some time now. The coding for the project started with Mineo back in 2014 and was carried forward by Jeff Weeksio in GSoC 2015. But due to lack of development resources and other, more pressing needs, the project was put on a hold for a while, until Roman started working on it. However, he left MetaBrainz before he could finish this work, so when I joined the MetaBrainz team, the first and foremost task that was assigned to me was getting Solr working and ready for production.

After struggling with multiple moving parts and services, tons of issues with maintaining compatibility with our existing web-service API, rowing up and down multi-threading/processing hell, learning just enough about information retrieval to get our search relevance on point and countless hours sifting through Solr documentation to get our Solr cluster fine-tuned and running fast enough to keep up with our web traffic… we are finally here.

I am pretty sure I would’ve rage-quit dozens of times during this last year if I was doing this all alone.

As such, we have our trusty sysadmin Zas to thank for taking care of all the deployment needs and making sure Solr was well-tested (believe me we toyed with Solr like little kids in a sandbox) and wasn’t going to fail and wake him up 3 AM in the morning with red alerts all over. Mineo, Bitmap and Yvanzo were there, with much-needed code reviews and help with all things Solr and MusicBrainz. Our style leader Reosarevok, and CatQuest helped us test our new search relevance configuration. And of course, we had our BDFL, Rob over-seeing things and whipping them into shape (with chocolate and mismatched socks of course).

Anyway, here’s what you are here for:

New features/improvements

  • (Almost) Instantaneous search-index updates – Edit something and immediately see it in the search results. Say goodbye to that note you used to see below the search telling you that you have to wait. Who likes waiting anymore – seriously, it’s 2018.
  • Better search results – We wanted to make sure you were getting the right Queen and London as the top result. You can finally link your favorite artist to London, UK as opposed to London, Arkansas. Don’t believe me? Go try it out.
  • Less load on our servers – Meaning we can serve more of your requests, faster. Getting tired of waiting for tagging your bajillion songs in Picard? Well, you still gotta wait, but less so, now that we are better equipped to handle your requests.

What has stayed the same

  • WS/2 Search API – We know you devs hate doing that extra work to maintain your applications’ compatibility with that one site that changes its API on a whim. Well, we wouldn’t want you to spend those hours following that one int to float change that broke everything ever. As such we have worked hard to make sure that Solr doesn’t change any of our WS/2 search schema.

What’s gone

  • WS/1 Search API – We deprecated WS/1 back in 2011. With the new search servers in place, there are only 3 words for those still using it after WS/1 being deprecated 7 years – ‘poof, it’s gone’. The service still works on our main website, but its search functionality will be phased out soon, while the entire service will be discontinued in August 2018 as announced earlier.

Now, you must be thinking there is some catch, some slip. Well so do I, which is why we are releasing this beta for you to test the heck out of our new search over at the MusicBrainz beta site. If you haven’t used it before, worry not – it has all your personalizations and all our cool music metadata from our main site. You should feel at home. (Note: The MusicBrainz beta site works on the live data. Any edits you make on the MusicBrainz beta site will also be reflected on the main site.)

So please! Go check it out!

If you feel you aren’t getting what we promised you or you want more of those shiny new features or that this blog was too long or like a TV commercial, feel free to complain at our Ticket Tracker for Solr. You get your promised features bug-free and our devs get to earn their living. It’s a win-win.

Happy testing!

Picard 2.0 beta3 announcement

Hello people,

Thank you so much for reporting bugs in our Picard 2.0.0beta2 release. We fixed most of the critical bugs that you guys and gals reported. You can find the beta3 release with the fixes here – Picard 2.0.0.beta3

If you have been following our Picard related blogs, you will know that we decided to release a new stable version of Picard before the beginning of the summer.

To help us, advanced users, translators and developers are encouraged to:

Note – If any of you are seasoned Windows/macOS devs and have experience with PyInstaller, we need some help with PICARD-1216 and PICARD-1217. We also need some help with code signing Picard for OSX. Hit us up on #metabrainz on freenode for more information. We will be very grateful for any help that you may offer!

A simplified list of changes made since 1.4 can be read here.

Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.

Picard 2.0 beta2 announcement

Hello people,

Thank you so much for reporting bugs in our Picard 2.0.0beta1 release. We fixed most of the critical bugs that you guys and gals reported. You can find the beta2 release with the fixes here – Picard 2.0.0.beta2

If you have been following our Picard related blogs, you will know that we decided to release a new stable version of Picard before the beginning of the summer.

To help us, advanced users, translators and developers are encouraged to:

Note – If any of you are seasoned Windows/macOS devs and have experience with PyInstaller, we need some help with PICARD-1216 and PICARD-1217. We also need some help with code signing Picard for OSX. Hit us up on #metabrainz on freenode for more information. We will be very grateful for any help that you may offer!

A simplified list of changes made since 1.4 can be read here.

Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.

Picard 2.0 beta announcement

Hello people,

We saw a flurry of updates to Picard these last few months and I am happy to announce that Picard 2.0 is finally in beta. You can find it here – Picard 2.0.0beta1

If you have been following our Picard related blogs, you will know that we switched up our dependencies a bit. What this means is that Picard should look better and in general feel more responsive.

We also decided to release a new stable version of Picard before the beginning of the summer.

To help us, advanced users, translators and developers are encouraged to:

A simplified list of changes made since 1.4 can be read here.

Be aware that downgrading from 2.0 to 1.4 may lead to configuration compatibility issues – ensure that you have saved your Picard configuration before using 2.0 if you intend to go back to 1.4.