# Classical Extras 2.0
**URL:** https://community.metabrainz.org/t/classical-extras-2-0/394627
**Category:** MusicBrainz Picard
**Tags:** classical, picard-plugins-fixme, picard
**Created:** [August 19, 2018, 10:05am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627 "2018-08-19T10:05:46Z")
**Posts on this page:** 20
**Page:** 4
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [June 26, 2019, 10:27pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/61 "2019-06-26T22:27:47Z")
> [@MetaTunes](#):
>
> (BTW I’ve found that the new movementnumber tag can get out of sequence on this one - I’m still investigating).
This is a bug which occurs if a work is split over more than one disc. The fix will be in the next release (which will be a while yet unless this is a problem for someone).
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [June 27, 2019, 4:29pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/63 "2019-06-27T16:29:49Z")
I was hoping to be able to retrieve the name of the second level of a multi-level work. (the one right after \_cwp\_work\_top)
E.g. taking these two releases as an example:
[https://musicbrainz.org/release/2af0dd60-78b7-463f-ba3b-65872ca151b4?tport=8000](https://musicbrainz.org/release/2af0dd60-78b7-463f-ba3b-65872ca151b4?tport=8000)
[https://musicbrainz.org/release/1d8ead91-e6e8-41cd-a215-bafe80b40b34?tport=8000](https://musicbrainz.org/release/1d8ead91-e6e8-41cd-a215-bafe80b40b34?tport=8000)
those would be the names in blue highlight:
For the first release it could be retrieved from cwp\_work\_1, for the second release it could be retrieved from cwp\_work\_2
I should then probably use the value in cwp\_work\_part\_levels to set a mapping to point at the correct cwp\_work\_n tag.
But while the first release has 0,1, and 2 populated, and the second one 0,1,2, and 3, for both cwp\_work\_part\_levels says 3.
Shouldn’t it say 4 for the second release?
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [June 27, 2019, 5:38pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/64 "2019-06-27T17:38:52Z")
Hi @hiccup. As per my earlier post:
> [@MetaTunes](#):
>
> There are complications when only some parts have sub-parts - e.g. [Haydn: The Creation](https://musicbrainz.org/release/ea2c0ebb-fa18-46ed-9414-e1c9e208d1b8). If you load this into Picard with the CE plugin, you will see that \_cwp\_work\_part\_levels = 3 but that for all but the last 2 tracks, \_cwp\_part\_levels = 2. The former tells you the max number of part levels in this overall work, whereas the latter tells you the number of levels in the current “branch”.
This is the case with your first release - there are other parts with more levels. So \_cwp\_part\_levels is 2 and \_cwp\_work\_part\_levels is 3. You need to get \_cwp\_work\_[\_cwp\_part\_levels - 1].
> [@hiccup](#):
>
> Shouldn’t it say 4 for the second release?
No. 3 is correct. In this case, \_cwp\_part\_levels = \_cwp\_work\_part\_levels = 3. Again, you want \_cwp\_work\_[\_cwp\_part\_levels - 1].
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [June 27, 2019, 5:53pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/65 "2019-06-27T17:53:54Z")
Hallelujah!
Thanks for helping a cripple crossing the street! 😉
You explained that you chose to have the composed year added.
Is that perhaps avoidable by some advanced setting?
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [June 27, 2019, 6:12pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/66 "2019-06-27T18:12:32Z")
> [@hiccup](#):
>
> Is that perhaps avoidable by some advanced setting?
Periods and dates at the bottom of the genres tab 😉 Full details are in the readme.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [June 27, 2019, 6:15pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/67 "2019-06-27T18:15:00Z")
> [@MetaTunes](#):
>
> Periods and dates at the bottom of the genres tab 😉 Full details are in the readme.
[insert embarrassed smiley here]
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [June 29, 2019, 4:28pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/68 "2019-06-29T16:28:34Z")
Just in case you are interested in what your plugin helped me to accomplish in regard to making it work for MusicBee, look here:
[https://getmusicbee.com/forum/index.php?topic=28999.msg161506#msg161506](https://getmusicbee.com/forum/index.php?topic=28999.msg161506#msg161506)
Thanks again.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [July 1, 2019, 4:37pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/69 "2019-07-01T16:37:32Z")
On my system, this release is problematic:
[https://musicbrainz.org/release/c7747555-4cb6-4f7a-a11e-ce3c650ad383?tport=8000](https://musicbrainz.org/release/c7747555-4cb6-4f7a-a11e-ce3c650ad383?tport=8000)
Picard will get stuck after the count-down at the right bottom reaches ‘1’.
F.w.i.w.:
I just tried again with disabling ‘use cache’, and then it will get stuck not at ‘1’, but at repetitive alternating between ‘2’ and ‘3’.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 1, 2019, 5:40pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/70 "2019-07-01T17:40:07Z")
The problem (if there is only one) is with Track 5. You will see that it is said to be 2 recordings, but the second recording is “part of” the first. This is causing an infinite loop. The plugin should detect and pass over errors of this type (and give you a warning), but for some reason it is not catching this one. Obviously the MB entry needs fixing (presumably the first recording relationship should be removed?), after which the plugin should work. But before fixing it I’d like to see why its not catching this one.
EDIT And track 7
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 1, 2019, 10:08pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/71 "2019-07-01T22:08:14Z")
Fix is in current development version obtainable at [https://github.com/MetaTunes/picard-plugins/releases/tag/2.0.5](https://github.com/MetaTunes/picard-plugins/releases/tag/2.0.5)
However, because of the circular references, the plugin has to choose which recording to use and typically picks the first one. In this case, I think the second one is correct for both tracks 5 and 7, so the best thing is to fix the MB data. At least Picard should run now. Please test it before fixing the data and let me know if any problems.
---
### Author:  [@SturmB](https://community.metabrainz.org/u/SturmB)
#### Post date: [July 3, 2019, 2:50am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/72 "2019-07-03T02:50:11Z")
> [@MetaTunes](#):
>
> I hope MB doesn’t trip itself up!
Looks like it all worked out fine.
> [@MetaTunes](#):
>
> The “performers” are those (with performer-type attributes) listed underneath the track title on the overview, not those listed as “artist” next to it.
I was actually referring to the list of relationships for a recording:
The above image is of one of the recordings on the album we’ve been talking about, but none of the relationships in that list are for “performer,” which is definitely an option for a relationship:
And all of the recordings for this album lacked a “performer” relationship, except for one. That one had the composer as the performer, so I submitted an edit (and it was accepted) to remove that relationship.
> [@MetaTunes](#):
>
> Maybe a simple pictorial guide to MB terminology would be helpful?
I feel like you’re being a bit patronizing here; not sure. But you know what? Yes, such a thing actually _would_ be helpful to a visual learner such as me.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 3, 2019, 8:42am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/73 "2019-07-03T08:42:21Z")
> [@SturmB](#):
>
> I feel like you’re being a bit patronizing here; not sure.
Not at all.I said it because I would have found it helpful when I first encountered MB - and probably would still do now.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [July 3, 2019, 1:22pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/74 "2019-07-03T13:22:03Z")
I was a bit hesitant to post this, since I haven’t (yet) been able to replicate it on a constant basis allowing to pin-point an exact cause or culprit releases.
But it does happen very frequently, so I thought to mention it anyway:
When I load several releases into Picard at the same time (let’s say five), very often Picard will hang on one of them saying [loading release information], while the others are matched.
Then, after restarting Picard, the problematic release itself never poses a problem.
As I said, I cannot pin-point it exactly, but I am pretty sure that it doesn’t happen when the different releases don’t have much in common.
Meaning: all releases from different composers, containing different works.
But as soon as I load several releases by the same composer, containing the same works, this will occur on a regular basis.
So it seems these releases are maybe not handled completely isolated from eachother internally, and maybe some shared information is spoiled to the others and then trips the plugin?
The problem is that I can not replicate it every time.
E.g. I just experienced it when loading five different releases of Dido and Aeneas.
_(yeah, I know…)_
Then I restarted Picard, ran the exact same five again, and it completed perfectly.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 3, 2019, 5:27pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/75 "2019-07-03T17:27:43Z")
Hmm. The plugin will cache works so it doesn’t have to look them up again. So if you have 5 Dido & Aeneas releases then it will look up each work once only. But the order of processing lookup responses may vary as it will have to deal with them asynchronously as and when the MB webservice returns the lookup. This may even mean that a lookup response happens on release 2 before release 1 is finished. If the recordings are linked in different ways on different releases (which quite often happens with opera) then it is quite possible that some unforeseen (i.e. not error-trapped) entanglement will occur but that a second attempt may receive lookup replies in a different sequence and run OK. That fits your experience, I think. If you let me know a set of releases that causes the problem, I can have a play around with it, but in the meantime keep the batch size down if it contains similar releases and restart if necessary.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [July 4, 2019, 9:50am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/76 "2019-07-04T09:50:45Z")
> [@MetaTunes](#):
>
> If you let me know a set of releases that causes the problem, I can have a play around with it
I tried to force the error by deliberately loading several similar releases.
This was the result:
These three:
[https://musicbrainz.org/release/1ee3f95e-82ff-421f-a6d4-2766e11c62dd?tport=8000](https://musicbrainz.org/release/1ee3f95e-82ff-421f-a6d4-2766e11c62dd?tport=8000)
[https://musicbrainz.org/release/4b7d3b7f-30d9-44a0-8e12-60614b7b06e1?tport=8000](https://musicbrainz.org/release/4b7d3b7f-30d9-44a0-8e12-60614b7b06e1?tport=8000)
[https://musicbrainz.org/release/5bc3f6ff-4ff8-4e2d-a6eb-310b36af38aa?tport=8000](https://musicbrainz.org/release/5bc3f6ff-4ff8-4e2d-a6eb-310b36af38aa?tport=8000)
succeeded.
These two:
[https://musicbrainz.org/release/76301f95-a40a-4ead-833f-efa1b88c89c7?tport=8000](https://musicbrainz.org/release/76301f95-a40a-4ead-833f-efa1b88c89c7?tport=8000)
[https://musicbrainz.org/release/1d8ead91-e6e8-41cd-a215-bafe80b40b34?tport=8000](https://musicbrainz.org/release/1d8ead91-e6e8-41cd-a215-bafe80b40b34?tport=8000)
failed.
The obvious suggestion to avoid such fails for now—until you have been able to fix the issue—would probably be to avoid loading similar releases in the same run.
The amount of releases doesn’t seem to play a role here.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 4, 2019, 11:24am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/77 "2019-07-04T11:24:02Z")
Can you refresh the ones that haven’t loaded?
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [July 4, 2019, 11:30am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/78 "2019-07-04T11:30:09Z")
Yes, the releases by themselves are not the issue.
---
### Author:  [@MetaTunes](https://community.metabrainz.org/u/MetaTunes)
#### Post date: [July 4, 2019, 1:56pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/79 "2019-07-04T13:56:12Z")
Not sure whether we are talking at cross-purposes. Your OP said that Picard hung and you restarted it. However, in my tests, Picard does not hang, it’s just that one or two of the releases do not load fully. In which case there is no need to restart Picard - just select the failed loads and click “refresh”.
It would seem to be something to do with the MB webservice interface, but it could be a bit tricky to nail down, so I’d like to be sure that it’s non-fatal as I describe.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [July 4, 2019, 3:55pm UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/80 "2019-07-04T15:55:36Z")
> [@MetaTunes](#):
>
> Your OP said that Picard hung and you restarted it.
By that I meant that while the counters had went all the way to zero for all releases, the problematic releases visually ‘hang’ at displaying: [loading album information].
There was no crash or unresponsiveness of Picard.
Restarting was my choice so to run the problematic releases with a clean slate in case the cache posed a problem. (since that was my guess when I discovered this issue)
I just tried, and I can indeed keep Picard open when these releases seem to hang, and then refreshing them individually will bring them alive again and completes the lookup.
---
### Author:  [@hiccup](https://community.metabrainz.org/u/hiccup)
#### Post date: [July 6, 2019, 10:27am UTC](https://community.metabrainz.org/t/classical-extras-2-0/394627/81 "2019-07-06T10:27:24Z")
When I scan this single track it makes Picard shutdown instantly when the plugin is activated:
[https://musicbrainz.org/recording/22872ddf-060b-485c-b99b-52cbe1f3769e](https://musicbrainz.org/recording/22872ddf-060b-485c-b99b-52cbe1f3769e)
If I don’t scan the actual file, but use the green tagger button on the website for it, Picard will not crash but say:
[could not load recording 22872ddf-060b-485c-b99b-52cbe1f3769e]
[Previous page](https://community.metabrainz.org/t/classical-extras-2-0/394627.md?page=3)
[Next page](https://community.metabrainz.org/t/classical-extras-2-0/394627.md?page=5)