Allow setting MusicBrainz server URL #482

Closed
opened 2026-02-06 19:45:31 +03:00 by OVERLORD · 5 comments
Owner

Originally created by @LeoVerto on GitHub (Mar 3, 2019).

Right now the MusicBrainz server used by Jellyfin is hard coded to https://musicbrainz.org/ here.

As with other metadata services where we should allow users to set their own API keys, I believe we should allow them to set the MB URL so those running a replicated server (either via docker or the VM image) can make use of higher rate limits, lower latency and independence from an internet connection.

Relevant Reddit discussion: https://www.reddit.com/r/jellyfin/comments/aw1bqi/feature_request_use_local_musicbrainz/

Originally created by @LeoVerto on GitHub (Mar 3, 2019). Right now the MusicBrainz server used by Jellyfin is hard coded to https://musicbrainz.org/ [here](https://github.com/jellyfin/jellyfin/blob/master/MediaBrowser.Providers/Music/MusicBrainzAlbumProvider.cs#L33). As with other metadata services where we should allow users to set their own API keys, I believe we should allow them to set the MB URL so those running a replicated server (either via [docker](https://github.com/metabrainz/musicbrainz-docker) or the [VM image](https://musicbrainz.org/doc/MusicBrainz_Server/Setup)) can make use of higher rate limits, lower latency and independence from an internet connection. Relevant Reddit discussion: https://www.reddit.com/r/jellyfin/comments/aw1bqi/feature_request_use_local_musicbrainz/
OVERLORD added the feature label 2026-02-06 19:45:31 +03:00
Author
Owner

@fruhnow commented on GitHub (Mar 8, 2019):

Maybe it would be a good idea to turn this (or in future every) Metadata-Provider into a Plugin (with its own configurationPage.html) while implementing this feature, so that the User can decide which Metadataproviders he wants to install?

Not sure if this is applicable for all Providers (e.g the ones for which we got organization-wide API keys for).

@fruhnow commented on GitHub (Mar 8, 2019): Maybe it would be a good idea to turn this (or in future every) Metadata-Provider into a Plugin (with its own configurationPage.html) while implementing this feature, so that the User can decide which Metadataproviders he wants to install? Not sure if this is applicable for all Providers (e.g the ones for which we got organization-wide API keys for).
Author
Owner

@anthonylavado commented on GitHub (Mar 8, 2019):

I forget where I commented this, but an eventual goal idea is to:

  • have all metadata providers be plug-ins
  • have an extra screen in the setup wizard that recommends plug-ins

The setup would read like:
“Metadata plug-ins provide information about your media. Here are some we recommend:”

It would then have a list of the available providers, links to their privacy policies, and if supported, a spot to put in either a URL/API key as required. This would all be configurable later as well.

@anthonylavado commented on GitHub (Mar 8, 2019): I forget where I commented this, but an eventual goal idea is to: - have all metadata providers be plug-ins - have an extra screen in the setup wizard that recommends plug-ins The setup would read like: “Metadata plug-ins provide information about your media. Here are some we recommend:” It would then have a list of the available providers, links to their privacy policies, and if supported, a spot to put in either a URL/API key as required. This would all be configurable later as well.
Author
Owner

@RazeLighter777 commented on GitHub (Mar 8, 2019):

Would some be enabled or installed by default?

@RazeLighter777 commented on GitHub (Mar 8, 2019): Would some be enabled or installed by default?
Author
Owner

@anthonylavado commented on GitHub (Mar 8, 2019):

@RazeLighter777 It’s open for debate (and will be in another issue when we start to discuss it further). My original thought was to have some “pre-selected”/opt out, but they could just be highlighted in the list instead. Hence the “Here’s some we recommend:”

@anthonylavado commented on GitHub (Mar 8, 2019): @RazeLighter777 It’s open for debate (and will be in another issue when we start to discuss it further). My original thought was to have some “pre-selected”/opt out, but they could just be highlighted in the list instead. Hence the “Here’s some we recommend:”
Author
Owner

@dkanada commented on GitHub (Oct 18, 2019):

A while ago I migrated the FanArt provider to a plugin, which was the last provider with unique settings in the core server. All providers should eventually be turned into plugins, which will not only let users remove unused providers, but also provide a dedicated location for provider options.

We hadn't actually decided on a method for these core providers yet, but converting them to plugins is actually quite straightforward. Once MusicBrainz gets converted to a plugin you can add as many unique options as you want. I'm not sure what would be useful in this case but things like parsing rules, user access tokens, and image download options would be excellent to include eventually.

@dkanada commented on GitHub (Oct 18, 2019): A while ago I migrated the FanArt provider to a plugin, which was the last provider with unique settings in the core server. All providers should eventually be turned into plugins, which will not only let users remove unused providers, but also provide a dedicated location for provider options. We hadn't actually decided on a method for these core providers yet, but converting them to plugins is actually quite straightforward. Once MusicBrainz gets converted to a plugin you can add as many unique options as you want. I'm not sure what would be useful in this case but things like parsing rules, user access tokens, and image download options would be excellent to include eventually.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#482