MBID tagged albums ignored in listen stats

Recently I discovered some odd behaviour with regard to listener stats and how it attributes fully tagged recordings to albums and tracks. I will now provide some details on the issue:

As some are aware, some albums have several tracks but no titles for them. Usually they are thus given the title “[untitled]” - or, as is described in the StyleGuides, given an unofficial title akin to “[Album, Part 1]”, etc. It can thus be a challenge for any scrobbling service to correctly attribute such tracks to the correct recording. This is where MBID tags would come to good use, and looking at the corresponding listens there should be no problems:

{
  "inserted_at": 1707501525,
  "listened_at": 1707501526,
  "recording_msid": "4ecb9bdd-ff52-4474-a7a2-9a7479ac5cb8",
  "track_metadata": {
    "additional_info": {
      "albumartist": "Muslimgauze",
      "artist_mbids": [
        "06fc1189-d7cd-4344-b09a-51cd82cfefe5"
      ],
      "date": "2020-05-24",
      "discnumber": "1",
      "isrc": "NLFC30800877",
      "listening_from": "foobar2000",
      "recording_mbid": "a77c693e-959f-4262-99a0-09646e8271e2",
      "recording_msid": "4ecb9bdd-ff52-4474-a7a2-9a7479ac5cb8",
      "release_group_mbid": "fd321fc6-08b6-4c1d-a0d5-2b031ded3943",
      "release_mbid": "c8aa3fe2-cf22-40a4-b4ef-faec4e33c382",
      "totaldiscs": "1",
      "totaltracks": "22",
      "track_mbid": "8a1b173c-40e0-46c2-8df9-8a07f45dfb95",
      "tracknumber": "1"
    },
    "artist_name": "Muslimgauze",
    "mbid_mapping": {
      "artist_mbids": [
        "06fc1189-d7cd-4344-b09a-51cd82cfefe5"
      ],
      "artists": [
        {
          "artist_credit_name": "Muslimgauze",
          "artist_mbid": "06fc1189-d7cd-4344-b09a-51cd82cfefe5",
          "join_phrase": ""
        }
      ],
      "caa_id": 31058481048,
      "caa_release_mbid": "743a78d0-7b19-4dc5-91dc-75255a1e4e26",
      "recording_mbid": "a77c693e-959f-4262-99a0-09646e8271e2",
      "recording_name": "[Azzazin, Part 1]",
      "release_mbid": "743a78d0-7b19-4dc5-91dc-75255a1e4e26"
    },
    "release_name": "Azzazin",
    "track_name": "Azzazin 1"
  },
  "user_name": "Cthulhu-fi"
}

So far, so good. However, looking at my stats, I find all the listened tracks lumped together into one similar named but incorrect track and also the wrong album - this regardless of the existing IDs!

Screenshot 2024-02-11 at 16-06-01 Your Stats - ListenBrainz

Looking back at my listen feed, I can see the listens in questions attributed correctly, so I can only conclude that somewhere between Sparks and stats processing the IDs are ignored and the listens are assigned incorrectly. Why this is I can think of a couple of vectors:

  1. The release hasn’t been updated yet to the cache, thus leading the mapper to incorrectly mapping the tracks - thus this problem will possibly rectify itself if given time
  2. User mapping is leading the automatic mapping to make incorrect mappings - this is more of an ignorant guess, since I do not know the inner workings of the process
  3. Since the mapper sees several tracks with the same title, it assumes they are one and the same. In normal circumstances this is a somewhat safe assumption, but in edge cases like these, this backfires easily
  4. The release in question is a compilation that combines two releases of the same name but of different contents (in this case “Assasin”) into one whole compilation. I find Listenbrainz generally ignores compilations in stats and just goes for the albums. The remapper however apparently ignored the recording id completely and freely attributed the tracks to what it considered the more appropriate one.

So this is the situation. Hopefully I’ve provided some good information on the issue at hand.

3 Likes

Someone else pointed me to this thread which sketches the process. As far as I can tell, the MBIDs are not used in the matching.

Edit: and another more detailed post

1 Like

If recording MBIDs are given those are used directly. Other MBIDs AFAIK not (yet)

1 Like

Thank you for clarifying!