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/axios@1.13.2/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 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.

[DuvelCorp]

@baudneo just saying : its not about defend themselves, its about providing clear feedback to users on why and how, which we didnt have before this discussion. After 1 year of Music support PR and dozen of testers feedback (amongst which I am), it is perfectly legit to ask for detailed information about why was nothing happening and what are the plans of the team about this.
Having a life doesnt prevent you to give feedback for the most regarded feature of Jellyseer.

[baudneo]

Except they have repeatedly told everyone why and that it will be merged when they are able to.

If you think because you did some testing that you are entitled to team updates and can demand timeline updates .... The sense of entitlement from users to OSS devs is absolutely jaw dropping insane. What I see here is:

• user wants stuff but doesn't have the skill or work ethic to implement themselves and is impatient
• user posts, demanding updates and putting pressure on devs for explanations and justifications on why this free software isn't doing what the users expects on the users timeline. Even if it's a polite message the underlying tone is: hurry tf up, I want it now.

Can you see how that can demoralize someone who has spent a couple thousand hours crawling source code for your enjoyment?

This is the last time I'll reply a out this, this is a thread for technical discussions about the PR, not a thread where people should be defending their choice of demanding updates from unpaid volunteers 😡

[DuvelCorp]

Except they have repeatedly told everyone why and that it will be merged when they are able to.

@baudneo .... which means strictly nothing and started to raise frustation amongs Music support testers

And now we got information and we are fine with it.

I just understand that you want to play the hero here and that everything you post is just useless and polution of a thread containing a lot of interresting information that you are now deluting. Everything you wrote are obvious things that everybody knows and think, and that doesnt bring anytthing to the Music debate.

We have demoralized no one. You just dont get anything.
Go re-read carefully all what I asked to Fallenbagel, what he answered, and what I commented. And then you can just delete your garbage for the sake of the Music support thread.

[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/axios@1.13.2/node_modules/axios/dist/node/axios.cjs:914:14)\n    
at RedirectableRequest.handleRequestError (/app/node_modules/.pnpm/axios@1.13.2/node_modules/axios/dist/node/axios.cjs:3515:25)\n    
at RedirectableRequest.emit (node:events:519:28)\n    
at eventHandlers. (/app/node_modules/.pnpm/follow-redirects@1.15.9/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/axios@1.13.2/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"} 

[tirrorex]

So since seer is now released, any update on who does what?
I don't mind jumping again on the PR aswell but having to PR on multiple repo at the same time is a big loss of time, could we streamline the implementation and for example separating PR into multiple smaller ones?

[Liquidmasl]

Seer is out? :o

[mpolom]

Seer is out? :o

Very much so
https://github.com/seerr-team/seerr

[dvub]

I've tried out the music preview branch - works really nicely so far. I was wondering if it would be possible (or if it's already planned) to create a menu to request an entire artist's discography - sort of similar to requesting multiple/all seasons of a show? there could be a toggle for everything, maybe "sub-toggles" for remixes/EPs/singles/etc., and of course toggles for individual tracks.

I also don't know if feature requests are really accepted here - so sorry if this is asking for a lot.