Approximately 60% of requests are now being routed to the new metadata server.
The Cache continues to build.

Author

Owner

@bakerboy448 commented on GitHub (Apr 9, 2025):

Team is aware and investigating.

*** There is currently a lidarr metadata server issue preventing searches - the devs are aware of it and will advise when it's fixed. It's not you, it's us, and we hope it won't last for too long ***

@bakerboy448 commented on GitHub (Apr 9, 2025): Team is aware and investigating. > *** There is currently a lidarr metadata server issue preventing searches - the devs are aware of it and will advise when it's fixed. It's not you, it's us, and we hope it won't last for too long ***

deekerman commented

Author

Owner

@mynameisbogdan commented on GitHub (Apr 17, 2025):

All good now.

@mynameisbogdan commented on GitHub (Apr 17, 2025): All good now.

deekerman commented

Author

Owner

@cjil commented on GitHub (May 23, 2025):

I am having the same issue today as well.

@cjil commented on GitHub (May 23, 2025): I am having the same issue today as well.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 23, 2025):

*WE ARE AWARE OF A LIDARR METADATA SERVER ISSUE - This is impacting all searches (as of the evening of 5/21). The devs are aware of the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday afternoon. We cannot provide an ETA on a fix, but it will be done as soon as the devs are able to. If there is a change in status, it will be updated here. Thank you!

@bakerboy448 commented on GitHub (May 23, 2025): ***WE ARE AWARE OF A LIDARR METADATA SERVER ISSUE** - This is impacting all searches (as of the evening of 5/21). The devs are aware of the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday afternoon. We cannot provide an ETA on a fix, but it will be done as soon as the devs are able to. If there is a change in status, it will be updated here. Thank you!

deekerman commented

2026-02-20 03:02:54 -05:00

Author

Owner

@Binocularbath commented on GitHub (May 26, 2025):

*WE ARE AWARE OF A LIDARR METADATA SERVER ISSUE - This is impacting all searches (as of the evening of 5/21). The devs are aware of the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday afternoon. We cannot provide an ETA on a fix, but it will be done as soon as the devs are able to. If there is a change in status, it will be updated here. Thank you!

Hi there. is this the same server issue that causes "Unable to communicate with LidarrAPI"?

@Binocularbath commented on GitHub (May 26, 2025): > ***WE ARE AWARE OF A LIDARR METADATA SERVER ISSUE** - This is impacting all searches (as of the evening of 5/21). The devs are aware of the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday afternoon. We cannot provide an ETA on a fix, but it will be done as soon as the devs are able to. If there is a change in status, it will be updated here. Thank you! Hi there. is this the same server issue that causes "Unable to communicate with LidarrAPI"?

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 26, 2025):

is this the same server issue that causes "Unable to communicate with LidarrAPI"?

Assuming that error relating to it is the server is down or another server side error and not local dns/ipv6 connectivity yes

@bakerboy448 commented on GitHub (May 26, 2025): > is this the same server issue that causes "Unable to communicate with LidarrAPI"? Assuming that error relating to it is the server is down or another server side error and not local dns/ipv6 connectivity yes

deekerman commented

2026-02-20 03:02:54 -05:00

Author

Owner

@HVR88 commented on GitHub (May 26, 2025):

the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday

Novel idea: Roll back the change until the issue can be identified and fixed.

@HVR88 commented on GitHub (May 26, 2025): > the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday Novel idea: Roll back the change until the issue can be identified and fixed.

deekerman commented

2026-02-20 03:02:54 -05:00

Author

Owner

@xaetacorenet commented on GitHub (May 26, 2025):

the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday

Novel idea: Roll back the change until the issue can be identified and fixed.

Second this, imho core functionality is important and i consider this a very important feature in lidarr.
The musicbrainz workaround works but is far from ideal

@xaetacorenet commented on GitHub (May 26, 2025): > > the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday > > Novel idea: Roll back the change until the issue can be identified and fixed. Second this, imho core functionality is important and i consider this a very important feature in lidarr. The musicbrainz workaround works but is far from ideal

deekerman commented

Author

Owner

@rstuke82 commented on GitHub (May 26, 2025):

Second this, imho core functionality is important and i consider this a very important feature in lidarr. The musicbrainz workaround works but is far from ideal

What is the workaround?

@rstuke82 commented on GitHub (May 26, 2025): > Second this, imho core functionality is important and i consider this a very important feature in lidarr. The musicbrainz workaround works but is far from ideal What is the workaround?

deekerman commented

Author

Owner

@AdamWHY2K commented on GitHub (May 26, 2025):

the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday

Novel idea: Roll back the change until the issue can be identified and fixed.

The change was not performed by the Lidarr team, they are just adapting to musicbrainz schema changes, so it's not something that they are able to roll back.

@AdamWHY2K commented on GitHub (May 26, 2025): > > the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday > > Novel idea: Roll back the change until the issue can be identified and fixed. The change was not performed by the Lidarr team, they are just adapting to musicbrainz schema changes, so it's not something that they are able to roll back.

deekerman commented

Author

Owner

@mvastum commented on GitHub (May 26, 2025):

Second this, imho core functionality is important and i consider this a very important feature in lidarr. The musicbrainz workaround works but is far from ideal

What is the musicbrainz workaround and how does it work? Searching for the musicbrainz ID of an artist didnt work for me.

@mvastum commented on GitHub (May 26, 2025): > Second this, imho core functionality is important and i consider this a very important feature in lidarr. The musicbrainz workaround works but is far from ideal What is the musicbrainz workaround and how does it work? Searching for the musicbrainz ID of an artist didnt work for me.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 26, 2025):

the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday

Novel idea: Roll back the change until the issue can be identified and fixed.

The suggestion is illogical. Servarr Team has no control over MusicBrainz and their schema / updates.

For support and inquiries, please use our Discord channel. GitHub is designated solely for bug reports and feature requests. It seems that recent discussions fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

@bakerboy448 commented on GitHub (May 26, 2025): > > the issue, which resulted from a musicbrainz metadata schema change that we incorporated yesterday > > Novel idea: Roll back the change until the issue can be identified and fixed. The suggestion is illogical. Servarr Team has no control over MusicBrainz and their schema / updates. For support and inquiries, please use our [Discord](http://lidarr.audio/discord) channel. GitHub is designated solely for bug reports and feature requests. It seems that recent discussions fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 27, 2025):

And for those curious in the Servarr / Lidarr metadata server part since there seems to be a lot of speculation.

All the Starrs use a private closed or semi-closed source metadata server with a Cloudflare cache.
- Radarr => TMDb
- Sonarr (Skyhook) => TVDb
- Lidarr => MusicBrainz
- Readarr => GoodReads (=> OpenLibrary one day)

Why? A central metadata is needed because relying solely on third-party services creates serious reliability, performance, and scalability issues. Lidarr users generate tens of millions of API requests daily—putting that load on external services is unsustainable and unfair. By hosting metadata ourselves, we can pull updates periodically and reduce strain on external APIs. It also allows us to normalize and correct data issues that third-party sources can’t or won’t fix. Most importantly, self-hosting protects against external outages—if a source like MusicBrainz goes offline, Lidarr remains functional. We’ve seen before with TVDB that relying entirely on external metadata sources leads to repeated disruptions. Hosting our own metadata avoids that risk and keeps us in control.

Note that for Lidarr there are issues with the Cloudflare cache not clearing thus requiring manual cache busting on discord - donors and mods can use the command to bust the cf cache.

The Lidarr metadata server is partly open sourced (e.g. only certain caching components are not) https://github.com/Lidarr/LidarrAPI.Metadata and other Lidarr Repos.

The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one ish active developer contributing to these projects, with none of the contributors working on them full-time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations. The other main Metadata infrastructure dev is assisting when they can in their limited free time due to real life responsibilities.

As previously stated, it's been the current 500 error is caused by musicbrainz latest schema change.

@bakerboy448 commented on GitHub (May 27, 2025): And for those curious in the Servarr / Lidarr metadata server part since there seems to be a lot of speculation. - All the Starrs use a private closed or semi-closed source metadata server with a Cloudflare cache. - Radarr => TMDb - Sonarr (Skyhook) => TVDb - Lidarr => MusicBrainz - Readarr => GoodReads (=> OpenLibrary one day) Why? A central metadata is needed because relying solely on third-party services creates serious reliability, performance, and scalability issues. Lidarr users generate tens of millions of API requests daily—putting that load on external services is unsustainable and unfair. By hosting metadata ourselves, we can pull updates periodically and reduce strain on external APIs. It also allows us to normalize and correct data issues that third-party sources can’t or won’t fix. Most importantly, self-hosting protects against external outages—if a source like MusicBrainz goes offline, Lidarr remains functional. We’ve seen before with TVDB that relying entirely on external metadata sources leads to repeated disruptions. Hosting our own metadata avoids that risk and keeps us in control. Note that for Lidarr there are issues with the Cloudflare cache not clearing thus requiring manual cache busting on discord - donors and mods can use the command to bust the cf cache. The Lidarr metadata server is partly open sourced (e.g. only certain caching components are not) https://github.com/Lidarr/LidarrAPI.Metadata and other Lidarr Repos. The primary development team is engaged in over five applications, including Lidarr, Prowlarr, Radarr, Readarr, Whisparr, and Sonarr. Currently, there is approximately one ish active developer contributing to these projects, with none of the contributors working on them full-time. Additionally, all members involved, whether in development or support roles, are volunteers and do not receive compensation for their contributions. Each team member balances their commitments alongside full-time jobs, family responsibilities, and other personal obligations. The other main Metadata infrastructure dev is assisting when they can in their limited free time due to real life responsibilities. As previously stated, it's been the current 500 error is caused by musicbrainz latest schema change.

deekerman commented

Author

Owner

@Daviid-P commented on GitHub (May 27, 2025):

Could we have a clearer error message in the future?

Search for 'lidarr:8d798def-1c72-4e9a-980d-db4f1e7b3f15' failed. Unable to communicate with LidarrAPI. HTTP request failed: [500:InternalServerError] [GET] at [https://api.lidarr.audio/api/v0.4/artist/8d798def-1c72-4e9a-980d-db4f1e7b3f15]

makes me think the webapp has trouble communicating with the lidarr API (everything local), not the Lidarr API having a problem communicating with Musicbrainz (external problem)

@Daviid-P commented on GitHub (May 27, 2025): Could we have a clearer error message in the future? `Search for 'lidarr:8d798def-1c72-4e9a-980d-db4f1e7b3f15' failed. Unable to communicate with LidarrAPI. HTTP request failed: [500:InternalServerError] [GET] at [https://api.lidarr.audio/api/v0.4/artist/8d798def-1c72-4e9a-980d-db4f1e7b3f15]` makes me think the webapp has trouble communicating with the lidarr API (everything local), not the Lidarr API having a problem communicating with Musicbrainz (external problem)

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 27, 2025):

The error message is accurate. LidarrApi is not working. It will not be changed.

@bakerboy448 commented on GitHub (May 27, 2025): The error message is accurate. LidarrApi is not working. It will not be changed.

deekerman commented

Author

Owner

@aalencia commented on GitHub (May 27, 2025):

The error message is accurate. LidarrApi is not working. It will not be changed.

your post was not helpful. narcisssim isn't a nice look... clearer error messages reduce communication and is always needed...

@aalencia commented on GitHub (May 27, 2025): > The error message is accurate. LidarrApi is not working. It will not be changed. your post was not helpful. narcisssim isn't a nice look... clearer error messages reduce communication and is always needed...

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 27, 2025):

The code is open source - be the change you want and submit a PR.

Given the numerous and continual offtopic comments; locked again

For support and inquiries, please use our Discord channel.

@bakerboy448 commented on GitHub (May 27, 2025): The code is open source - be the change you want and submit a PR. Given the numerous and continual offtopic comments; locked again For support and inquiries, please use our [Discord](http://lidarr.audio/discord) channel.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (May 29, 2025):

Infrastructure update

WE ARE AWARE OF A LIDARR METADATA SERVER ISSUE - This is impacting all searches (as of the evening of 5/21). Per the devs on 5/29, "Everything is pointed at new musicbrainz now. This means that new data for releases and artists should be available, but the 01-01-0001 release date is still an issue. Search is currently rebuilding, so it won't work until that process is complete." As before, there is no workaround or ETA, please be patient. We're aware that it seems like it comes and goes while things are building. If you're having an issue with searches, or adding artists, or albums not showing up, this is related to the metadata server problem described here.

@bakerboy448 commented on GitHub (May 29, 2025): Infrastructure update > **WE ARE AWARE OF A LIDARR METADATA SERVER ISSUE** - This is impacting all searches (as of the evening of 5/21). Per the devs on 5/29, "Everything is pointed at new musicbrainz now. This means that new data for releases and artists should be available, but the 01-01-0001 release date is still an issue. Search is currently rebuilding, so it won't work until that process is complete." As before, there is no workaround or ETA, please be patient. We're aware that it seems like it comes and goes while things are building. If you're having an issue with searches, or adding artists, or albums not showing up, this is related to the metadata server problem described here.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Jun 5, 2025):

Right to end this once and for all.
The Lidarr metadata is broke, we know about it and are working on it.
The source of Lidarr's metadata is open source, Our metadata cache is not because it has API keys and other sensitive information in it.
I know folks want to help but unfortunately this is something that we can't open up due to the above
We are evaluating options, ether a full rewrite or we reset teh cache and start fresh. eta of idk

@bakerboy448 commented on GitHub (Jun 5, 2025): > Right to end this once and for all. > The Lidarr metadata is broke, we know about it and are working on it. > The source of Lidarr's metadata is open source, Our metadata cache is not because it has API keys and other sensitive information in it. > I know folks want to help but unfortunately this is something that we can't open up due to the above > We are evaluating options, ether a full rewrite or we reset teh cache and start fresh. eta of idk

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Jun 12, 2025):

applying the metadata fix [from MusicBrainz] didn't work and borked things even more thus making the migration non-viable. Part of the current headache is technical debt of outdated supporting containers and less than optimal consolidation of supporting tools/code. We're exploring the least painful way to resolve the metadata as this is investigated: update retry the upgrade in place or burn and start clean.

latest update as of ~6/5 the Dev with both the Access to the metadata and the willpower to work through the code is juggling efforts in his freetime while balancing life/dayjob:

I've actually been trying to work on a rewrite. I was hoping it would be working yesterday, but still working on it. There's a bunch of async stuff going on in the old lidarr meta that has larger issues

No ETA on a fix still. If you wish to contribute to Lidarr - then work on the HUNDREDS of backlogged Sonarr Pulls / Bugs / Feature Requests.

and to reflect the current Discord Pin

THERE IS A METADATA SERVER ISSUE (6/12) This impacts all searches and imports. On 5/21, Musicbrainz pushed a schema change which broke our metadata server. The devs attempted a repair using MB's scripts, and those failed to work. The devs are currently working on a rebuild of the metadata server, but they are very short on personal time to devote to this, and it will be up when they are able to get to it. We have no ETA, nor can we provide one. There is nothing you can do to resolve this, there are no workarounds. There is no support for self-hosting your own metadata server or bypassing lidarr's metadata server. All of the arrs use their own metadata server for a number of reasons, this is not going to change. We appreciate your patience during the downtime. Please continue to use the lidarr channel for support questions only. Thank you for your continued patience.

@bakerboy448 commented on GitHub (Jun 12, 2025): applying the metadata fix [from MusicBrainz] didn't work and borked things even more thus making the migration non-viable. Part of the current headache is technical debt of outdated supporting containers and less than optimal consolidation of supporting tools/code. We're exploring the least painful way to resolve the metadata as this is investigated: update retry the upgrade in place or burn and start clean. latest update as of ~6/5 the Dev with both the Access to the metadata and the willpower to work through the code is juggling efforts in his freetime while balancing life/dayjob: > I've actually been trying to work on a rewrite. I was hoping it would be working yesterday, but still working on it. There's a bunch of async stuff going on in the old lidarr meta that has larger issues No ETA on a fix still. If you wish to contribute to Lidarr - then work on the HUNDREDS of backlogged Sonarr Pulls / Bugs / Feature Requests. and to reflect the current Discord Pin > THERE IS A METADATA SERVER ISSUE (6/12) This impacts all searches and imports. On 5/21, Musicbrainz pushed a schema change which broke our metadata server. The devs attempted a repair using MB's scripts, and those failed to work. The devs are currently working on a rebuild of the metadata server, but they are very short on personal time to devote to this, and it will be up when they are able to get to it. We have no ETA, nor can we provide one. There is nothing you can do to resolve this, there are no workarounds. There is no support for self-hosting your own metadata server or bypassing lidarr's metadata server. All of the arrs use their own metadata server for a number of reasons, this is not going to change. We appreciate your patience during the downtime. Please continue to use the lidarr channel for support questions only. Thank you for your continued patience.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Jun 17, 2025):

As a little update, all the custom packages were updated to their respective latest versions.
Now we’re working on deploying them, but we need to put the new changes in the admin scripts from musicbrainz that are hardcoded for docker to match k8s.

progress - fingers crossed we're almost there

Edit

The origin and current state of lidarr meta is a long story, but it hasn't historically had much "data engineering" even though it proably should. As far as history, a large part of it is how we interacted with MB:

Query the musicbrainz API. Too slow and caused load on MB.

Host local MB mirror. Still too slow.

Directly query the DB in the hosted mirror. This improved response times dramatically.

As the application and load on the API grew, more caching was necessary, which greatly improved things and is the general reasoning behind "don't run your own metadata".

Integration with SIR (MB's search reindexer) and using DB updates to manage the cache.

At that point, we've had some stale cache issues and the current strain of issues are due to a MB update that went wrong.

@bakerboy448 commented on GitHub (Jun 17, 2025): > As a little update, all the custom packages were updated to their respective latest versions. > Now we’re working on deploying them, but we need to put the new changes in the admin scripts from musicbrainz that are hardcoded for docker to match k8s. _progress_ - fingers crossed we're almost there Edit > The origin and current state of lidarr meta is a long story, but it hasn't historically had much "data engineering" even though it proably should. As far as history, a large part of it is how we interacted with MB: > 1. Query the musicbrainz API. Too slow and caused load on MB. > 2. Host local MB mirror. Still too slow. > 3. Directly query the DB in the hosted mirror. This improved response times dramatically. > 4. As the application and load on the API grew, more caching was necessary, which greatly improved things and is the general reasoning behind "don't run your own metadata". > 5. Integration with SIR (MB's search reindexer) and using DB updates to manage the cache. > > At that point, we've had some stale cache issues and the current strain of issues are due to a MB update that went wrong.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Jul 25, 2025):

Hi everyone, it's July 25. Yesterday, the devs and mod team here have begun (early) alpha testing of the new Lidarr metadata server.

In general, things are working fairly well. There are a few issues to resolve before it can go live. But we wanted to let everyone know that we have some concrete forward movement happening behind the scenes.

NOTE: This stage of testing is NOT OPEN to users. We appreciate your patience, but at this stage you cannot help. This update is meant to let you know that the project is not dead, as some have incorrectly theorized, and that there is behind-the-scenes work heading toward getting the new metadata server up and running as quickly as possible.

Please continue to be patient, and continue to use this channel for Lidarr support questions. If you have other conversation topics, please use ⁠general or another more appropriate channel for that.

Thank you from the devs and mod team.

@bakerboy448 commented on GitHub (Jul 25, 2025): > Hi everyone, it's July 25. Yesterday, the devs and mod team here have begun (early) alpha testing of the new Lidarr metadata server. > > In general, things are working fairly well. There are a few issues to resolve before it can go live. But we wanted to let everyone know that we have some concrete forward movement happening behind the scenes. > > NOTE: This stage of testing is NOT OPEN to users. We appreciate your patience, but at this stage you cannot help. This update is meant to let you know that the project is not dead, as some have incorrectly theorized, and that there is behind-the-scenes work heading toward getting the new metadata server up and running as quickly as possible. > > Please continue to be patient, and continue to use this channel for Lidarr support questions. If you have other conversation topics, please use ⁠general or another more appropriate channel for that. > > Thank you from the devs and mod team.

deekerman commented

https://discord.com/channels/264387956343570434/1028840582270955612/1400953758225010802

Author

Owner

@bakerboy448 commented on GitHub (Aug 1, 2025):

The current open issues we're seeing are: 1) artist images, 2) lists, 3) search result sorting, and 4) spotify artist ID lookups - related to 2) lists. Artist images may be an easy fix. Search result sorting is kind of a big one because it means when you search for something like "pink floyd", you get all the cover bands and not the actual band as a result, which you can imagine is problematic. But I'm only personally seeing that on some artists, but I see it consistently. Not having artist images doesn't bother me, but people tend to think it's important.

@bakerboy448 commented on GitHub (Aug 1, 2025): > The current open issues we're seeing are: 1) artist images, 2) lists, 3) search result sorting, and 4) spotify artist ID lookups - related to 2) lists. Artist images may be an easy fix. Search result sorting is kind of a big one because it means when you search for something like "pink floyd", you get all the cover bands and not the actual band as a result, which you can imagine is problematic. But I'm only personally seeing that on some artists, but I see it consistently. Not having artist images doesn't bother me, but people tend to think it's important. https://discord.com/channels/264387956343570434/1028840582270955612/1400953758225010802

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Aug 18, 2025):

There's an ongoing issue with the Lidarr metadata server.

This issue affects anything that requires fresh metadata, including searches and adding artists.

(The Start of) The Fix

As of August 17, we have started routing a portion of all API traffic to the new metadata server. This portion will increase over time until everything is going through the new metadata server.

What does this mean?
Some searches/adds/imports will work! Yay! But the cloudflare cache needs to rebuild, so you may see a smaller percent actually working properly until it gets built up, and you may still experience metadata server issues for a majority of your actions.

Which requests will work and which won't is entirely random. You can't influence this, and we ask that you bear with us during this phase.

Why?
While the metadata server is currently functional, some testing and work (see below) still remains. We figure this is a better solution than a longer closed beta (with only some of you users) and just letting everyone loose on the server at once and seeing it crash and burn within 5 minutes.

A couple of notes:

Artist images are currently broken. This means you're going to probably lose your Lidarr artist images until they are working again and rebuild.

The ordering of search results is not working right. This means that sometimes when you text search for artists, it might return things like cover bands, but not the real band. ID-based searches should work fine.

We recommend that if you did use an alternate metadata server during this outage, that you please revert. This will help build up cloudflare cache and make things better for everyone.

As always, thank you for your patience. The mod team here appreciates that the vast majority of users here have been patient and civil.

You can always find the latest update in the pinned messages for this channel (click the pin icon at the top right on PC, and the channel name/pin tab on mobile)

@bakerboy448 commented on GitHub (Aug 18, 2025): > ## There's an ongoing issue with the Lidarr metadata server. > This issue affects anything that requires fresh metadata, including searches and adding artists. > > ## (The Start of) The Fix > As of August 17, we have started routing a portion of all API traffic to the new metadata server. This portion will increase over time until everything is going through the new metadata server. > > ***What does this mean?*** > Some searches/adds/imports will work! Yay! But the cloudflare cache needs to rebuild, so you may see a smaller percent actually working properly until it gets built up, and you may still experience metadata server issues for a majority of your actions. > > Which requests will work and which won't is entirely random. You can't influence this, and we ask that you bear with us during this phase. > > > ***Why?*** > While the metadata server is currently functional, some testing and work (see below) still remains. We figure this is a better solution than a longer closed beta (with only some of you users) and just letting everyone loose on the server at once and seeing it crash and burn within 5 minutes. > > **A couple of notes:** > > 1) Artist images are currently broken. This means you're going to probably lose your Lidarr artist images until they are working again and rebuild. > 2) The ordering of search results is not working right. This means that sometimes when you *text search* for artists, it might return things like cover bands, but not the real band. ID-based searches should work fine. > > We recommend that if you did use an alternate metadata server during this outage, that you please revert. This will help build up cloudflare cache and make things better for everyone. > > As always, thank you for your patience. The mod team here appreciates that the vast majority of users here have been patient and civil. > > **You can always find the latest update in the pinned messages for this channel (click the pin icon at the top right on PC, and the channel name/pin tab on mobile)**

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Aug 19, 2025):

Some thoughts after 24 hr of "new metadata"

The fix is entirely on the server side. You don't need to do any changes to your Lidarr (unless you switched to an alternative metadata source)

Which requests go to the new server and which go to the old is effectively random. There's no prioritization, but more popular artists/albums have a higher change of being cached because of more requests.

All requests go through the cache first, so if the request is already cached, you'll get a response.

A text search is different from an ID search. If one is cached, the other isn't (necessarily) cached. For the moment, ID searches seems to have a higher chance of being cached.

Similarly, each album is a separate request. So you might be able to add artists, with 0 tracks, and you might be able to see some albums for that artist. This will eventually fix itself.

For the moment, most requests fail. This will improve over time, first as more requests are cached, and later as we increase the ratio of requests that go to the new server. You'll still be seeing the Unable to communicate with LidarrAPI. error for a little while, this is expected.

How can I find a musicbrainz ID?

Navigate to the artist or release group on Musicbrainz.

Find the ID at the end of the URL, OR on the Detail page, under MBID.

The ID will be a long string of letters and numbers, separated by dashes, e.g: 710e234d-e1e2-4f30-89ec-01bd71f6e4a3

Prefix the ID with lidarr: in the Add New/search box, e.g: lidarr:710e234d-e1e2-4f30-89ec-01bd71f6e4a3

Remember that an ID search is still likely to fail (for now)

Just a note on MBID's from aug's post above - Lidarr supports using /artist mbid's and /release-group mbid's, but NOT /release mbid's.

@bakerboy448 commented on GitHub (Aug 19, 2025): > ## Some thoughts after 24 hr of "new metadata" > * The fix is entirely on the server side. **You don't need to do any changes to your Lidarr** (unless you switched to an alternative metadata source) > * Which requests go to the new server and which go to the old is effectively random. There's no prioritization, but more popular artists/albums have a higher change of being cached because of more requests. > * All requests go through the cache first, so if the request is already cached, you'll get a response. > * A text search is different from an ID search. If one is cached, the other isn't (necessarily) cached. For the moment, ID searches seems to have a higher chance of being cached. > * Similarly, each album is a separate request. So you might be able to add artists, with 0 tracks, and you might be able to see *some* albums for that artist. This will eventually fix itself. > > For the moment, most requests fail. This will improve over time, first as more requests are cached, and later as we increase the ratio of requests that go to the new server. You'll still be seeing the `Unable to communicate with LidarrAPI.` error for a little while, **this is expected.** > > ### How can I find a musicbrainz ID? > 1. Navigate to the artist or release group on Musicbrainz. > 2. Find the ID at the end of the URL, **OR** on the `Detail` page, under `MBID`. > 3. The ID will be a long string of letters and numbers, separated by dashes, e.g: `710e234d-e1e2-4f30-89ec-01bd71f6e4a3` > 4. Prefix the ID with `lidarr:` in the Add New/search box, e.g: `lidarr:710e234d-e1e2-4f30-89ec-01bd71f6e4a3` > 5. Remember that an ID search is still likely to fail (for now) > > Just a note on MBID's from aug's post above - Lidarr supports using /artist mbid's and /release-group mbid's, but NOT /release mbid's. >

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Aug 22, 2025):

Multi-CD albums currently don't work, meaning that each CD will show up in Lidarr as "CD 1" and will have the tracks of that CD.

Devs are aware of the issue.

@bakerboy448 commented on GitHub (Aug 22, 2025): > Multi-CD albums currently don't work, meaning that each CD will show up in Lidarr as "CD 1" and will have the tracks of that CD. > > Devs are aware of the issue.

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Aug 28, 2025):

Approximately 60% of requests are now being routed to the new metadata server.
The Cache continues to build.

Various Updates

What should I do?

If you're starting a NEW lidarr library, you should wait. It's not ready for that.
If you're adding Spotify lists, you should wait. It's not ready for that.
If you have an existing library, run it. Hit Refresh Artists.
Do searches. The more searches you do, the more chance of getting it cached, so it's available for everyone.
Run version 2.14.0.* (currently "develop" is on that version)"nightly" or "plugins" are on that version). This changes the method of calling the metadata server to be more helpful to you. 2.14.1.* has an additional change which allows an MBID search in lidarr to not fail the artist lookup and also try album lookups, which is helpful for VA album searching (currently "nightly" and "plugins" is on that version).
If you want to help get your existing library cached, you can run @devianteng 's lidarr-cache-warmer script. That helps everyone, but it's for existing library owners only. Get it here: https://github.com/DeviantEng/lidarr-cache-warmer

How the metadata issues Present:

All unique searches are separately cached items. So if you search for an ID, it might be cached, while a search for the artist name or partial name might not.
There are 3 "gates" for caching. The artist, their album list, and the track contents of those albums.
We recommend using ID based searches for now. Instructions on how to get ID's and use them in searches is in the pinned messages.
You are going to get API errors. You're going to get 503 errors. You're going to get a Sequence Error. These are all normal, expected responses for now.

I'm getting a column error, or Torrent not enabled for this artist, when I fire up Lidarr, what's that about?

You were using the Plugins branch (or blampe's early build). You cannot jump back.

Open Issues:

Artist images may not be working.
Text based search results may not be ordered correctly.
Multi-CD releases are not working. Every CD is listed as CD 01 and additional CD's are Unmapped.
You should not be able to add Various Artists as an artist, only individual albums, but you currently can and it causes a scanning nightmare.

How can I find a Musicbrainz ID?

ID-based searches are working a LOT better than text string searches right now.

Navigate to the artist or release group on musicbrainz.org (NOT /release/!)
Find the ID at the end of the URL, OR on the Detail page, under MBID.
The ID will be a long string of letters and numbers, separated by dashes, e.g: df494a19-4657-4a77-92b6-80325c63510f
Prefix the ID with lidarr: in the Add New/search box, e.g: lidarr:df494a19-4657-4a77-92b6-80325c63510f
Remember that an ID search is still likely to fail (for now)

@bakerboy448 commented on GitHub (Aug 28, 2025): Approximately 60% of requests are now being routed to the new metadata server. The Cache continues to build. ============== # Various Updates ## What should I do? 1. If you're starting a NEW lidarr library, you should wait. It's not ready for that. 2. If you're adding Spotify lists, you should wait. It's not ready for that. 3. If you have an existing library, run it. Hit Refresh Artists. 4. Do searches. The more searches you do, the more chance of getting it cached, so it's available for everyone. 5. Run version 2.14.0.* (currently "develop" is on that version)"nightly" or "plugins" are on that version). This changes the method of calling the metadata server to be more helpful to you. 2.14.1.* has an additional change which allows an MBID search in lidarr to not fail the artist lookup and also try album lookups, which is helpful for VA album searching (currently "nightly" and "plugins" is on that version). 6. If you want to help get your existing library cached, you can run @devianteng 's lidarr-cache-warmer script. That helps everyone, but it's for existing library owners only. Get it here: https://github.com/DeviantEng/lidarr-cache-warmer ## How the metadata issues Present: 1. All unique searches are separately cached items. So if you search for an ID, it might be cached, while a search for the artist name or partial name might not. 3. There are 3 "gates" for caching. The artist, their album list, and the track contents of those albums. 4. We recommend using ID based searches for now. Instructions on how to get ID's and use them in searches is in the pinned messages. 5. You are going to get API errors. You're going to get 503 errors. You're going to get a Sequence Error. These are all normal, expected responses for now. ## I'm getting a column error, or Torrent not enabled for this artist, when I fire up Lidarr, what's that about? You were using the Plugins branch (or blampe's early build). You cannot jump back. ## Open Issues: 1) Artist images may not be working. 2) Text based search results may not be ordered correctly. 3) Multi-CD releases are not working. Every CD is listed as CD 01 and additional CD's are Unmapped. 4) You should not be able to add Various Artists as an artist, only individual albums, but you currently can and it causes a scanning nightmare. ## How can I find a Musicbrainz ID? ID-based searches are working a LOT better than text string searches right now. 1) Navigate to the artist or release group on musicbrainz.org (NOT /release/!) 2) Find the ID at the end of the URL, OR on the Detail page, under MBID. 3) The ID will be a long string of letters and numbers, separated by dashes, e.g: df494a19-4657-4a77-92b6-80325c63510f 4) Prefix the ID with lidarr: in the Add New/search box, e.g: lidarr:df494a19-4657-4a77-92b6-80325c63510f 5) Remember that an ID search is still likely to fail (for now)

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Sep 1, 2025):

Update: Changes have been pushed to the server to more properly handle multi-cd releases, and to handle properly blocking VA the way it should be handled. For multi-CD, if something has already been cached we'll have to wait for that cache to invalidate to pull in the proper multi-CD. Formats will probably all default to "CD" instead of what they actually are on MB (Vinyl, etc.).

@bakerboy448 commented on GitHub (Sep 1, 2025): > **Update: Changes have been pushed to the server to more properly handle multi-cd releases, and to handle properly blocking VA the way it should be handled. For multi-CD, if something has already been cached we'll have to wait for that cache to invalidate to pull in the proper multi-CD. Formats will probably all default to "CD" instead of what they actually are on MB (Vinyl, etc.).**

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Sep 10, 2025):

With the changes we recently made to the cache ttl and some other improvements, we're now up to 97% of our API hits going to the cache first. Some number of those are stale and still hitting the metadata server, but this is right where we want it to be.

@bakerboy448 commented on GitHub (Sep 10, 2025): > With the changes we recently made to the cache ttl and some other improvements, we're now up to 97% of our API hits going to the cache first. Some number of those are stale and still hitting the metadata server, but this is right where we want it to be. ![Image](https://github.com/user-attachments/assets/2d811976-9484-4d46-acc1-26d3b102d946)

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Sep 14, 2025):

The Lidarr devs are asking users to please turn off any warming scripts temporarily. We are now also blocking the useragent of the script. We are asking this of you so that we can get an idea of the actual load hitting the server, in an attempt to evaluate where we can increase the hits to it without overloading it. This will make things better for everyone. We will advise when you are able to start running your warmer scripts again. Thank you for your help in getting us to 100% stable!

@bakerboy448 commented on GitHub (Sep 14, 2025): > **The Lidarr devs are asking users to please turn off any warming scripts temporarily. We are now also blocking the useragent of the script. We are asking this of you so that we can get an idea of the actual load hitting the server, in an attempt to evaluate where we can increase the hits to it without overloading it. This will make things better for everyone. We will advise when you are able to start running your warmer scripts again. Thank you for your help in getting us to 100% stable!**

deekerman commented

Author

Owner

@bakerboy448 commented on GitHub (Sep 15, 2025):

Server hits have been adjusted, they were previously 80% to the new servers and 20% to the old dead server. They are now 100% to the new servers. Rate limiting is still in place, so you will continue to see 503's

@bakerboy448 commented on GitHub (Sep 15, 2025): > **Server hits have been adjusted, they were previously 80% to the new servers and 20% to the old dead server. They are now 100% to the new servers. Rate limiting is still in place, so you will continue to see 503's**

deekerman commented