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

After commit ab32813972382822797657b77668cae269811568 tracks are added to wrong release




      I've ripped two CD's, Paste Magazine Sampler #48 and #41.

      With Picard 1.1 I can load them, cluster them, look-them-up, and
      everything works.

      With the git master I load and cluster them. Looking up #48 works as
      expected, but when I look up #41 its tracks get crammed (poorly) into
      Album #48. Similar misbehavior happens if I load #41 first and #48

      I used git bisect to walk the commits between 1.1 and the tip of the
      git tree and discovered that commit
      ab32813972382822797657b77668cae269811568 caused the problem.

      The bit that seems to be causing the change in behavior is in
      metadata.py:compare_to_release, at the very end of the method, where
      the score for the release is given a boost if it is in a release group
      that has already been loaded. cluster.py:_compare_to_release calls
      metadata.py:compare_to_release when it's trying to figure out where to
      put its tracks.

      This change is sufficient to cause #48
      release: u'90b66a30-878b-4c32-a943-7f87842d2a2c'
      release group: u'826bc83c-069b-3e09-aaea-a44ebb2dbcda'
      to appear to be a better match for #41 than its real release
      release: u'30979257-92ba-455f-8423-7b7509090165'
      release group: u'14338bba-34af-3a87-9932-c2c55f96b3ee'

      I'll attach three debugging traces ( from./tagger.py -d): good-trace,
      bad.trace, and bad-trace-patched-to-work.trace which are for the good
      commit, bad commit and (yep...) the bad commit with metadata.py lines
      138-140 commented out.

      Please ignore the register_save_file_processor error, that's my
      transcoding plugin that's only supported in my code.

      All three traces have this snippet in cluster.py:_lookup_finished,
      around line 186 (right after the commented out debug statement)

      for match in matches:
      self.log.debug("Track id=%r, score=%r, ", match[1].id, match[0])

      so that the tracks and their scores appear in the trace files.

      I don't have enough background to understand why the fact that one of
      the candidate releases being considered for a cluster has already been
      loaded should matter. It certainly messes up this case.

      So far, running with metadata.py lines 138-140 commented out is
      working for me, but I don't really understand the ramifications.

      Anyone have any insights?


        1. bad.trace
          38 kB
        2. bad-patched-to-work.trace
          42 kB
        3. good.trace
          42 kB

          Issue Links



              Unassigned Unassigned
              hartzell George Hartzell
              0 Vote for this issue
              1 Start watching this issue




                  Version Package