Picard 3 alpha ready for testing

MusicBrainz Picard
, ,
1

We finally did it, here is a pre-release for MusciBrainz Picard 3. We are looking for feedback, please see our blog post:

9 Likes
3

FYI, some of the download links don’t work in Chrome presumably because they lack HTTPS:

1 Like
4

With respect to testing - is it possible to run this as a standalone version with its own ini files avoiding disruption to my main Picard? Side by side testing style?

Some interesting looking changes.

5

Thanks for noticing, fixed.

You can run it with the --config or -c parameter:

picard -c "path/to/picard.ini"
2 Likes
6

We have released a second alpha version of Picard with several fixes:

Thanks for all the feedback and issue reports.

3 Likes
7

Downloaded standalone Windows version to a Win10 PC. MusicBrainz-Picard-3.0.0a2.exe
Ran okay as is. Started without issues.

I then deleted the folders created to make it “fresh” again.

Copied my current picard.ini file over and used:
picard -c "path\to\picard.ini"

Got crash :collision: :

Traceback (most recent call last):
  File "picard\config.py", line 477, in run_upgrade_hooks
  File "picard\config_upgrade.py", line 621, in upgrade_to_v3_0_0dev10
AttributeError: 'ImageFormat' object has no attribute 'lower'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "tagger.py", line 12, in <module>
  File "picard\tagger.py", line 1771, in main
  File "picard\tagger.py", line 255, in __init__
  File "picard\config_upgrade.py", line 717, in upgrade_config
  File "picard\config.py", line 479, in run_upgrade_hooks
picard.config.ConfigUpgradeError: Error during config upgrade from version 3.0.0.dev9 to 3.0.0.dev10 using upgrade_to_v3_0_0dev10()

Should I be stripping things out of my picard.ini? Do you want a copy buzzed to you via MB email? (I won’t post it here as it has auth tokens and other stuff in it) (Have emailed it to you @outsidecontext and it looks like it should survive the mail system as text unmangled as I see the same my end as I sent)

My picard.ini is old and messy and just been around for years through updates. But looking at that error I assume “ImageFormat” is a new setting?

As a test I then made a blank picard.ini and ran stand alone again. This time no crash and a selection of new settings added to the ini file.

But here is odd observation… the version numbers written at the top of picard.ini don’t make sense:

Successful run starting from an empty picard.ini file produces this:

[application]
version=3.0.0.alpha2

But when I ran with my original picard.ini, the crash had changed my original from:

[application]
version=2.13.3.final0

to:

[application]
version=3.0.0.dev9
1 Like
8

I believe this is a bug because it shouldn’t crash. Looks like it could be from a change I made to the way the target image format (for converting coverart files) is stored.

EDIT: I took the liberty of creating a ticket for this. https://tickets.metabrainz.org/browse/PICARD-3192

3 Likes
9

I didn’t receive it unfortunately. But I think @rdswift already identified the issue and we are discussing the fix. We should have enough information to create a test case.

2 Likes
10

Odd. I got my copy of the email from the MB emailing thing.

Let me know if needed and I’ll find an alternate way of doing it using one of them log paste sites or WeTransfer or magic pixies.

11

Oh, I found it now. Sorry, I was both looking at the wrong inbox and looking for a mail with attachment :smiley:

@rdswift it’s actually interesting, the config does not have the keys for cover_tags_convert_to_format or cover_file_convert_to_format (meaning it was never saved there, seeting kept as default). But as your fix shows the issue is independent of that.

1 Like
12

I thought a messy old picard.ini would have something unexpected for you :grin:

To be clear, the ini I sent is a copy direct from Picard2. Before Picard3 changes it. The crash happens when I tried to get Picard3 standalone to use this ini file using picard -c "path\to\picard.ini".

Running that standalone does cause a big re-write of that ini file, but not to a state that will allow Picard3 to start unless I remove the ini file completely.

13

Right, it will currently always crash on such an upgrade. There are two workarounds that should work:

  1. After it crashed the first time, set the version inside the .ini file to version=3.0.0.dev10. The config upgrade to this version is crashing, but the changes it does are not needed when upgrading directly from version 2.
  2. First install the alpha 1. This version can perform the update properly. Once it has done so you can run alpha 2.
1 Like
14

Confirmation to say I did Option 1 and no crash. Quick glance and I see settings I recognise. No other breakages yet.

Ah - spoke too soon. Dragged album in and it asks to authorise again… then realise I didn’t notice the error when it attempted to authorise first time. Paying attention this time I see. Invalid "state" parameter. in the browser.

Updated to add note to self. Don’t run Picard2 and Picard3 at the same time otherwise you get the above error. When I realised I had actually left both running I closed both, opened Picard3 on its own, and it has now logged in fine.

Will look closer another day and see what I can see and find out what else I can break.

15

I have a small plugin that I wrote for my own convenience. It expands the artists of a track, e.g. to add individual members of a band, or real people behind fictional characters. I implemented rate limiting and a local cache and request queue to ensure that the musicbrainz servers are not queried multiple times if several tracks have the same artist. To make everything (somewhat) thread-safe I implemented the queue based on LockableObject in picard.util.

Today I had a look at how easy it will be to migrate the plugin to new api version, but noticed that the lockableobject class has been dropped from the master branch. Is it planned to have a replacement for this class, or a similar mechanism that should be used in plugins now?

If there is no direct replacement, is there guidance for the recommended pattern for this in the new API:

  • shared in-flight request queue
  • local cache
  • deduplicating requests for the same artist across multiple tracks
  • keeping threaded access around async web callbacks

I could probably have a look at standard Python locks but wanted to check what the recommendation is as I assumed that using lockable objects was the preferred way of doing this since it was provided in the picard library.

16

The LockableObject got removed because it was not actually used. There were some classes inherting from it, but without actually using the lock functionality. Generally you could use any locking mechanism provided by Qt or Python, with a certain preference to the Qt. Picard itself is primarily using QMutex and ReadWriteLockContext.

What I would recommend for your use case if you need a read/write lock is using the picard.util.ReadWriteLockContext instead directly. This was also used by the LockableObject class. The ReadWriteLockContext is wrapping a QReadWriteLock to allow it being used with Python’s with:

class MyClass:
    def __init__(self):
        self._lock = ReadWriteLockContext()

    def get_some_data(self):
        with self._lock.lock_for_read():
            ...

    def write_some_data(self):
        with self._lock.lock_for_write():
            ...
3 Likes
17

Thanks for the clarification, appreciate it!

18

A third alpha version of Picard has been released with several fixes:

Once again, thanks to all of you for the feedback and issue reports.

5 Likes
19

And another round of fixes and polishing, with a few more small features.

With this release we also moved the Picard User Guide from GitHub Pages to ReadTheDocs. And thanks to the awesome work of @mfmeulenbelt the user guide is now translated into Dutch.

6 Likes