Classical Extras plugin (for Picard 1.4.x)

picard
classical
Tags: #<Tag:0x00007fe3d340c0e0> #<Tag:0x00007fe3d3417f80>

#161

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.


#162

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


#163

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.


#164

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.


#165

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?


#166

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.


#167

That’s because I started a new thread for 2.x :wink: (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


#168

Ah, yes.

But I have a similar suggestion for that thread also :wink:
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.


#169

Fine in theory, but I am unable to edit the start post :frowning:


#170

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).


#171

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…


#172

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.


#173

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.

It’s probably a Picard 2.0.5.dev1 issue then.


#174

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.


#175

I’ll try 2.0.5 and see.


#176

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.