This thread can be used for queries and updates regarding the current ListenBrainz status/uptime/downtime.
We are aware that ListenBrainz is currently down, for at least some users.
Admins are being kicked awake so that they can kick servers awake. Thank you for your patience as the kicking commences.
Update (thanks @zas): ListenBrainz is currently under attack from multiple distributed botnets.
We are doing our best to mitigate it, but (as almost always) they use masses of residential IPs, many UAs, and are almost impossible to block without also blocking legitmate users. Thank you for bearing with us!
Out of curiosity, would temporary blocks not be on the table for these situations?
Also, in case someone wants to know if they are part of a botnet, I used greynoiseâs website check. Might be useful for some.
Update: We (aka @zas :D) are still blocking a large amount of bot traffic, but the ListenBrainz website should be up and running for everyone (unless youâre a bot!). Thanks again for your patience.
Interestingly my Navidrome server is blocked - possibly because its listenbrainz plugin kept trying to submit the same song over and over every 5 sec for the last night after being rejected (Error HTTP 429). And I stopped it once I realized the behavior. However, I can submit through other clients, or even manually through python scripts. Maybe this is somehow the expected behavior that only certain clients are blocked even if they are from the same ip.
Now I cannot even enable listenbrainz scrobbling back on navidrome - it gives the same error (429).
Iâm having a similar problem on my DroppedNeedle instance. Trying to search from it get a âMusicBrainz albums are temporarily unavailable. Local and cached results remain available.â error or âMusicBrainz suggestions took too longâ. Been like this for hours and I stopped any polling I could see.
The navidrome issue is caused by navidrome using a generic Go user agent string, and the MB admins had to apply stricter rate limiting to this user agent, which is also heavily used by scraper bots.
See also [Bug]: Listenbrainz connection timeout error ¡ Issue #6017 ¡ navidrome/navidrome ¡ GitHub
The good news is that navidrome already merged the necessary changes and deluan is working on other improvements for the LB connection. But until the fix is available we navidrome users might be affected by this (except if maybe the bot situation allows lifting the limits a bit).
I personally might try the next develop builds of navidrome with the user agent fix.
Edit: specifically the comment [Bug]: Listenbrainz connection timeout error ¡ Issue #6017 ¡ navidrome/navidrome ¡ GitHub in the issue I linked above is a good summary of the situation
Thank you for the clarification. I should have also checked Navidrome. It is great to hear that this is being addressed. In the meantime I am back to good old Rhythmbox.
We have also had reports of multi-scrobbler being affected, but they are almost as quick as Navidrome!
They are pushing a fix here: feat: Version and user-agent improvements by FoxxMD ¡ Pull Request #680 ¡ FoxxMD/multi-scrobbler ¡ GitHub
Thanks for the work and transparency on this. I wasnât aware of the whole scrobbling part with Navidrome, so I only turned it off now. Iâll be checking around to see when itâs safe to turn it on again.
Thereâs a new blog post on the topic of recently blocked services (navidrome, multi-scrobbler, possible many othersâŚ).
It doesnât add much to what @outsidecontext covered, above, but may as well be thorough:
FYI, multiscrobbler as an uptime status for LB, MB, and CAA. Pretty useful to check if itâs not just you
Hi, does anyone know if the navidrome scrobbling issue also applies to last.fm? my scrobbles are recording correctly in last.fm so was hoping to use that to sync to listenbrainz, but they donât seem to be transferring over despite it claiming its synced.
Unfortunately, my Navidrome canât connect to ListenBrainz anymore. Typing in the token generates this error: ListenBrainz could not be linked: ListenBrainz: HTTP Error, Status: (429) I updated my docker image for navidrome, but it seems that the new solution is not implemented yet. Is there a possibility to put usernames on a whitelist? Thank you for your help.
What tag does your container target? If its âlatestâ thatâs only going to pull the latest release, these fixes are not in a release yet. But you can pull the âdevelopâ tag and that should contain the fixes. Alternatively, you can pull the âpr-6028â tag as that will also have the fixes.
Switching to PR 6028 allowed linking Listenbrainz again. Unfortunately seems my scrobbles from the last 3 days are gone though. Thanks for the tip nonethelesss!
For those deploying Navidrome on NixOS, setting services.navidrome.package to
pkgs.navidrome.overrideAttrs (prev: rec {
src = pkgs.fetchFromGitHub {
owner = "navidrome";
repo = "navidrome";
# head of PR/6028 as of 2026-08-27
rev = "8f0183e466d14dd91414743ca9202f8ee25d5bb9";
hash = "sha256-tl1bQUuOGGQljjMsNONurD5y6yG2K3QbKjAabLNgFPA=";
};
vendorHash = "sha256-SVyCW+F36yMn23CLjdDa0YCzZQLkOoCL1pMSq0qFguA=";
npmDeps = pkgs.fetchNpmDeps {
inherit src;
sourceRoot = "${src.name}/ui";
hash = "sha256-uRF9cf6HZE0gyCvGTEZ520d2gMsxmccEYLJBgc47pMg=";
};
})
fixed it for me.
Looks like the Jellyfin ListenBrainz plugin got updated as well, make sure you are updating to the latest version: Provide user agent header for ListenBrainz API calls (#180) ¡ lyarenei/jellyfin-plugin-listenbrainz@49ba618 ¡ GitHub
(if you think you got IP blocked during this time please contact MeB support here)
Thank you for your solution. I changed it back to latest tag as it is now implemented in the newest image of navidrome. ![]()
We are aware that ListenBrainz stats and playlists have failed to generate for most (?) users since 23/24 August.
Some of our dumps will not work for the foreseeable future, including all the dumps listed on the ListenBrainz data page, as well as the ListenBrainz PostgresSQL Data dump listed on the MetaBrainz data page.
If you need to discuss this with the devs, please visit the MetaBrainz channel on ChatBrainz.
(All still a result of the heavy load that our systems are buckling under - a good thing in the long term (growth) but right now itâs a large technical hurdle that the team is sweating over. More details in this blog post.)