There are a number of relationships that Picard does not retrieve in its web look-up, namely: area, event, label, place and series. I guess there was some reason for this, but it may be that the relationships were added after Picard was initially developed and no-one added them in.
Of particular concern to me is the series relationship. Including this would help to address the issue raised in A Picard (plugin) request/wish and go some way to helping resolve the conundrum posed in BBC Music Magazine release names.
The most basic fix is really simple - just adding
, 'series-rels'
to line 437 of album.py. That would permit plugins such as Classical Extras to pick up the data, even if Picard doesn’t create any metadata tags itself.
Is there any possible objection to this? I can’t see that it would create any significant processing overhead and it is a very quick fix.
In the longer term, would it also make sense to add the other missing relationships and maybe add some tags? After all, the “use release relationships” and “use track relationships” options in Picard imply that these relationships will be provided. As it is now, you can see relationships in MB but Picard doesn’t show them.
The main reason is that Picard does currently not use this data and hence does not request the data. Picard takes care of only setting those include flags that it needs according to the current user settings. Just including everything possible conditionless would just increase server load and request time needlessly.
So there are basically two ways to handle that:
Add support for e.g. series, events etc. to Picard (maybe behind a user option). We already have a couple of tickets for things like this. It just needs somebody to implement. Patches welcome.
Do it with a plug-in right now, but this requires an additional request being made
I think this would be best. I’ll look at the tickets. The series relationship is not common and has only one attribute so the extra load would be limited.
I was trying to avoid additional requests where they are not necessary.
OK, I found Picard-711 and Picard-802. 711 seems to have been sitting unimplemented for 4 years. I think it is about time to do it as it should be quite simple. 802 appears to be a duplicate. I have added comments to both. Re the performance issue, I will do some tests.
I ran a few tests and could not find any discernible performance difference in picking up the series-rels. In other words, the normal variation in runtimes due to other factors seemed to be greater than any difference caused by looking up series rels. In fact, sometimes it was quicker with the extra inc parameter, presumably because of other factors.
I tested two releases - one small release with a series link (Release A) and one larger one without
a link (Release B). Both were tested with and without the series-rel look-up and associated tag write. In both cases, the Classical Extras plugin with the full debug log was running, with works cache enabled.
Results:
Release A: With series-rels: 2.480585s, 2.229726s, Without series-rels: 2.422615s, 2.422615s
Release B: With series-rels: 12.439924s, 13.936550s, Without series-rels: 13.983521s, 14.054480s
Obviously, this is quite a small sample size and a larger sample might elicit some measurable difference, but it does seem to support the contention that the load is negligible.
Out of interest, I also ran Release A without Classical Extras. The benchmarking is harder as I have to rely on the standard debug log, but this indicated
With series-rels: 1.648, 1.683 Without series-rels: 1.608, 1.685
(Note that the times measured by the plugin and those taken from the debug log are not directly comparable. Also note that the full debug log in Classical Extras adds quite a load - without it, the duration for release A was about 0.8s [with cached works]).
Others may have access to more sophisticated tools and a more stable platform, but I can’t see any reason not to add series-rels on performance grounds.
From the discussion at Picard-802 it would seem that release group series is more widely used than release series. Unfortunately, I think that may need an extra lookup per release which would dent performance slightly. I am confused as to the distinction between release group series and release series - I can’t find any style guidelines and the two seem to be used for similar purposes.
They are indeed very similar. Release Group series are the more general purpose ones and should be used in most instances (IMHO), but sometimes you have series like “20th anniversary remaster series” which would be a series of individual Releases that would sit inside existing Release Groups, and a Release Group series would be too broad (since presumably most of the releases in said releases groups would not be 20th anniversary remasters).
Thanks for the clarification. Regrettably, it looks like (unless changes are made to the MB webservice) an extra lookup would be required to get release group series, whereas release series could be obtained by a fairly simple mod to Picard with negligible overhead. Not quite sure where that leaves things as the ticket is for the more general issue.
I think both PICARD-711 (on a series tag) and [PICARD-802] (on a series entity) are needed.
But I’m unclear how the series tag would work, especially for release groups/releases/recordings that are part of multiple series. I’m guessing it would be something like musicbrainz_seriesid. But then it would also need to convey the item number and the total number of items in that series. Would those be something like musicbrainz_series_itemnum_4bc2a338-e1d8-4546-8a61-640da8aaf888? If not, how will they indicate that this item number is related to this particular series and not another series?