Uploaded image for project: 'Picard'
  1. Picard
  2. PICARD-88

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

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Normal Normal
    • 1.0
    • 0.15, 0.15.1, 0.16
    • Tags & Metadata
    • None

      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.

          [PICARD-88] musicbrainz_workid / "MusicBrainz Work Id" doesn't appear to be working as documented

          voiceinsideyou added a comment - https://github.com/musicbrainz/picard/pull/28

          Robin Munn added a comment -

          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.

          Robin Munn added a comment - 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.

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

          voiceinsideyou added a comment - 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 -

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

          Robin Munn added a comment - 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 voiceinsideyou
            voiceinsideyou voiceinsideyou
            Votes:
            3 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:

                Version Package
                1.0