Classical Extras plugin (for Picard 1.4.x)

Any idea what this means? I’ve been trying to figure it out for ages and it might not be directly related to your plugin but I just don’t know what’s going on. It only happens for a few in my collection and not all.

I open it up in MusicBrainz and it looks fine and I see the recording associated with the track with all the work information. But in Picard I see this and all of the relationship/advanced information is missing.

It’s happening for this box set among others.

1 Like

That is a message from my plugin (actually 2 messages). I’ll deal with each in turn and give the background.

  1. The plugin is (I think) unique in that it is able to process not only the metadata from the MusicBrainz database, but also the existing file tags. However, because of the way Picard is structured, it can only do this if the file tags contain a MB trackid. If no MB trackid exists on the file, or if for some reason there is a problem reading it (can happen sometimes, particularly with network servers) then you will get the first message. Everything will work, except those noted in the message.

    • ‘saved options’ - This relates to the bottom section of the ‘advanced’ tab: “Over-ride plugin options displayed in Options Pages with options from local file tags (previously saved using method in box above)?”. If you have selected this then the error message means that the displayed options will have been used rather than the saved ones.
    • ‘lyrics’ - These are only found in file tags, not MB. If you have mapped them to other tags (bottom box of ‘artists’ tab) then this processing will not have happened.
    • ‘keep tags’ - These are any tags you have specified immediately above the “Tag map details” section on the ‘tag mapping’ tab. If there are none then fine, otherwise if you have specified some and they are used in tag mapping, then that processing will not have happened.

    To get everything you need to right-click on the album and select “refresh”. The message should then go away.
    Obviously if you have just tagged a MB release and not matched to files then the message is irrelevant.

  2. The original raison d’etre of the plugin was to access all the hierarchical works structure for classical works, although it now does a lot more. Even some classical albums may have tracks which do not have a work relationship. This message just tells you that - the idea being that you can check the MB entry and see if a work relationship should be added. However, for the release you have quoted, it seems that the message is generated for all the tracks and that they do have work relationships, so I’ll need to delve into that one a bit more deeply (may take a while to find the problem - that’s a pretty big album!).

Hope that helps :slight_smile:

Thanks for the response!

Unfortunately, refreshing doesn’t fix the problem :frowning: Maybe it’s because the release is so big and there are network problems.

It looks like the works issue is the bigger issue though since they seem to be there…it’s also not returning conductor, orchestra, or the other instrument roles. Let me know if more information would help you.

Do you have any other (smaller) albums with the same problems?

The ‘works’ issue doesn’t seem to be down to the plugin. If you deselect the plugin and run “vanilla Picard” you will see that no tags are returned for Work or MusicBrainz Work Id, even though there are work relationships and the release-rels and track-rels options are enabled. Whereas for other releases, these tags are returned. My plugin needs the MusicBrainz Work Id to look up the work structure. If that is not available an extra lookup would be required which would make it almost twice as slow. I’m wondering if Picard is restricting the amount of data returned and a 40 CD release is blowing the limit?
The same problem occurs if you do an XML lookup:
https://musicbrainz.org/ws/2/release/60af2508-679f-32e7-a582-d01e48450113?inc=release-groups+media+recordings+artist-credits+artists+aliases+labels+isrcs+collections+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels+tags
should get all the relationships, but none are returned.

If you have any smaller releases with the same problem, it might help to narrow the problem down. Otherwise it looks like I may need to raise an issue with the Picard devs.

1 Like

Raised the question re the xml webservice here: Relationships not returned by XML webservice

1 Like

Great, thanks for reporting. I think you’re right that it’s not your plugin. I just tested beets and that doesn’t work either. No work info is returned.

There are a lot of classical box sets that are very big (sometimes split up into psuedo volumes, sometimes not) and it would be a shame if their web service was throttling it

Assuming the diagnosis is correct, I am not hopeful of any imminent fix. Meantime, the only solution I can think of is to create (say) 4 pseudo releases of 10 CDs each. I know that Mahler (13 CDs) and Sibelius (15 CDs) work OK.

I wonder if this issue is why those pseudo releases were created in the first place? Some of the box sets mention technical reasons as the reason for splitting, although it seems queries used to fail entirely and now they omit information (or it depends on just how big it is)

This Bach release was split into unofficial volumes, for example.

I would be willing to help make some of these pseudo releases in my free time as long as the MusicBrainz community is okay with some of the arbitrary splits I’d have to make to accomplish it. It’s not like I’d be modifying the official release though.

I just wanted to test this plugin, but I could’t install it. On Arch Linux, Picard 2.0.0beta3 ist currently the version which gets installed. I guess (sorry, I’m a newbie) the problem is, that classical_extras uses API v1 but for my picard version, it needs API v2? So I would like to know if there are any plans for that? (or am I wrong with my guess?)

Sorry, you are right, it only works on 1.4 at the moment. I have almost finished the last planned release on 1.4 (to incorporate genres, instruments, keys, workdates and periods). After that I will focus on the migration to 2.0. Any information on updates will be posted to this thread.

1 Like

Version 0.9.3 released - https://github.com/MetaTunes/picard-plugins/releases/tag/v0.9.3. This is the final intended functionality. It incorporates the following:

  1. A new tab in the options page - “Genres etc.” This includes special processing for genres, instruments, keys, work dates and periods. A separate section has been added to the readme giving more details on the options in this tab.

  2. As well as the main Picard log, a custom logging function is provided. This may be either “basic” or “full”. If “basic” is selected, a file “session.log” will be written (over-written each session) to a “Classical Extras” directory inside the same directory as the main Picard log. This gives a processing summary for each release and includes errors, warnings and debug messages if those options have been selected.

    If “full” is selected, all errors, warnings and debugs will be written, along with additional debugging messages, to a custom log file for each release processed. These files are stored in the same directory as the session.log. The log file for a release is named using the release MBID. Debugging from these files requires an understanding of the source code (i.e. intended for developer use :nerd_face:).

  3. Performance improvements (especially for lyrics processing) and various bug fixes.

See the readme at https://github.com/MetaTunes/picard-plugins/blob/1.0/plugins/classical_extras/Readme.md
After any (hopefully no) bug fixes, this will become version 1.0.
After that I will attempt to migrate it to Picard 2.0.

5 Likes

Just so you know; at https://picard.musicbrainz.org/plugins/ the older 0.9.1 is still referenced.

Yes, I know, thanks. I’ve tried to get them to update it to the most recent PR. I gave up and will try again when I release 1.0.
0.9.3 seems to be reasonably stable. I have a 0.9.4 with minor fixes which I’m testing now and will do a release of that shortly. If it seems error-free, it will become 1.0 and I will do a PR for that and get them to update the link.

2 Likes

A version for Picard 2.0 has now been released - see Classical Extras 2.0
Please use this thread only for questions etc. which relate to the Picard 1.4.x - compatible versions.
Version 0.9.4 for Picard 1.4.2 will be released shortly, but it is advised to upgrade to Picard 2.0 and Classical Extras 2.0 (BUT back up your Picard.ini file before doing so!!)

5 Likes

Thank you for the wonderful Classical Extras 0.x. I have been using various versions on all my classical music tagging for several months.

I’ve been having difficulties using Picard and Classical Extras 0.9.3 to update the tags in my 1984 Solti Götterdämmerung Release (release/4ded9). Some problems occur with Classical Extras turned off. But when I turn Classical Extras on, I see many repetitions of the following error:

E: 23:49:14 Traceback (most recent call last):
  File "picard/album.pyo", line 330, in _finalize_loading_track
  File "picard/metadata.pyo", line 351, in run_track_metadata_processors
  File "picard/plugin.pyo", line 479, in run
  File "/Users/jdlh/.config/MusicBrainz/Picard/plugins/classical_extras.zip/classical_extras/__init__.py", line 4153, in add_work_info
  File "/Users/jdlh/.config/MusicBrainz/Picard/plugins/classical_extras.zip/classical_extras/__init__.py", line 550, in get_options
KeyError: u'/Volumes/Qmultimedia/Music/master_tagged_files/Wagner, Richard; Vienna Philharmonic, Solti, Georg, Sir/Go\u0308tterda\u0308mmerung (feat. conductor_ Sir Georg Solti)/409 Go\u0308tterda\u0308mmerung_ War das sein Horn_ (Gutrune).flac'

I did a little investigation. Here are some observations.

  • The KeyError seems to come from Classical Extras looking up album.tagger.files[track_file].orig_metadata.
  • track_file seems to have been assigned the value album_file.filename.
  • Note that the FLAC file’s path includes u'o\u0308' and u'a\u0308'. \u0308 is U+0308 COMBINING DIAERESIS.
  • I am running on a Mac (Mac OS X 10.11.6). I understand that on the Mac, filenames are stored in Unicode’s Normalisation Form NFKD, fully decomposed. (Source: Apple TN1150, “HFS Plus defines that Unicode strings will be stored in fully decomposed form, with composing characters stored in canonical order.”)
  • I speculate that maybe album_file.filename had the ö and ä characters in composed form, which is a different set of character codes than the HFS+ filesystem’s decomposed form.

If my speculation is right, you might be able to reproduce this by giving a music file a name with ö and ä characters and running Picard 1.4 + Classical Extras 0.9.x on a Mac OS X 10.11 system. If I recall correctly, 10.12 introduced a new file system which might behave differently.

I hope this report is helpful. Please let me know if you’d like me to turn this into a Issue on the Classical Extras github repo.

You have published Classical Extras 2.0 (thanks!). I balked at trying it because you label it as “beta”. I could give it a go, however, if you think it might help.

Thanks for the kind words. I’m away at the moment (sans computer😌), but will investigate on my return on 29th.

I have tested it quite extensively, I fixed a few small bugs in 0.9.x along the way, but obviously different environments and releases may reveal other bugs, hence the beta rating. At the moment, my issues are with Picard 2.0.x (e.g. won’t run scripts) rather than the plugin, hence my warning to backup the Picard.ini file before upgrading, otherwise you won’t be able to go back.

I suspect you may be right that it is the file name causing the problem. However, I don’t have a Mac to replicate it. I created a filename with ö and ä in it which worked fine in version 2.0.1 under Windows. This code hasn’t changed from 0.9.3, but Python 3 handles unicode better than Python 2, so it is worth trying the new version (but back up the Picard.ini file!).
If it still fails, you could try turning on “full” logging in the advanced tab and sending me the log file, but I’m not sure it will cast much more light on the problem. (You could also inspect the log file to see what the line beginning “Track file found =” says).
Have you tried changing the file names?
Another thought - I have sometimes had problems with long filenames, but I think that is a Windows issue.

1 Like

This is about a recording that makes Picard hang (or crash) when using the CE plugin.

using Picard 2.0.5.dev1 on Win10:

Picard hangs at [loading track information].

I first discovered an issue with this recording because using a previously tagged track from my library it even crashes Picard.
(‘picard.exe has stopped working’)

Perhaps the plugin is sensitive to very silly titles? :wink:

.
And a general observation:
It took me some effort to find the download link to the most recent version of the plugin.
I found that this thread contains several links that will land on webpages that have old versions by now.
(0.7, 0.9.3, etc.)

Would it be an idea to have a link to the most recent version in the start post?
And perhaps delete all pages (github) that show and offer old versions?

.
edit @outsidecontext
Any chance that this great plugin could be added to the plugins offered by Picard 2.x by default?