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.
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.
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!!)
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.
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.
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.
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
That link seems to be a recording, not a release. If I go to the release page and load it into Picard with the plugin, it works fine for me (but I have not yet updated to Picard 2.0.5.dev1).
Correct, it’s a single track.
If it doesn’t pose a problem for you, perhaps it’s a Picard 2.0.5 issue?
Or maybe something odd is going on on my system.
Perhaps another Picard 2.0.5/Classical extras user could verify…
The plugin is designed to work with releases, not single tracks. It works OK if you load the whole release. If you only have one track of a release and you lookup/scan, then Picard will by default load the whole matching release. To prevent Classical Extras from loading all the works (at 1 second each) for the tracks you don’t have files for, go to the advanced tab and check “Do not run Classical Extras for tracks where no pre-existing file is detected”.
If you deliberately just load one track, it will hang as you describe. I will try and error trap this so it exits more cleanly.
Yes, checking that option indeed solves it for that recording.
But just in case it’s useful to you:
I created a folder with some 15 different classical recordings for testing purposes.
All single tracks from larger releases.
This recording is the only one that triggers this issue.
All others get matched fine.
(albeit slow, when that option is not checked)
.
b.t.w.
I also loaded the complete release, and that also made Picard crash.
So this is not about using the plugin with a single recording.
Interesting approach and one I might try for additional testing. However, I tend to test using whole releases.
Be aware that some functions may not work if only single tracks are provided - for example, if you choose to populate the works and movements metadata from the “Title” tag rather than the MB works data (or if you use the title data to supplement the works data), the plugin will look for repeating content on other tracks from the same work in the album in order to determine what part of the title is a work rather than a movement.
For me it’s a good way to learn and understand about how to handle all sorts of classical compositions (with the help of your plugin), making sure they end up in my player the way I like it.
It’s not intended to ‘test’ your plugin, but I thought it might be helpful to report it when I encounter issues.
).
(this one was getting rather long). You can find it 