Listens with faulty recording id can't be corrected

ListenBrainz
1

There are multiple topics with some problem in matching with MusicBrainz data, but none of them seem to match exactly my problem, so here goes yet another one. 8)

Basically: Last.fm import has filled my history with listens that have a recording ID that doesn’t exist in MusicBrainz anymore. This is apparent in the screencap where the name of the track is a link, but the artist is not, and there’s the link icon next to the track.

image
image1353×891 29.5 KB

A more recent one, from last Friday, has a recording ID that is mapped in MusicBrainz to a current ID but doesn’t match on the ListenBrainz side:

image
image1353×99 3.32 KB

Here’s the JSON from that particular listen:

{
  "inserted_at": 1702045990,
  "listened_at": 1702045780,
  "recording_msid": "d64e2f6b-d9a3-4f14-ad56-62c10d519cbe",
  "track_metadata": {
    "additional_info": {
      "rating": "",
      "recording_mbid": "36c99ff0-f395-40f3-a2eb-b23eee1c52e7",
      "recording_msid": "d64e2f6b-d9a3-4f14-ad56-62c10d519cbe",
      "source": "P",
      "track_length": "209",
      "track_number": "3"
    },
    "artist_name": "CMX",
    "mbid_mapping": {
      "recording_mbid": "36c99ff0-f395-40f3-a2eb-b23eee1c52e7"
    },
    "release_name": "Aurinko",
    "track_name": "Aivosähköä"
  },
  "user_name": "ssundell"
}

It seems you can’t “relink” this kind of listens with MusicBrainz, so I now have oodles of lines in the history that suggest there’s something to fix but I can’t do anything about them.

Also: some of my listens that have been imported from last.fm are duplicated; I’ve imported them at least once in 2019, did a reset last week and reimported, and I guess I’ve done a third one at some point since I now have three copies of a single listen for some track. I suspect this might be a symptom of the same problem, caused by differing implementations of the import doing the mapping in different ways and therefore not recognizing some of the listens as duplicates.

2

You have the exact same issue I have!

Effectively its submitted a track ID not a recording ID.

For example:
https://musicbrainz.org/recording/00c510ed-1660-378f-892b-68e5b9df1009

doesn’t work but
https://musicbrainz.org/track/ 00c510ed-1660-378f-892b-68e5b9df1009

does!

I had already raised on JIRA, but thinking about it now I’m not sure how easy this will be to remedy

1 Like
3

Hah, right, I didn’t realize it’s a working track ID :smiley:

So there are (at least) two distinct bugs in my opening message, since the later one is a listen that was submitted through Last.fm proxy and it has a recording ID, just not a current one but one that leads to a redirect.

1 Like
4

The issue with the older tracks is a bit odd. The first screenshot shows listens from 2006. At that time no recordings existed, and all the IDs where called “track IDs”. But the IDs stayed and became recording IDs when recordings where introduced. So the IDs should either still exist or be a redirect, unless the recordings have actually been deleted instead of merged.

So it’s a bit strange how listens from that time can have track IDs that did not even exist back then. It definitely did not happen with the listens I got imported from last.fm from around that time (but my import into LB has been quite some while ago).

Where these listens originally added to last.fm at that time (2006)? Or retroactively imported later on from some other source? Or maybe last.fm did some rewriting to its data!?

The newer listen from last Friday one is clearly a redirect. This might indicate that there is some issue how LB is handling redirects.

If track IDs show up for newer listens this could also be a bug with whatever tool submitted the data.

5

(I’m sure you’re asking the OP directly but)

Where these listens originally added to last.fm at that time (2006)? Or retroactively imported later on from some other source? Or maybe last.fm did some rewriting to its data!?

Mine of course start in 2008, and I know that at the time I would have been using the official Last.fm iTunes scrobbler

6

IIRC they were added to last.fm. Can’t remember, with which player/scrobbler, but I don’t remember importing anything there.

Here’s the JSON for the first one in the screenshot:

{
  "inserted_at": 1698796800,
  "listened_at": 1154498013,
  "recording_msid": "afe456f8-ddd8-4b8c-9831-16d4c2afca0d",
  "track_metadata": {
    "additional_info": {
      "artist_msid": "b2c0527e-3105-4e4e-a198-c0b31012efa3",
      "recording_mbid": "32d1f6d0-1705-38a8-a7b7-feac0e8b939f",
      "recording_msid": "afe456f8-ddd8-4b8c-9831-16d4c2afca0d",
      "release_msid": "81655e87-5f58-4a0d-ac3e-151be4c1dff4"
    },
    "artist_name": "CMX",
    "mbid_mapping": {
      "recording_mbid": "32d1f6d0-1705-38a8-a7b7-feac0e8b939f"
    },
    "release_name": "Isohaara",
    "track_name": "Revontulten repijä"
  },
  "user_name": "ssundell"
}

For me, the broken listens start at the beginning of 2006: browsing through the history, there are none in 2005, but starting from Jan 3rd 2006 almost all the listens are broken (there are no listens for 1st and 2nd of January).

This continues until Mar 1st 2019, after which practically all music starts to get mapped again. Here’s the first listen from that era:

{
  "inserted_at": 1701691136,
  "listened_at": 1551441499,
  "recording_msid": "6e717880-df44-4672-b701-1824f78a3816",
  "track_metadata": {
    "additional_info": {
      "lastfm_artist_mbid": "eec43ebc-815a-4105-b1cb-205b8f57b4fa",
      "lastfm_release_mbid": "520dd05e-1584-4a35-847f-13cf03a8b1f5",
      "lastfm_track_mbid": "00861fe8-371d-42b0-9808-8f20b5a2afc5",
      "recording_msid": "6e717880-df44-4672-b701-1824f78a3816",
      "submission_client": "ListenBrainz lastfm importer"
    },
    "artist_name": "The Beautiful South",
    "mbid_mapping": {
      "artist_mbids": [
        "eec43ebc-815a-4105-b1cb-205b8f57b4fa"
      ],
      "artists": [
        {
          "artist_credit_name": "The Beautiful South",
          "artist_mbid": "eec43ebc-815a-4105-b1cb-205b8f57b4fa",
          "join_phrase": ""
        }
      ],
      "caa_id": 6193416035,
      "caa_release_mbid": "9f71898d-a656-4299-b152-4a66a8a8fdef",
      "recording_mbid": "e553b78c-5bc3-497f-ab86-e0e4bf085b6a",
      "recording_name": "Old Red Eyes Is Back",
      "release_mbid": "79fe1d97-f967-481e-b252-9fcb4e4b6e38"
    },
    "release_name": "0898 Beautiful South",
    "track_name": "Old Red Eyes Is Back"
  },
  "user_name": "ssundell"
}

Now then, thinking about this… I did a new import last week, and it showed that the previous last.fm import timestamp was from 2019; I didn’t pay any attention to it since it wasn’t meaningful at the time, but maybe it was in February 2019 then.

Thing is: I first did the regular import, but I then noticed it was missing tracks from both the beginning of my listening history and the end, so I reset the import timestamp and imported the whole history again.

This reimport brought the 2005 listens to my history; they weren’t there previously. That kind of explains why those listens are mapped correctly. They also have "inserted_at": 1701797032 which matches last Tuesday.

Of course, the broken data’s "inserted_at": 1698796800 suggests an import from a month ago, and I have absolutely no recollection of doing such thing :smiley: I would’ve thought I had done that import in 2019, but who am I to question the timestamps…

Curiously, by the way, the import from last week has varying insert time, whereas all the broken listens have the exact same timestamp.

So, yeah. I don’t know. Export data, delete everything, reimport, cross fingers, do some kind of magic incantation to readd the listens that were submitted straight to ListenBrainz?

7

This plan stops at “export data”, as it’s currently giving me 504. :expressionless: