|
Thanks for the digging; just hadn't got around to doing it. Will submit a patch/tests some time shortly and get it merged. I take back my previous comment about that patch not being enough – with that one line, the musicbrainz_workid tag does get saved with the rest of the tags. The reason I wasn't seeing it is because the other tag editor I was using to verify the presence of the tags (Ex Falso from http://code.google.com/p/quodlibet/ |
||||||||||||||||||||||||||||||||||
While the Work ID is being transmitted back to Picard in the MB XML, it's not being saved anywhere in the metadata. Nowhere in the Picard source could I find a single line of code that saved a musicbrainz_workid tag, for example. The _relations_to_metadata() function in mbxml.py would seem an obvious place for that code, but it only saves metadata for artists and urls. Metadata for performances is processed in that function but never saved via an m.add(name, value) call of any kind.
The following patch would save the work ID in the metadata. It's not enough – the musicbrainz_workid tag isn't getting saved with the other musicbrainz_* tags, for example – but it's a start.
--- mbxml.py 2011-10-24 14:31:14.000000000 +0700 +++ mbxml.py.new 2012-02-22 00:40:26.137268701 +0700 @@ -100,6 +100,7 @@ for relation in relation_list.relation: if relation.type == 'performance': work = relation.work[0] + m.add("musicbrainz_workid", work.attribs['id']) if 'relation_list' in work.children: _relations_to_metadata(work.relation_list, m, config) elif relation_list.target_type == 'url':