Problems with band which has had multiple names #3402

New issue

Open

opened 2026-02-20 02:17:37 -05:00 by deekerman · 1 comment

deekerman commented

2026-02-20 02:17:37 -05:00

Owner

Originally created by @pkreuzt on GitHub (Dec 29, 2023).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

Lidarr searches only for the current band name. Trying to manually import disks from this band (RYUJIN) Lidarr doesn't recognize disks issued with the former name (GYZE). But in Lidarr's artist tab those disks are present and in MB both figure as alternate names for the band. Trying to manually assign the artist tag on import only allows to assign the current name of the band, but then again disks are not recognized because they are presented in MB with former band name.

Expected Behavior

Lidarr should search and tag disks with the corresponding band name at the moment of release, not the current one if it has changed.

Steps To Reproduce

No response

Environment

- OS: Debian GNU/Linux 12 (Bookworm) aarch64
- Lidarr: 2.0.7.3849
- Docker Install: No
- Using Reverse Proxy: Yes, Nginx
- Browser: Chromium
- Database: Sqlite 3.40.1

What branch are you running?

Master

Trace Logs?

Relevant portion of search log:

(It doesn't search for alternate names)

Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided.

I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain trace - that are relevant and show this issue.

Originally created by @pkreuzt on GitHub (Dec 29, 2023). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior Lidarr searches only for the current band name. Trying to manually import disks from this band (RYUJIN) Lidarr doesn't recognize disks issued with the former name (GYZE). But in Lidarr's artist tab those disks are present and in MB both figure as alternate names for the band. Trying to manually assign the artist tag on import only allows to assign the current name of the band, but then again disks are not recognized because they are presented in MB with former band name. ### Expected Behavior Lidarr should search and tag disks with the corresponding band name at the moment of release, not the current one if it has changed. ### Steps To Reproduce _No response_ ### Environment ```markdown - OS: Debian GNU/Linux 12 (Bookworm) aarch64 - Lidarr: 2.0.7.3849 - Docker Install: No - Using Reverse Proxy: Yes, Nginx - Browser: Chromium - Database: Sqlite 3.40.1 ``` ### What branch are you running? Master ### Trace Logs? Relevant portion of search log: 2023-12-29 14:16:42.7|Info|ReleaseSearchService|Searching indexers for [RYUJIN]. 2 active indexers 2023-12-29 14:16:45.7|Info|DownloadDecisionMaker|No results found 2023-12-29 14:16:45.7|Info|ArtistSearchService|Artist search completed. 0 reports downloaded. (It doesn't search for alternate names) ### Trace Logs have been provided as applicable. Reports may be closed if the required logs are not provided. - [X] I have read and followed the steps in the wiki link above and provided the required trace logs - the logs contain `trace` - that are relevant and show this issue.

deekerman added the

Type: Bug

Status: Needs Triage

Status: Logs Needed

labels

2026-02-20 02:17:37 -05:00

deekerman commented

2026-02-20 02:17:38 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Sep 6, 2025):

👋 @pkreuzt, In order to help you further we'll need to see logs. You'll need to enable trace logging and replicate the problem that you encountered. Guidance on how to enable trace logging can be found in our troubleshooting guide.

@github-actions[bot] commented on GitHub (Sep 6, 2025): :wave: @pkreuzt, In order to help you further we'll need to see logs. You'll need to enable trace logging and replicate the problem that you encountered. Guidance on how to enable trace logging can be found in our [troubleshooting guide](https://wiki.servarr.com/lidarr/troubleshooting#logging-and-log-files).