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
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:
-
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.
-
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
). -
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
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_fileseems to have been assigned the valuealbum_file.filename. - Note that the FLAC file’s path includes
u'o\u0308'andu'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.filenamehad 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:
- Start Picard
- Open MB’s webpage for this release:
https://musicbrainz.org/recording/942b3636-10ec-4537-9567-d5fb76079b65?tport=8000 - Click the green ‘tagger’ icon’
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? 
.
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?
I’ll look into it when I get a moment. Re adding it to the plugin list for 2.x, that is down to me issuing a PR, which I will do when I am happy with the current version.
2 Likes
That’s because I started a new thread for 2.x 
(this one was getting rather long). You can find it here.
I wonder if a mod could rename this thread so that it is clear that it only relates to Picard 1.4.x
Ah, yes.
But I have a similar suggestion for that thread also
Only two posts, but already two different links to different versions.
Maybe it’s just me, but I prefer to have a startpost always updated with a link to the latest release.