MetaBrainz Foundation Community Blog
Hello, and welcome to the April recap of what’s happened in MetaBrainz land!
Compared the first quarter, April was somewhat on the slow side (reflected on the blog with only three posts that month). I’m guessing this is a mix of both recovering from all the activity in the first few months and a lot of work going on in the background—incl. preparing for Google Summer of Code. However, some stuff did happen, so let’s talk about those things! Continue reading “Community Recap April 2017”
Continuing our story from last time…
Eventually I mean to come back to this group of instruments (and in fact this is what I am doing currently), expanding the family tree I’ve been working on, which is why this “fix” version is still open.
Tamburica: 2017 January 6th to the 25th:
Initially, what I found to be the hardest part of adding instruments was actually the addition of aliases. It was a cumbersome, time consuming and annoying part, and I often clamoured for someone to write some sort of Batch Alias script. Then, in March, loujine came in like a superhero with a batch alias script! Now thanks to this script I can add aliases en masse, which has helped me tremendously!
After reosarevok fixed INST-723, I could link hybrids with the instruments they were hybrids of, therefore a batch of “hybrid” instruments came next.
Hybrids: 2017 February to March:
By this time a community discussion came out about the use of disambiguations and descriptions (instrument exclusive fields, which, unlike disambiguations, are translatable), with some users suggesting they were too long, some pointing out issues with translating and yet others suggesting the description field should be dropped altogether. While this discussion didn’t reach a clear resolution, it’s definitely something we should revisit later.
Stay tuned for part three!
If your replicated slave threw an error trying to apply packet #104949 (showing the message ERROR: duplicate key value violates unique constraint "artist_alias_idx_primary"), then you can un-break things by doing the following:
master branch:git checkout master && git pull origin master (OR, if you don’t want to update your code, clear the dbmirror_pending tables instead:echo 'TRUNCATE dbmirror_pending CASCADE; TRUNCATE dbmirror_pendingdata CASCADE;' | ./admin/psql READWRITE)./admin/replication/LoadReplicationChangesYou can also re-import from dump 20170605-031203 or later, and replicate from there. We’re very sorry for the inconvenience.
The issue here was caused by a bug in our alias merge code that interacted strangely with dbmirror. Since that code went untouched for years, the trigger for this issue must have been extremely rare. I’ve put in place a fix for the merge logic to ensure it doesn’t happen there again, and am investigating dbmirror’s behavior to see why it didn’t sequence the updates correctly.
Hi everyone! I’m CatQuest, the Endeavouring MusicBrainz Instrument Inserter. I’ve been meaning to write a post or two about this for a while, but now finally everything is in order!
As some of you may know, I have “officially” taken over instrument additions from reosarevok. I suggested this way back in June 2016 because a) reo was already overworked enough between doing Style, handling support, dealing with social media, and other things, and b) as a consequence of this, the Instrument Requests queue had grown unmanageably large.
Initially I started without grouping, components, or “fix versions”, but later I’ve been allowed to organise everything to my liking and so, I’ve gone back and retroactively added tickets for initial batches, modelled on freso’s ORG tickets.
So without further ado: Here is a list of the instrument tickets I solved from my initiate appointment in July 2016 to roughly October:
Very first batch:
It felt natural to separate this at Pipe and Tabor, so the next batch got a different “fix” version, from October to (taking a Christmas break) January 2017:
Second batch:
Stay tuned for part two!
We’re happy to announce the release of our May 2017 schema change today! Thanks to all who were patient during today’s downtime as we released everything to our production servers.
This is a fairly minor release as far as schema changes go, but please do report any issues that you come across.
Currently, the only visible change for editors is the ability to add multiple lyrics languages to works. We’ve also modified the schema to support dynamic attributes for entities other than works, but the UI for that won’t be complete for another release or two.
Now, on to the 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 rest of the instructions here assume an in-place upgrade.
DB_SCHEMA_SEQUENCE is set to 23 in lib/DBDefs.pm.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 #24, but the database is currently at #23.”git fetch origin followed by git checkout v-2017-05-15-schema-change.cpanm --installdeps --notest . (note the dot at the end) to ensure your perl-based dependencies are up to date.cpanm TURNSTEP/DBD-Pg-3.5.3.tar.gz (version 3.6.0 breaks things currently)../upgrade.sh (it may take a while to vacuum at the end).DB_SCHEMA_SEQUENCE to 24 in lib/DBDefs.pm as instructed by the output of ./upgrade.sh.npm install followed by ./script/compile_resources.sh.For those curious, here’s the list of resolved tickets (excluding MBS-8393):
We’re going to start our schema change release process today at 17h UTC.
We anticipate having a short downtime of a few minutes as we”ll need to restart our database server. As usual, we’re not certain when we will start the downtime, but we’ll keep people posted about our progress in IRC and on Twitter.
Once we’re done with the release we will post instructions on this blog on how to upgrade any replicated instances of MusicBrainz you might be running.
Stay tuned!
Sambhav’s GSoC project is all about Picard 2.0, and among progress made the devel version is now installable via PyPi: https://pypi.python.org/pypi/picard_dev
To install the dev builds you need to have a Python 3.5 or greater. At the moment it is mainly a port of 1.4.x to Python 3 and Qt5, with support for HiDPI and new icons !
Please note that Picard Dev version uses a different config file than your stable Picard installation. As such the settings and plugins will be on their default configuration.
To use your stable config with the dev version, simple copy your “Picard.ini” file from your MusicBrainz user folder to “Picard Dev.ini” which can be found in the same folder.
Since testers may want to run a stable 1.4.x version along the 2.0 dev one, the executable is named “picard_dev”.
Of course, we encourage people to test this version on every platform they can, and report any issue.
Thanks to Sambhav Kothari for the fantastic job he did on this ! And stay tuned, more to come !
Official MusicBrainz cross-platform music tagger Picard 1.4.2 is now out.
This is mainly a bugfix release, the only notable improvement is related to TOPE/TOAL tags.
Users can get Windows and MacOSx packages from Picard website downloads section.
Oh boy, oh boy. It’s been a while. Again. Huh? Well, now we’re back! Really! And so, so much has happened in the last while that we’re in for quite a ride here. So strap in!
This release brings feature parity with the pre-NGS edit search, thanks to work by yvanzo.
Note: The “My Vote” search condition has been replaced by “Voter,” with sub-condition “is me.”
The git tag is v-2017-04-10.