bug: lIstenbrainz source keep rediscovering its listens

[RustyNova016]

Please check existing knowledge before opening an issue

• I have read the Help docs
• I have checked the FAQ and documentation
• I have searched through existing issues and discussions.

Describe the Bug

I got a listenbrainz source that keeps discovering its own listens, resending them to the clients, then wait for bit only to rediscover them again. It seems like it fetch ~1 day of listens everytime, and I'm currently spamming my 3 clients with listens they already have

I sent ~7 hours of logs, but not in debug mode as restarting it fixed the loop. Hopefully it's still useful. We can clearly see there's a loop by searching for [Listenbrainz - brainzSource] Discovered => Bossfight - Charge. I may have listened to stuff while it's going on.

Added the logs as an external file as it's too big for github lol

logs.log

What configuration types are you using for multi-scrobbler? Check all that apply.

• Environmental Variables (ENV)
• Individual Config Files
• All-In-One Config File

Platform

Docker

Versions

• multiscrobler 0.12.0
• Listenbrainz from the main website

Logs

Play Debug Data

Additional Context

I do have a LB client at teh same time as a LB source, but it worked for a day without messing up so it shouldn't be an issue.

[FoxxMD]

I'm a bit stumped. From your logs it looks like its not always happening but just starts randomly. There's also a suspicious lack of [API - ListenBrainz - brainzSource] [Pagination] which is logged when MS makes api calls to get scrobbles from listenbrainz. It almost looks like its backlogging previous plays but not detecting they are already discovered...it also shouldn't be backlogging plays after it has already started.

Please try:

• enable Debug Mode so that TRACE level logging is enabled
• switch to the docker image foxxmd/multi-scrobbler:edge

If/when you see this happening again please post more logs. Also, give me an idea of:

• how long the Listenbrainz Source has been active
• what does it show for "Tracks Scrobbled" count on the dashboard?

Copy and paste the debug data for one of the duplicated scrobbles

[RustyNova016]

It's definitely happening regularly as when I go check I see a ton of failed scrobbles that are older ones (Rocksky API is unreliable). Need to catch it in the act again...
Debug mode has been turned on and will use the edge image.

But for the questions, the LB source has been active since I installed multiscrobbler. So roughly a week? The track scrobbled count keep reseting (not sure if it's a feature or not), but when it's looping it goes up to at least 2000 listens.

[FoxxMD]

The count increasing while its looping would be expected since that discovery mechanism is where the count is increased. It definitely should not be resetting, though. There is no code to reset the counter 🤔

Need to catch it in the act again...

I know its a big ask to try to re-create condition like this but: your logs show that you were listening to music (LZ Source was showing Now Playing) when some of the looping was happening. However I'm not convinced the two are related. Can you try to catch the looping happening when no other LZ Source activity is occurring?

[FoxxMD]

In addition to the above, please switch to docker image foxxmd/multi-scrobbler:pr-502. This temporarily adds a call site trace to every call to discover which should nail down what is actually calling/initiating the loop. It will be logged at the TRACE level like this

[2026-03-25 08:11:03.657 -0400] TRACE  : [App] [Sources] [Listenbrainz - lzSource] Call site trace
Error: Call site trace
    at ListenbrainzSource.discover (CWD/src/backend/sources/AbstractSource.ts:260:27)
    at ListenbrainzSource.processBacklog (CWD/src/backend/sources/AbstractSource.ts:324:43)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at ListenbrainzSource.poll (CWD/src/backend/sources/AbstractSource.ts:381:13)

There's another trace with the message addPlayToDiscovered Call site trace. Please include these in the logs you post the next time the loop happens.

Can you please also include an example of your config.json and any ENV's or other file-based configs you have setup for MS?

[RustyNova016]

Well I don't have access to the logs and config rn (and the image is still the stable release one) but it's happening again at the wrong time.

I'm not sure if the now playing state isn't unrelated either, but it's been 2 times I find it looping while playing stuff. And since I listen to 80 song per day on average... Let's hope it fails during my sleep, or during the weekend when I listen less

Here's the debug info of a looping listens

{
  "input": {
    "inserted_at": 1774436107,
    "listened_at": 1774435230,
    "recording_msid": "57cd551e-cc92-4450-b827-6cc2733f1afc",
    "track_metadata": {
      "additional_info": {
        "artist_mbids": [
          "303abdee-ffca-4685-a582-6aaaefd81b01"
        ],
        "artist_names": [
          "Carpenter Brut"
        ],
        "duration": 214,
        "music_service_name": "navidrome",
        "recording_mbid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
        "recording_msid": "57cd551e-cc92-4450-b827-6cc2733f1afc",
        "release_group_mbid": "9cfc6e0d-3367-4269-ad74-886d024b1fba",
        "release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
        "submission_client": "multi-scrobbler",
        "submission_client_version": "0.12.0",
        "tracknumber": 1
      },
      "artist_name": "Carpenter Brut",
      "mbid_mapping": {
        "artist_mbids": [
          "303abdee-ffca-4685-a582-6aaaefd81b01"
        ],
        "artists": [
          {
            "artist_credit_name": "Carpenter Brut",
            "artist_mbid": "303abdee-ffca-4685-a582-6aaaefd81b01",
            "join_phrase": ""
          }
        ],
        "caa_id": 36125549388,
        "caa_release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
        "recording_mbid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
        "recording_name": "Roller Mobster",
        "release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc"
      },
      "release_name": "EP II",
      "track_name": "Roller Mobster"
    },
    "user_name": "RustyNova"
  },
  "original": {
    "data": {
      "playDate": "2026-03-25T10:40:30.000Z",
      "track": "Roller Mobster",
      "artists": [
        "Carpenter Brut"
      ],
      "album": "EP II",
      "duration": 214,
      "meta": {
        "brainz": {
          "album": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
          "releaseGroup": "9cfc6e0d-3367-4269-ad74-886d024b1fba",
          "recording": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
          "trackNumber": 1,
          "additionalInfo": {
            "artist_mbids": [
              "303abdee-ffca-4685-a582-6aaaefd81b01"
            ],
            "artist_names": [
              "Carpenter Brut"
            ],
            "duration": 214,
            "music_service_name": "navidrome",
            "recording_mbid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
            "recording_msid": "57cd551e-cc92-4450-b827-6cc2733f1afc",
            "release_group_mbid": "9cfc6e0d-3367-4269-ad74-886d024b1fba",
            "release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
            "submission_client": "multi-scrobbler",
            "submission_client_version": "0.12.0",
            "tracknumber": 1
          },
          "artist": [
            "303abdee-ffca-4685-a582-6aaaefd81b01"
          ],
          "albumArtist": [
            "303abdee-ffca-4685-a582-6aaaefd81b01"
          ]
        }
      }
    },
    "meta": {
      "source": "multi-scrobbler",
      "playId": "57cd551e-cc92-4450-b827-6cc2733f1afc",
      "deviceId": "navidrome-multi-scrobbler-0.12.0",
      "trackid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
      "lifecycle": {
        "input": {
          "inserted_at": 1774436107,
          "listened_at": 1774435230,
          "recording_msid": "57cd551e-cc92-4450-b827-6cc2733f1afc",
          "track_metadata": {
            "additional_info": {
              "artist_mbids": [
                "303abdee-ffca-4685-a582-6aaaefd81b01"
              ],
              "artist_names": [
                "Carpenter Brut"
              ],
              "duration": 214,
              "music_service_name": "navidrome",
              "recording_mbid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
              "recording_msid": "57cd551e-cc92-4450-b827-6cc2733f1afc",
              "release_group_mbid": "9cfc6e0d-3367-4269-ad74-886d024b1fba",
              "release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
              "submission_client": "multi-scrobbler",
              "submission_client_version": "0.12.0",
              "tracknumber": 1
            },
            "artist_name": "Carpenter Brut",
            "mbid_mapping": {
              "artist_mbids": [
                "303abdee-ffca-4685-a582-6aaaefd81b01"
              ],
              "artists": [
                {
                  "artist_credit_name": "Carpenter Brut",
                  "artist_mbid": "303abdee-ffca-4685-a582-6aaaefd81b01",
                  "join_phrase": ""
                }
              ],
              "caa_id": 36125549388,
              "caa_release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
              "recording_mbid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
              "recording_name": "Roller Mobster",
              "release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc"
            },
            "release_name": "EP II",
            "track_name": "Roller Mobster"
          },
          "user_name": "RustyNova"
        },
        "original": {
          "data": {
            "playDate": "2026-03-25T10:40:30.000Z",
            "track": "Roller Mobster",
            "artists": [
              "Carpenter Brut"
            ],
            "album": "EP II",
            "duration": 214,
            "meta": {
              "brainz": {
                "album": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
                "releaseGroup": "9cfc6e0d-3367-4269-ad74-886d024b1fba",
                "recording": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
                "trackNumber": 1,
                "additionalInfo": {
                  "artist_mbids": [
                    "303abdee-ffca-4685-a582-6aaaefd81b01"
                  ],
                  "artist_names": [
                    "Carpenter Brut"
                  ],
                  "duration": 214,
                  "music_service_name": "navidrome",
                  "recording_mbid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b",
                  "recording_msid": "57cd551e-cc92-4450-b827-6cc2733f1afc",
                  "release_group_mbid": "9cfc6e0d-3367-4269-ad74-886d024b1fba",
                  "release_mbid": "5213e3c3-0d76-4347-8688-1a864b40e2bc",
                  "submission_client": "multi-scrobbler",
                  "submission_client_version": "0.12.0",
                  "tracknumber": 1
                },
                "artist": [
                  "303abdee-ffca-4685-a582-6aaaefd81b01"
                ]
              }
            }
          },
          "meta": {
            "source": "multi-scrobbler",
            "playId": "57cd551e-cc92-4450-b827-6cc2733f1afc",
            "deviceId": "navidrome-multi-scrobbler-0.12.0",
            "trackid": "0e7516a5-04a2-4d05-b8bf-3529ff274c5b"
          }
        },
        "steps": []
      }
    }
  },
  "steps": []
}

[RustyNova016]

For the scrobble count, all the sources and clients are affected. I though it only counted listens for the last 2 days or something as it's often just 2 to 1 day of listens.

According to my dashboard, I only got 115 listens on navidrome and panoscrobbler, despite LB reporting 154 listens. for monday and Tuesday. I don't listen much more than around 10 listens on LB dirrectly, so it did get reset. I also had some listens made by Alistral last week that are just gone

If it is indeed not a feature I can make another issue for it

[RustyNova016]

Here's my current config

{
    "debugMode": true,
  "clients": [
    {
      "name": "brainzClient",
      "enable": true,
      "configureAs": "client",
      "data": {
        "token": "****",
        "username": "RustyNova",
        "url": "https://api.listenbrainz.org"
      },
      "type": "listenbrainz"
    },
    {
      "name": "myRockskyClient",
      "configureAs": "client",
      "data": {
        "key": "****",
        "handle": "alephria.bsky.social"
      },
      "type": "rocksky"
    },
    {
      "name": "myLastFmClient",
      "enable": true,
      "configureAs": "client",
      "data": {
        "apiKey": "****",
        "secret": "****",
        "redirectUri": "http://listens.alephrium.com/lastfm/callback"
      },
      "type": "lastfm"
    }
  ],
  "sourceDefault": {
    "maxRequestRetries": 10
  },
  "sources": [
    {
      "name": "brainzSource",
      "enable": true,
      "configureAs": "source",
      "data": {
        "token": "****",
        "username": "RustyNova",
        "url": "https://api.listenbrainz.org"
      },
      "type": "listenbrainz"
    },
    {
      "name": "panoscrobler",
      "enable": true,
      "data": {
        "token": "****"
      },
      "type": "endpointlz"
    },
    {
      "name": "navidrome",
      "enable": true,
      "data": {
        "token": "****"
      },
      "type": "endpointlz"
    },
    {
      "name": "alistral",
      "enable": true,
      "data": {
        "token": "****"
      },
      "type": "endpointlz"
    }
  ],
  "transformers": [
    {
      "type": "musicbrainz",
      "name": "MyMB",
      "data": {
        "apis": [
          {
            "contact": "rusty.nova.jsb@gmail.com"
          }
        ]
      }
    }
  ]
}

Environment is setup through docker:

    environment:
      - TZ=Europe/Paris # Specify timezone from TZ Database name found here https://en.wikipedia.org/wiki/List_of_tz_database_time_zones
      #- JELLYFIN_APIKEY=
      #- JELLYFIN_URL=
      #- JELLYFIN_USER=
      #- MALOJA_URL=http://maloja:42010
      #- MALOJA_API_KEY=
      - PUID=1000 # required if running docker on linux host, see main README Docker setup instructions
      - PGID=1000 # required if running docker on linux host, see main README Docker setup instructions

[RustyNova016]

I can confirm that it fails on the new image as well!

However I don't have access to the logs until tomorrow. At least it didn't seem to coincide with LB having a temporary api failure, but I was listening to music during this time so can't confirm it's not linked to playing music

[RustyNova016]

Finally got the log transfer working. It's a bit of a pain as I got... 23 MB of raw logs. I had to trim it to only the log of the 25th to 28th as it's just... huge. The loop happened on the 26 before 1pm

All I have to say... Goodluck

container_logs.txt

[FoxxMD]

Thanks for the logs!

I don't see the loop on 3-26 but I did find one at 2026-03-27 10:53:57.

With the additional tracing I added it does look like the LZ Source is actually behaving relatively normally. About a minute before that it is fine:

[2026-03-27 10:51:59.978 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] Last activity at 10:50:03+01:00 (01:56 ago) | Next check in 15.00s
[2026-03-27 10:52:00.126 +0100] DEBUG  : [App] [Sources] [Listenbrainz - brainzSource] [Player Pano Scrobbler-multi-scrobbler-pr502-876c2cc-SingleUser]
Venjent - R U Guna Move (VIP) @ 10:50:03+01:00
Reported: UNKNOWN | Calculated: PLAYING | Stale: No | Orphaned: No | Player Updated At: 10:52:00+01:00 | Play Updated At: 10:52:00+01:00
Listened For: 116s 49%
[2026-03-27 10:52:00.134 +0100] DEBUG  : [App] [Scrobblers] [Listenbrainz - brainzClient] [Now Playing] Queueing Player Pano Scrob... PLAYING with Play Pano Scrobbler-multi-scrobbler-pr502-876c2cc-SingleUser Venjent - R U Guna Move (VIP) from brainzSource-listenbrainz
[2026-03-27 10:52:00.135 +0100] DEBUG  : [App] [Sources] [Listenbrainz - brainzSource] [API - ListenBrainz - brainzSource] [Pagination] [Request 1] Fetching => Limit 20
[2026-03-27 10:52:00.138 +0100] DEBUG  : [App] [Scrobblers] [Lastfm - myLastFmClient] [Now Playing] Queueing Player Pano Scrob... PLAYING with Play Pano Scrobbler-multi-scrobbler-pr502-876c2cc-SingleUser Venjent - R U Guna Move (VIP) from brainzSource-listenbrainz
[2026-03-27 10:52:00.572 +0100] DEBUG  : [App] [Sources] [Listenbrainz - brainzSource] [API - ListenBrainz - brainzSource] [Pagination] API reported 20 total results
[2026-03-27 10:52:00.573 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] [API - ListenBrainz - brainzSource] [Pagination] [Request 1] 20 results returned
[2026-03-27 10:52:00.575 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] [API - ListenBrainz - brainzSource] [Pagination] API indicated no more results, ending fetch
[2026-03-27 10:52:00.684 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] discover Call site trace
Error: discover Call site trace
    at ListenbrainzSource.discover (CWD/src/backend/sources/AbstractSource.ts:261:27)
    at ListenbrainzSource.doPolling (CWD/src/backend/sources/AbstractSource.ts:519:48)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async ListenbrainzSource.startPolling (CWD/src/backend/sources/AbstractSource.ts:425:27)
    at async ListenbrainzSource.poll (CWD/src/backend/sources/AbstractSource.ts:393:9)

and we see that its checking the (inactive) LZ source every 2 minutes

[2026-03-27 10:51:59.978 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] Last activity at 10:50:03+01:00 (01:56 ago)

About two minutes later we see

[2026-03-27 10:53:57.358 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] Last activity at 10:52:00+01:00 (01:57 ago) | Next check in 15.00s

And it starts the "loop"

[2026-03-27 10:53:57.280 +0100] TRACE  : [App] [Sources] [Listenbrainz - brainzSource] addPlayToDiscovered Call site trace
Error: addPlayToDiscovered Call site trace
    at ListenbrainzSource.addPlayToDiscovered (CWD/src/backend/sources/AbstractSource.ts:199:27)
    at ListenbrainzSource.discover (CWD/src/backend/sources/AbstractSource.ts:266:22)
    at runNextTicks (node:internal/process/task_queues:60:5)
    at listOnTimeout (node:internal/timers:545:9)
    at process.processTimers (node:internal/timers:519:7)
    at async ListenbrainzSource.doPolling (CWD/src/backend/sources/AbstractSource.ts:519:37)
    at async ListenbrainzSource.startPolling (CWD/src/backend/sources/AbstractSource.ts:425:27)
    at async ListenbrainzSource.poll (CWD/src/backend/sources/AbstractSource.ts:393:9)

What the trace tells me is that the discover call is coming from the right place. There's no rogue function or weird code accidentally calling it -- this is what it is supposed to do. The loop-like behavior comes from the fact that the discover function has a delay so the amount of time time its taking to "finish" discovery of all the plays overlaps with the next doPolling -> discover call, ~2 minutes later.

The discover function is supposed to get all these plays but they are supposed to detected as "already discovered" by discover and not passed to addPlayToDiscovered, which then ends up scrobbling them.

What is "going wrong" here is that for some reason the plays that were already discovered are somehow being erased. Or being unset on each loop? So that on each doPolling call its discovering them as if they are brand new because the old ones aren't there to be referenced against anymore. This goes back to my previous comment wherein there is no code to reset them...so something very funky is going on here. But at least we can rule out that it's some rogue/forgotten logic path in multi-scrobbler that I just missed.

[FoxxMD]

Please update to the latest pr-502 image tag. I've added more logging that should help isolate when/if the recently discovered list is reset. However, it also includes a fix for scrobble API fetching bug that I think may be a smoking gun for this...fingers crossed.