starred/Lidarr

Fork 0

mirror of https://github.com/Lidarr/Lidarr.git synced 2026-03-02 22:56:57 -05:00

`searchForNewAlbum` not working as expected when doing `POST` requests to `/api/v1/album` and not monitoring artist #3882

New issue

Open

opened 2026-02-20 02:59:55 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-20 02:59:55 -05:00

Owner

Originally created by @ano0002 on GitHub (Aug 18, 2024).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

When doing POST requests to /api/v1/album with addOptions: {searchForNewAlbum: true} if the artist hasn't already been in your lidarr and you choose to not monitor all its albums lidarr will not monitor and search for the album.

Expected Behavior

I would expect Lidarr to monitor the album in question and search for it even if you don't monitor the album.

Steps To Reproduce

Simply add any album you don't have the artist for with these parameters (from the UI or using the API):

Environment

- OS: Ubuntu 22.04.4
- Lidarr: Lidarr 2.5.1.4312
- Docker Install: Yes (pr-0260738 by hotio)
- Using Reverse Proxy:No
- Browser: -
- Database: -

What branch are you running?

Master

Trace Logs?

I did some digging around in the trace logs and here seems to be the issue:
The album monitoring is applied before the artist one.

2024-08-17 14:08:54.2|Info|ArtistScannedHandler|[Sky White Tiger] was recently added, performing post-add actions
2024-08-17 14:08:54.2|Debug|AlbumMonitoredService|[Sky White Tiger] Setting album monitored status.
2024-08-17 14:08:54.2|Debug|AlbumMonitoredService|Unmonitoring all albums

Here are logs of another time I ran it:
https://gist.github.com/ano0002/00bef4e72fc6099d7fbf7d7a87ab66e9

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 @ano0002 on GitHub (Aug 18, 2024). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior When doing `POST` requests to `/api/v1/album` with `addOptions: {searchForNewAlbum: true}` if the artist hasn't already been in your lidarr and you choose to not monitor all its albums lidarr will not monitor and search for the album. ### Expected Behavior I would expect Lidarr to monitor the album in question and search for it even if you don't monitor the album. ### Steps To Reproduce Simply add any album you don't have the artist for with these parameters (from the UI or using the API): ![image](https://github.com/user-attachments/assets/b5a3c4ca-ae0a-41ac-b1b3-84c0288440a5) ### Environment ```markdown - OS: Ubuntu 22.04.4 - Lidarr: Lidarr 2.5.1.4312 - Docker Install: Yes (pr-0260738 by hotio) - Using Reverse Proxy:No - Browser: - - Database: - ``` ### What branch are you running? Master ### Trace Logs? I did some digging around in the trace logs and here seems to be the issue: The album monitoring is applied before the artist one. ``` 2024-08-17 14:08:54.2|Info|ArtistScannedHandler|[Sky White Tiger] was recently added, performing post-add actions 2024-08-17 14:08:54.2|Debug|AlbumMonitoredService|[Sky White Tiger] Setting album monitored status. 2024-08-17 14:08:54.2|Debug|AlbumMonitoredService|Unmonitoring all albums ``` Here are logs of another time I ran it: https://gist.github.com/ano0002/00bef4e72fc6099d7fbf7d7a87ab66e9 ### 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: Logs Needed

labels

2026-02-20 02:59:55 -05:00

deekerman commented

2026-02-20 02:59:56 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Aug 18, 2024):

👋 @ano0002, 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 (Aug 18, 2024): :wave: @ano0002, 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).

deekerman commented

2026-02-20 02:59:57 -05:00

Author

Owner

@ano0002 commented on GitHub (Aug 18, 2024):

Here are logs of another time I ran it: https://gist.github.com/ano0002/00bef4e72fc6099d7fbf7d7a87ab66e9

@ano0002 commented on GitHub (Aug 18, 2024): Here are logs of another time I ran it: https://gist.github.com/ano0002/00bef4e72fc6099d7fbf7d7a87ab66e9

deekerman commented

2026-02-20 02:59:57 -05:00

Author

Owner

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

likely a race condition. can we get refreshed logs based on develop 2.14.5

various logging / other changes since 8/2024 should make this slightly more detailed to see whats the cause of dropping the monitored state from the add

@bakerboy448 commented on GitHub (Oct 5, 2025): likely a race condition. can we get refreshed logs based on develop [2.14.5](https://github.com/Lidarr/Lidarr/releases/tag/v2.14.5.4824) various logging / other changes since 8/2024 should make this slightly more detailed to see whats the cause of dropping the monitored state from the add

deekerman commented

2026-02-20 02:59:57 -05:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 5, 2025):

@github-actions[bot] commented on GitHub (Oct 5, 2025): :wave: @ano0002, 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).