starred/Lidarr

Fork 0

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

Metadata API - Cache Busted - Album missing one track relative to musicbrainz release #4047

New issue

Closed

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

deekerman commented

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

Owner

Originally created by @Bakadori on GitHub (Nov 12, 2024).

Is there an existing issue for this?

I have searched the existing open and closed issues

Current Behavior

Lidarr import all tracks but one to one certain album. In Select Release under the Edit menu it shows two releases, one of them with the correct number of tracks, the other (the one I'm interested in) wrong (28 instead of 29 tracks). If I try to import the leftover track
(number 4) via Unmapped Files, that track is missing from the tracklist of the release. Lidarr list the correct Musicbrainz ids for release group, release and track.

Expected Behavior

Lidar should show the same number of tracks as the Musicbrainz release.

Steps To Reproduce

Add Release group cbd59809-014d-4c0c-b7c8-d21a36f6d973 (2 Son Multitud by Andres Calamaro)
In Edit, see the releases and compare the track count to the one that appears on Musicbrainz website and Picard.

Environment

- OS: Windows 10
- Lidarr: 2.7.1.4417
- Docker Install: No
- Browser: Chrome 130.0.6723.117

What branch are you running?

Master

Trace Logs?

lidarr.trace.1.txt
lidarr.trace.2.txt

Screenshot - 4

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 @Bakadori on GitHub (Nov 12, 2024). ### Is there an existing issue for this? - [X] I have searched the existing open and closed issues ### Current Behavior Lidarr import all tracks but one to one certain album. In Select Release under the Edit menu it shows two releases, one of them with the correct number of tracks, the other (the one I'm interested in) wrong (28 instead of 29 tracks). If I try to import the leftover track (number 4) via Unmapped Files, that track is missing from the tracklist of the release. Lidarr list the correct Musicbrainz ids for release group, release and track. ### Expected Behavior Lidar should show the same number of tracks as the Musicbrainz release. ### Steps To Reproduce 1. Add Release group cbd59809-014d-4c0c-b7c8-d21a36f6d973 (2 Son Multitud by Andres Calamaro) 2. In Edit, see the releases and compare the track count to the one that appears on Musicbrainz website and Picard. ### Environment ```markdown - OS: Windows 10 - Lidarr: 2.7.1.4417 - Docker Install: No - Browser: Chrome 130.0.6723.117 ``` ### What branch are you running? Master ### Trace Logs? [lidarr.trace.1.txt](https://github.com/user-attachments/files/17724760/lidarr.trace.1.txt) [lidarr.trace.2.txt](https://github.com/user-attachments/files/17724761/lidarr.trace.2.txt) ![Screenshot - 1](https://github.com/user-attachments/assets/d6c6f3d6-1741-4037-99af-09d3e168e70d) ![Screenshot - 2](https://github.com/user-attachments/assets/128e0fb0-d4aa-4560-b2cf-edda7f4d5c4b) ![Screenshot - 3](https://github.com/user-attachments/assets/05ddbb2e-1727-49b1-8902-8a60fd17d4f9) <img width="532" alt="Screenshot - 4" src="https://github.com/user-attachments/assets/3de5ab30-7df4-478c-95cb-c572d1bfbee5"> ### 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:05 -05:00

closed this issue
added the
Area: Metadata API

Type: Support.
labels

deekerman commented

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

Author

Owner

@github-actions[bot] commented on GitHub (Nov 12, 2024):

👋 @Bakadori, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please hop over onto our Discord.

@github-actions[bot] commented on GitHub (Nov 12, 2024): :wave: @Bakadori, we use the issue tracker exclusively for bug reports and feature requests. However, this issue appears to be a support request. Please hop over onto our [Discord](https://lidarr.audio/discord).

deekerman commented

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

Author

Owner

@bakerboy448 commented on GitHub (Nov 12, 2024):

https://api.lidarr.audio/api/v0.4/album/cbd59809-014d-4c0c-b7c8-d21a36f6d973

Lidarr & Lidarr metadata have all 29 tracks. It appears the release you downloaded only contains 28.

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 (Nov 12, 2024): https://api.lidarr.audio/api/v0.4/album/cbd59809-014d-4c0c-b7c8-d21a36f6d973 Lidarr & Lidarr metadata have all 29 tracks. It appears the release you downloaded only contains 28. 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:06 -05:00

Author

Owner

@bakerboy448 commented on GitHub (Nov 12, 2024):

Okay yeah something odd with track 4 - not in the metadata, but visit Discord to shake this out. Not exactly a lidarr but more a lidarr metadata bug. Cache refresh didn't fix either
https://api.lidarr.audio/api/v0.4/album/cbd59809-014d-4c0c-b7c8-d21a36f6d973

@bakerboy448 commented on GitHub (Nov 12, 2024): Okay yeah something odd with track 4 - not in the metadata, but visit Discord to shake this out. Not exactly a lidarr but more a lidarr metadata bug. Cache refresh didn't fix either https://api.lidarr.audio/api/v0.4/album/cbd59809-014d-4c0c-b7c8-d21a36f6d973

deekerman commented

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

Author

Owner

@Bakadori commented on GitHub (Nov 12, 2024):

Okay yeah something odd with track 4 - not in the metadata, but visit Discord to shake this out. Not exactly a lidarr but more a lidarr metadata bug.

Thanks @bakerboy448 for looking into it, and sorry for posting in the wrong place! I'll head to Discord.

@Bakadori commented on GitHub (Nov 12, 2024): > Okay yeah something odd with track 4 - not in the metadata, but visit Discord to shake this out. Not exactly a lidarr but more a lidarr metadata bug. Thanks @bakerboy448 for looking into it, and sorry for posting in the wrong place! I'll head to Discord.

deekerman commented

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

Author

Owner

@mboudreau commented on GitHub (Dec 8, 2025):

Yeah, something is screwed with the cache? It can't seem to find the band Architects at all. It's present on MusicBrainz, but completely missing from lidarr.

I thought this problem was fixed already?

https://github.com/Lidarr/Lidarr/issues/5498

@mboudreau commented on GitHub (Dec 8, 2025): Yeah, something is screwed with the cache? It can't seem to find the band `Architects` _at all_. It's present on MusicBrainz, but completely missing from lidarr. I thought this problem was fixed already? https://github.com/Lidarr/Lidarr/issues/5498

deekerman commented

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

Author

Owner

@augustuen commented on GitHub (Dec 26, 2025):

At the time of this issue that track was classified as a video, not as an audio recording. That's why Lidarr didn't see that track. This looks to be solved now.

@augustuen commented on GitHub (Dec 26, 2025): At the time of this issue that track was classified as a video, not as an audio recording. That's why Lidarr didn't see that track. This looks to be solved now.