Music support Support/Testing

[M0NsTeRRR]

Please use this thread as a place to discuss testing / questions related to the work-in-progress Music support feature. This will allow the PR comments to be used for code review instead of general discussion.

PR : #2132

Caution

The image below is a beta version that should not be run in production. There is ongoing work, and the seerr-team has not carefully reviewed this image. Some refactors will probably be needed and may cause issues between updates of this image.

Preview image tag :

# Github
ghcr.io/seerr-team/seerr:preview-music-support
# Dockerhub
seerr/seerr:preview-music-support

[Altheran88]

Have these latest features been merged in the develop branch ? If yes, the develop docker image might benefit from an update (or even a continuous sync, right now Jellyseerr shouts about the image being out of date.)

[Liquidmasl]

I would love to spin this up in my docker stack and give it a whirl, can someone help me out which image to deploy?

[Altheran88]

I am quite confused regarding the image inclusion of the latest updates as it is 8 month old, unless there is something I dont understand about the image inner working ? (like initiating a fresh update on start ??)

https://hub.docker.com/r/fallenbagel/jellyseerr/tags?name=preview-music-support

@M0NsTeRRR , any insight ?

[M0NsTeRRR]

Hi,
I was waiting for the linked PR to be updated with upstream (it was rebased 4 days ago). Tomorrow, I’ll do a quick review with some of the other maintainers not in depth, just to flag any potential issues. After that, we’ll add the preview image and I’ll post an update there. :)

[M0NsTeRRR]

Just to give a quick update, we're waiting for some other reviews from our team before updating the tag. We haven't forgotten about it many of us are busy like everyone else with the end of the year :)

[M0NsTeRRR]

I've updated the description with the image tag, please read the caution message before.

[QuixThe2nd]

I've just updated to seerr/seerr:preview-music-support with this error being thrown on a fresh install whenever i open the music tab:

2025-12-27T02:38:07.691Z [error][API]: Failed to retrieve fresh music releases
{"error":"Error","stack":"AggregateError: Error
    at AxiosError.from (/app/node_modules/.pnpm/[email protected]/node_modules/axios/dist/node/axios.cjs:914:14)
    at TLSSocket.socketErrorListener (node:_http_client:518:5)
    at TLSSocket.emit (node:events:519:28)
    at async ListenBrainzAPI.get (/app/dist/api/externalapi.js:43:26)
    at async /app/dist/routes/discover.js:613:35"
}

(I've shortened the stack trace)

Surely I can't be the only one facing a similar issue? Is anyone aware what hostname it might be calling?

services:
  jellyseerr:
    image: seerr/seerr:preview-music-support
    container_name: jellyseerr
    user: 1000:1000
    environment:
      - LOG_LEVEL=debug
      - TZ=Australia/Sydney
      - PORT=5055
    ports:
      - 5055:5055
    volumes:
      - ./config3:/app/config

[formeo14]

Is there a timeline when the music branch will be merged? As it already takes quite a while.

[fallenbagel]

The PR is huge because it basically makes jellyseer media capabilities going from x2 to x3, isnt that HUGE? :)

I have been thinking (need to discuss this with the team, this is just my own personal opinion, not speaking for the team here) that we might need to request the author to divide this PR into small prs.

That's exactly what the OIDC pr author did and why we have been able to slowly merge in the foundation for OIDC support. OIDC pr author closed the original pr, divided it into several small prs that we already merged in and the only remaining PR now is the one that adds the OIDC login (which has already been reviewed by me and will be merged first thing after seerr release).

I would very much appreciate if the PR can be divided like this. (But then again this is just my own opinion).

CC: @seerr-team/seerr-core

[fallenbagel]

The actual image is too old and way behind to really bring something new and appeal more testers.

Don't worry, we will update the image c:

[DuvelCorp]

The actual image is too old and way behind to really bring something new and appeal more testers.

Don't worry, we will update the image c:

Great. If you can make a Seer + OID + Music image that is even better :D

On a side note, my personal feeling about all your concerns :
This PR basically adds Lidarr integration.
Radarr, Sonarr and Lidarr (and Readarr/Prowlarr/Wisparr) are the same ecosystem, coded and/or reviewed, and controlled by the same people, and they follow the same approaches and standards, and share the same building blocks and architecture.
This is de facto limiting the maintenance or understanding problems you can have with this part of the application in the future. Its not like the music PR would interact with something entirely different. It is different, but it has the same roots and programming approaches as for movies and series.

[fallenbagel]

The actual image is too old and way behind to really bring something new and appeal more testers.

Don't worry, we will update the image c:

Great. If you can make a Seer + OID + Music image that is even better :D

On a side note, my personal feeling about all your concerns :
This PR basically adds Lidarr integration. Radarr, Sonarr and Lidarr (and Readarr/Prowlarr/Wisparr) are the same ecosystem, coded and/or reviewed, and controlled by the same people, and they follow the same approaches and standards. This is de facto limiting the maintenance problems you can have with this part of the application. Its not like the music PR would interact with something entirely different. It is diffreent, but it has the same roots and approaches as for movies and series.

I'm not questioning the standards of Lidarr or how the *arr apps work. Those applications are indeed well-maintained and follow good practices.

However, that doesn't automatically mean the integration code in our app follows the same standards. The quality of Lidarr as an external service is separate from how that integration is implemented within Seerr. Even if we're connecting to a well-built API, the integration layer itself could have code quality issues, introduce technical debt, or create maintenance burdens specific to our codebase.

Additionally, while Radarr and Sonarr integrations share similar patterns, that doesn't mean a Lidarr integration will be straightforward to maintain. Music metadata works differently than movies and TV shows due to different data structures, different edge cases, different user expectations, different metadata provider with different api limitstions and api structure. The fact that they're in the same ecosystem doesn't eliminate the need for thorough review of how this specific feature is architected and implemented in our application.

We need to evaluate this PR on its own merits: the code quality, the architectural decisions made, how it fits into our existing codebase, and whether we can realistically maintain it long-term. That's independent of how well the *arr apps themselves are built.

[baudneo]

The fact that you need to constantly defend yourselves in these status threads is infuriating. You dont owe all these people walls of text defending your workflows and having to breakdown the rationale behind your workflows. While I do appreciate the transparency and well-mannered responses, it gives impatient, demanding people an in-road to expecting a status update anytime they feel like dev isnt going fast enough for their made-up timeline.

For the love of god people, let these devs work on the project in peace! We have no idea whats going on behind the scenes and we also ARE NOT PAYING THESE PEOPLE to use their spare time to make this wonderful project for us. Unless you have something relevant to the PR or find some sort of bug in the previews, please stop asking "merge when", it doesnt make anything faster (might even demoralize someone, thus making it slower).

These devs have a life outside of work and these side projects and we should respect that.

[Harriotskelli]

Any word on these errors?

brand new install of seerr/seerr:preview-music-support
when I exec into the container I can wget the MusicBrainz and ListenBrainz APIs without issue.

2026-01-28T00:27:54.987Z [error][API]: Failed to retrieve fresh music releases {"error":"Error","stack":"AggregateError: Error\n    
at AxiosError.from (/app/node_modules/.pnpm/[email protected]/node_modules/axios/dist/node/axios.cjs:914:14)\n    
at RedirectableRequest.handleRequestError (/app/node_modules/.pnpm/[email protected]/node_modules/axios/dist/node/axios.cjs:3515:25)\n    
at RedirectableRequest.emit (node:events:519:28)\n    
at eventHandlers. (/app/node_modules/.pnpm/[email protected]/node_modules/follow-redirects/index.js:49:24)\n    
at ClientRequest.emit (node:events:519:28)\n    
at emitErrorEvent (node:_http_client:105:11)\n    
at TLSSocket.socketErrorListener (node:_http_client:518:5)\n    
at TLSSocket.emit (node:events:519:28)\n    
at emitErrorNT (node:internal/streams/destroy:170:8)\n    
at emitErrorCloseNT (node:internal/streams/destroy:129:3)\n    
at Axios.request (/app/node_modules/.pnpm/[email protected]/node_modules/axios/dist/node/axios.cjs:4731:41)\n    
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)\n    
at async ListenBrainzAPI.get (/app/dist/api/externalapi.js:43:26)\n    
at async /app/dist/routes/discover.js:613:35"}
2026-01-28T00:27:56.869Z [error][API]: Failed to retrieve popular music {"error":"Error"}
2026-01-28T00:27:56.872Z [error][API]: Failed to retrieve popular artists {"error":"Error"}