starred/Lidarr

Fork 0

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

Release Group ignored when manually importing #4163

New issue

Closed

opened 2026-02-20 03:01:57 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-20 03:01:57 -05:00

Owner

Originally created by @retiolus on GitHub (Feb 5, 2025).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

When I manually import an album, even if I manually set release group for all tracks, this is changed to "Lidarr" for all tracks.

Expected Behavior

Release group set when manually importing should be respected.

Steps To Reproduce

No response

Environment

- OS: Debian
- Lidarr:     2.8.2.4493

What branch are you running?

Master

Trace Logs?

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 @retiolus on GitHub (Feb 5, 2025). ### Is there an existing issue for this? - [x] I have searched the existing open and closed issues ### Current Behavior When I manually import an album, even if I manually set release group for all tracks, this is changed to "Lidarr" for all tracks. ### Expected Behavior Release group set when manually importing should be respected. ### Steps To Reproduce _No response_ ### Environment ```markdown - OS: Debian - Lidarr: 2.8.2.4493 ``` ### What branch are you running? Master ### Trace Logs? . ### 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

2026-02-20 03:01:57 -05:00

closed this issue
added the
Type: Support.
label

deekerman commented

2026-02-20 03:01:58 -05:00

Author

Owner

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

👋 @retiolus, 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 (Feb 5, 2025): :wave: @retiolus, 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 03:01:59 -05:00

Author

Owner

@Unspec7 commented on GitHub (Jun 3, 2025):

Can confirm this is still an existing issue.

@Unspec7 commented on GitHub (Jun 3, 2025): Can confirm this is still an existing issue.

deekerman commented

2026-02-20 03:01:59 -05:00

Author

Owner

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

Logs not provided; invalid bug report, closing.

This is most likely caused by your naming schema requiring group even if it does not exist thus Lidarr is the default

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

@bakerboy448 commented on GitHub (Sep 6, 2025): Logs not provided; invalid bug report, closing. This is most likely caused by your naming schema requiring group even if it does not exist thus Lidarr is the default 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 this issue may fall under a support request, so we kindly ask you to visit our Discord for assistance. Thank you.

deekerman commented

2026-02-20 03:01:59 -05:00

Author

Owner

@Unspec7 commented on GitHub (Sep 18, 2025):

@bakerboy448

This should be reopened, as it's an actual bug and not just a support issue. The problem here is that in ManualImportService.cs, release group is flat out ignored. Adding this single line:

Makes manual imports go from this:

To this:

(Forgive the ugly redactions)

The import window actually now uses the release group. However, this line only fixes the visual aspect. During the manual importing process, the release group isn't used once more and isn't passed on:

I am currently working on fixing this, and would appreciate it if this issue could be reopened :)

@Unspec7 commented on GitHub (Sep 18, 2025): @bakerboy448 This should be reopened, as it's an actual bug and not just a support issue. The problem here is that in ManualImportService.cs, release group is flat out ignored. Adding this single line: <img width="1320" height="478" alt="Image" src="https://github.com/user-attachments/assets/291c892b-2307-481b-85d6-c29def31507e" /> Makes manual imports go from this: <img width="773" height="123" alt="Image" src="https://github.com/user-attachments/assets/289c4042-c094-45fc-a944-0574c3680282" /> To this: <img width="789" height="112" alt="Image" src="https://github.com/user-attachments/assets/53e20cc6-c700-43c1-9641-33e01e962327" /> (Forgive the ugly redactions) The import window actually now uses the release group. However, this line only fixes the visual aspect. During the manual importing process, the release group isn't used once more and isn't passed on: <img width="477" height="234" alt="Image" src="https://github.com/user-attachments/assets/18d3510a-cebb-44db-a280-e7041d5cc4ba" /> I am currently working on fixing this, and would appreciate it if this issue could be reopened :)