Feature Request: Native Plugin UI Support for Seerr & Music Requests + Albums, Singles & EPs Separation

[Samus512 2]

Hi,

I’ve been doing quite a bit of development around my Emby setup recently, particularly around requests and music organization. In the process I’ve managed to get some functionality working that Emby doesn’t currently provide natively, and it made me wonder whether some additional native plugin UI extension points could make this type of integration much cleaner and useful to other plugin developers as well.

There are really three related things I’d love to see:

• Better native plugin UI extension support
• Native Seerr discovery/request integration through a plugin
• Proper separation of Albums, Singles & EPs, Live releases, etc. on music artist pages, with the ability for a plugin to provide music requests as well

The first one is really what makes the other ideas much more powerful.

I already have Seerr requests appearing inside Emby

This isn’t entirely theoretical in my setup.

I’ve already built a working My Requests section for Emby that integrates with Seerr.

My users can have their Seerr requests represented directly on the Emby Home screen rather than having to go back to Seerr just to see what they’ve requested.

The implementation currently uses a custom version of Home Screen Sections Creator / HomeScreenCompanion, along with a request integration service.

The basic flow is:

Seerr
↓
Request integration
↓
Per-user Emby request collections
↓
HomeScreenCompanion
↓
Emby Home Section
↓
Official Emby client

Each Emby user gets their own request data rather than everybody sharing one global request row.

Internally, the integration creates per-user Home Section sources associated with generated Emby collections. HomeScreenCompanion uses Emby’s existing Home Section functionality to expose those collections.

Because the official clients already understand Home Sections and collections, they render the result using normal Emby UI components.

So from the user’s perspective, My Requests appears as another row in Emby.

That’s the part I really like about it.

It doesn’t look like I’ve embedded another website inside Emby.

Emby itself renders the row.

Where the current implementation becomes limited

The current solution works, but it also demonstrates why I’d love to see a proper native plugin UI API.

We’re essentially taking advantage of UI concepts Emby already exposes to the server:

Home Sections + Collections

That means we’re limited to the places where Emby already allows the server to influence the client.

For example, I can create something like:

My Requests

on the Home screen.

But I can’t have the plugin cleanly say:

Add a Request button to this movie.

or:

Add a Request Music action to this artist.

or:

Add a Singles & EPs row to this artist page.

or:

Add a Discover section backed by Seerr.

Those layouts are controlled by the clients.

I also experimented with client-side web modifications where necessary, but obviously that only helps Emby Web. It doesn’t give me the same functionality in the official Android TV, Android and iOS applications.

That’s really what led me to this feature request.

The server plugin side can already do a lot.

What’s missing is a standardized way for a plugin to tell the official clients:

“Here is some structured data or an action I’d like you to render using your native Emby components.”

What I think would make this much better

Rather than every plugin finding creative ways to manipulate Home Sections or patch the web client, I’d love to see Emby provide a controlled native plugin UI extension framework.

I’m not suggesting that plugins should be able to inject arbitrary HTML or completely redesign an Emby client.

I’d actually prefer the opposite.

The plugin could register structured UI elements and Emby’s official client would decide how to render them.

For example, a plugin might register:

• Home Screen section
• Discover section
• Detail-page action
• Context-menu action
• Artist-page action
• Media row
• Status badge
• Search provider
• Request provider
• Plugin-backed detail page

The server could return structured information such as:

Section type: MediaRow
Title: My Requests
Items: […]

or:

Action: Request
Item: Movie XYZ
Provider: Seerr

and the official client could render that using its existing components.

That would keep Android TV, Android, iOS, Web and other clients visually consistent while still allowing plugins to provide much richer integrations.

Native Seerr integration

Seerr is probably the clearest example of where this could be useful.

I’d love to have a proper Seerr server plugin where users can discover and request content without leaving Emby.

Imagine opening the official Emby app and having a native:

Discover

section.

Inside it could be things such as:

Trending

Popular Movies

Popular TV

Upcoming

Recommended

Similar Titles

Those results could come from Seerr but be rendered by Emby’s native UI.

The important difference from a normal Emby library would be that some of those titles don’t exist on the server yet.

Instead of Play, they would have:

Request

Selecting Request could send:

Emby client
→ Emby server plugin
→ Seerr

The client doesn’t need Seerr credentials.

The plugin keeps all of that server-side.

The item’s state could then progress through something like:

Request

→ Requested

→ Approved

→ Searching

→ Downloading

→ Processing

→ Available

Once the requested item reaches the Emby library, the normal Play experience takes over.

Searching could become much more useful too

I’d also love for a request provider to optionally participate in search.

For example, I search Emby for a movie that isn’t currently in my library.

Today, Emby understandably can’t return something it doesn’t have.

With an optional discovery/request provider, it could potentially show:

IN YOUR LIBRARY

existing results

and then:

AVAILABLE TO REQUEST

external results supplied by Seerr.

Selecting one could open a native Emby-style details page with:

Request

instead of:

Play

That would make the experience extremely natural for users.

They wouldn’t even necessarily need to understand what Seerr is.

They would just know:

If it’s available, I can play it. If it isn’t available, I can request it.

My Requests could become properly native

The My Requests row I’ve already implemented is another example.

My current solution works by translating Seerr request information into structures Emby already knows how to display.

With native plugin support, the plugin wouldn’t need to manufacture collections just to get a request row onto the Home screen.

Instead it could register something conceptually like:

Home Section: My Requests

and provide the items directly.

The plugin could supply additional metadata that collections aren’t designed to represent, such as:

Requested

Approved

Searching

Downloading

Processing

Available

Failed

That would make the existing idea considerably more useful.

The same integration could potentially provide:

My Requests

Recently Available Requests

Trending to Request

or other administrator-configurable sections.

Permissions could remain per-user.

One user’s request history should never automatically appear for another user.

Music is where I ran into the same limitation again

I’ve also been working on improving how music is presented in Emby.

Right now, an artist’s releases generally end up together under Albums.

I’d love to see native artist pages separated into something like:

Songs

Albums

Singles & EPs

Live

Compilations

Other Releases

More Like This

Empty sections could simply remain hidden.

For example, Linkin Park could have:

Albums

Hybrid Theory
Meteora
Minutes to Midnight
From Zero
etc.

Then separately:

Singles & EPs

One Step Closer
Papercut
Faint
etc.

And live releases would have their own section rather than being mixed into Albums.

I’ve already built a working release classifier

This part isn’t just an idea either.

I’ve built a MusicBrainz-based release classification system against my Emby music library.

It classifies releases into:

• Albums
• Singles & EPs
• Live
• Compilations
• Other Releases

I’m using MusicBrainz release/release-group identity rather than simplistic rules such as:

fewer than X tracks = single

because that produces incorrect classifications.

I also built a working reference interface that renders those release types as separate artist-page rows.

For one of my test artists, Linkin Park, the current classifier identifies 27 releases and separates them into Albums and Singles & EPs appropriately.

I’ve tested other artists containing Live releases as well, and the Live row is automatically generated when appropriate.

Empty rows disappear automatically.

So I’ve been able to demonstrate the user experience.

The limitation is the same one I encountered with requests:

I can control the server and I can modify Emby Web, but I can’t tell the official native clients to add another artist-page row.

That’s why I think these seemingly different feature requests actually share the same underlying issue.

Music requests could use the same plugin framework

I’d also love to be able to request missing music directly from Emby.

In my setup the acquisition/request backend is Dropped Needles, but just like Seerr, I don’t think Emby should have to specifically maintain support for it.

I’d rather have a generic:

Music Request Provider

A plugin could implement that provider.

Then an artist page could potentially have:

Play · Shuffle · Request Music

Selecting Request Music could offer:

Request Missing Albums

Request Singles & EPs

Request Missing Releases

Request Discography

An individual missing release could simply show:

Request

Again, the flow would be:

Official Emby client
→ Emby server
→ Request-provider plugin
→ Dropped Needles

Credentials stay on the server.

MusicBrainz makes the request side much more powerful

Because my music classification already uses MusicBrainz identity, requests can be much more precise than just sending an artist/title string.

For example:

Having the recording One Step Closer as part of Hybrid Theory does not mean I necessarily own the actual One Step Closer single release.

Those are different things.

If the single is missing, it should still be requestable.

When acquired, it should appear under:

Singles & EPs

with its own release identity and artwork.

The plugin could compare the artist’s MusicBrainz discography against the releases already present in Emby and determine what is actually missing.

A discography request therefore wouldn’t need to blindly download everything.

It could say:

Present: 27

Missing: 12

Already Requested: 2

Downloading: 1

Eligible to Request: 9

and submit only the genuinely missing releases.

This could be generic rather than tied to my setup

That’s probably the biggest reason I’m asking for plugin support rather than asking the Emby team to implement my exact environment.

I don’t think Emby should have to maintain:

Seerr support

and

Dropped Needles support

and whatever request system comes next.

Instead, Emby could provide the client/server extension framework.

Then plugins provide the integrations.

For example:

Emby provides

Native plugin UI components

Native Request actions

Native Discover sections

Native plugin-backed media rows

Native status badges

Native search-provider integration

Native artist-page extension points

Native release-type presentation

A client/server request-provider API

Plugins provide

Seerr

Dropped Needles

Other request systems

Other discovery providers

Future integrations

That seems much more scalable.

Security could stay under Emby’s control

I’d also prefer a structured extension framework over arbitrary client-side injection for security reasons.

Plugins shouldn’t necessarily be able to execute whatever UI code they want on every TV and phone.

Instead, Emby could define the components a plugin is allowed to register.

The plugin supplies:

data + actions + permissions

and the official client supplies:

rendering + navigation + platform behavior

That means D-pad navigation remains correct on Android TV, touch behavior remains correct on phones, and everything still looks like Emby.

External service credentials would stay on the server.

The end result I’d love to have

Ultimately I’d like to tell everyone using my server:

Just open Emby.

If the movie already exists:

Play

If it doesn’t:

Request

If they want to browse:

Discover

If they want to see something they previously requested:

My Requests

If they’re browsing music:

Artist → Albums / Singles & EPs / Live / Compilations

If an album is missing:

Request Album

If they want the missing discography:

Request Missing Releases

Everything happens through Emby.

The backend services can continue doing what they’re good at, but users don’t have to know or care whether Seerr, Dropped Needles or something else is handling the request behind the scenes.

I’m happy to share what I’ve already built

I realize this is a larger feature request than simply asking for another button.

I wanted to explain the existing implementation because I’ve already proven several pieces of the concept in my own environment.

I currently have working/prototype implementations involving:

• Per-user Seerr My Requests Home Screen rows
• HomeScreenCompanion integration
• Generated request collections
• Native Emby rendering of those Home Sections
• MusicBrainz release classification
• Albums vs Singles & EPs separation
• Live release classification
• Compilation classification
• Other/unknown release handling
• Release-specific artwork handling
• A working music artist-page reference implementation
• TV/D-pad layout testing
• Server-side request/acquisition integration work

I’d be happy to provide screenshots, API examples, classification data, test results, architecture details or portions of the prototype if any of it would be useful to the Emby team.

I’m not expecting Emby to adopt my implementation exactly.

The part I think would have the biggest long-term value is giving server plugins a supported way to expose structured native UI elements and actions across the official Emby clients.

That would allow integrations like mine to stop relying on creative Home Section/collection techniques or Web-only modifications and instead become proper native Emby experiences.

Thanks for taking the time to read this. I’d be very interested to hear whether anything along these lines is already planned, particularly around client-side plugin extension points or a generic request/discovery provider API.

Thank you
Samus512