I assume “artist” is blanked before these operations (off-screen).
If there is no album_soloist or album_ensemble then all recording_artists will be put into “artist”. That might include the conductor (typically it will). So I suggest you remove the mapping on line 2. Line 3 will then operate if line 1 doesn’t do anything.
BTW, not sure why you are mapping album_ensembles to conductor at the end.
No reason, must have had it set accidentally. I reset to default settings and updated to 0.91 and did it over again
Your reply made me understand better and I got it working how I wanted (artists not including conductor, switched line 2 and line 3 mappings, put composer into album artist field for library navigation purposes), but artists_sort is still being populated with conductor. artists isn’t but artists_sort is. Any idea why?
Did you mean “composer” rather than “conductor” in this quote? (and also last “isn’t” was meant to be “is”?)
Assuming my interpretation above is correct, then you can fix the issue by blanking “~artists_sort” rather than “artists_sort” in the tag-blanking section. Picard does not have an “artists_sort” tag, only a hidden variable “_artists_sort” (which you can see if you use the viewvariables plugin). However these are referenced internally in Picard with a leading “~” rather than a “_” - so you have to blank “~artists_sort”.
EDIT: I’ll make a change in the next version so that it will blank ~artists_sort whenever artists_sort is specified.
Your interpretation was correct. Sorry for the writing mistakes (I need more sleep…)
Thank you very much for the help and your hard work on this plugin! Will install the viewvariables plugin which should come in handy in the future.
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.
-
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. -
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 
Thanks for the response!
Unfortunately, refreshing doesn’t fix the problem 
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
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