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).
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:
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?
Hi @hiccup. As per my earlier post:
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].
No. 3 is correct. In this case, _cwp_part_levels = _cwp_work_part_levels = 3. Again, you want _cwp_work_[_cwp_part_levels - 1].
1 Like
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?
Periods and dates at the bottom of the genres tab 
Full details are in the readme.
2 Likes
[insert embarrassed smiley here]
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
Thanks again.
On my system, this release is problematic:
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’.
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
1 Like
Fix is in current development version obtainable at 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.
1 Like
Looks like it all worked out fine.
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.
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.
Not at all.I said it because I would have found it helpful when I first encountered MB - and probably would still do now.
1 Like
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.
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.
1 Like
I tried to force the error by deliberately loading several similar releases.
This was the result:
These three:
succeeded.
These two:
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.
Can you refresh the ones that haven’t loaded?
Yes, the releases by themselves are not the issue.
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.
1 Like
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.
3 Likes
When I scan this single track it makes Picard shutdown instantly when the plugin is activated:
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]