Issue Details (XML | Word | Printable)

Key: PICARD-88
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Normal Normal
Assignee: voiceinsideyou
Reporter: voiceinsideyou
Votes: 3
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
Picard

musicbrainz_workid / "MusicBrainz Work Id" doesn't appear to be working as documented

Created: 16/Nov/11 02:28 AM   Updated: 19/Mar/12 04:23 PM   Resolved: 19/Mar/12 04:23 PM
Component/s: Tags & Metadata
Affects Version/s: 0.15, 0.15.1, 0.16
Fix Version/s: 1.0


 Description  « Hide

On http://musicbrainz.org/doc/Picard_Tag_Mapping it implies that "MusicBrainz Work Id" should be available, but testing on a release which Picard requested as http://musicbrainz.org/ws/2/release/79180d6f-cace-35c7-a305-9c7924faedef?inc=release-groups+media+recordings+puids+artist-credits+labels+isrcs+artist-rels+release-rels+url-rels+recording-rels+work-rels+recording-level-rels+work-level-rels+tags doesn't lead to these variables being available internally despite being in the response.

Needs some more investigation later.



Sort Order: Ascending order - Click to sort in descending order
Robin Munn added a comment - 21/Feb/12 05:54 PM

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':

voiceinsideyou added a comment - 22/Feb/12 12:48 AM

Thanks for the digging; just hadn't got around to doing it. Will submit a patch/tests some time shortly and get it merged.


Robin Munn added a comment - 22/Feb/12 09:28 AM

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/ if you're curious) didn't know about the musicbrainz_workid tag and thus wasn't displaying it even when it was present. Once I taught Ex Falso about the workid tag (another simple patch, a single line changed in each of about half a dozen files), I started seeing workid tags showing up with only the change above.