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

[ebr 16863]

Hi.  We cannot build direct integrations into content-acquisition systems.

[Samus512 2]

Thanks for the clarification. I completely understand if Emby cannot build or maintain direct integrations with content-acquisition systems.

I think I may not have explained the main part of my request clearly enough, though.

I’m not asking Emby to build or maintain the Seerr or music-request integrations. I’ve already built the functionality myself.

What I’m really asking for is a supported way for third-party server plugins to expose native UI elements and actions to the official Emby clients.

The reason I’m asking is that I already have both of the major concepts from my original post working in Emby Web.

The limitation I’ve reached isn’t the backend or the integration logic.

The limitation is getting the same functionality into the official Android TV, Android and iOS Emby apps.

I already have the music separation working in Emby Web

For music, I’ve already built the classification and Web UI implementation.

Instead of putting every release under one Albums section, my modified Emby Web artist page can separate releases into:

Albums

Singles & EPs

Live

Compilations

Other Releases

Empty sections are automatically hidden.

So an artist with albums and singles might have:

Albums

Hybrid Theory
Meteora
Minutes to Midnight
A Thousand Suns
Living Things
From Zero

and then separately:

Singles & EPs

One Step Closer
Papercut
Faint
Numb
The Emptiness Machine
etc.

If that artist has live releases, a Live row appears.

If there aren’t any live releases, the row doesn’t appear.

The classification itself is already working.

I’m using MusicBrainz release/release-group identity and release types rather than trying to guess based on the number of tracks, folder names, or other heuristics.

That means the system understands the difference between an album, single, EP, live release, compilation, etc.

I’ve already built the Web-side artist-page presentation as well.

So for Emby Web, I can take that classified data and add the additional rows to the artist page using Emby’s existing visual style.

The problem is that I can’t do the same thing in the official native clients.

I can modify the Web client on my own server because I control those files.

I obviously can’t modify the Android TV, Android or iOS Emby applications distributed by Emby.

That’s the extension point I’m looking for.

The request functionality is in a similar position

I’ve also already built the request functionality on my own system.

For example, I have request functionality integrated into my modified Emby Web interface rather than requiring users to leave Emby and open another application.

The Web UI can expose a Request action using an Emby-style control, and my server-side integration handles what happens after the user selects it.

Likewise, I’ve built the My Requests Home Screen concept.

That currently works through a custom version of HomeScreenCompanion/Home Screen Sections Creator together with my request integration.

The basic flow is:

External request service

↓

My server-side integration

↓

Per-user Emby request data/collections

↓

HomeScreenCompanion

↓

Emby Home Section

↓

Official Emby client

That works because Home Sections and collections are already concepts that the Emby server is allowed to expose to the clients.

The official client receives something it already understands, so Emby itself renders the row natively.

That’s actually what led me to this request.

It demonstrated that I don’t need arbitrary control over the client.

I just need a supported mechanism for a plugin to provide structured information to it.

I’m already doing the development work

That’s the main point I wanted to clarify.

I’m not asking the Emby team to build all of this for me.

I’ve already done quite a bit of it.

On my own server I currently have working or prototype implementations for:

• Per-user My Requests Home Screen rows
• Server-side request integration
• Emby Web Request actions
• HomeScreenCompanion integration
• Generated request collections
• Native Emby rendering of those Home Sections
• MusicBrainz release classification
• Albums vs Singles & EPs separation
• Live release separation
• Compilation separation
• Other/unknown release handling
• Release-specific artwork
• Dynamic artist-page rows
• Automatic hiding of empty release sections
• A modified Emby Web artist-page implementation
• TV/D-pad layout testing
• Server-side music request/acquisition logic

I’m completely willing to continue developing and maintaining those pieces myself.

What I can’t build myself is the missing extension point inside Emby’s closed native applications.

What I would need from Emby

Ideally, a server plugin could register a limited set of structured UI elements.

For example:

DetailPageAction

ContextMenuAction

MediaRow

ArtistPageSection

HomeSection

and possibly eventually:

SearchProvider

DiscoveryProvider

The plugin wouldn’t send HTML, JavaScript, CSS, Android layouts, Swift UI code, or anything platform-specific.

It would just provide structured data.

For example, conceptually:

ArtistPageSection

Title: Singles & EPs
Type: MediaRow
Items: [Emby item IDs]

or:

Title: Live
Type: MediaRow
Items: [Emby item IDs]

The Android TV client could render that using the same component it already uses for media rows.

The Android client could render it using its native component.

The iOS client could render it using its native component.

The Web client could do the same.

The plugin doesn’t control how it looks.

Emby controls the presentation.

That would let my existing music classifier provide the same:

Albums

Singles & EPs

Live

Compilations

structure across all of the official clients instead of only my modified Web client.

Actions could work the same way

A plugin could register something conceptually like:

Action: Request
Item: Movie XYZ
Handler: Plugin action

The official client simply displays an Emby-native button or menu action.

When the user activates it, the server invokes the plugin.

What the plugin does after that is the plugin developer’s responsibility.

For my use case, it might communicate with a request system.

Another developer might use exactly the same API for:

Report Playback Problem

Refresh External Metadata

Add to External Watchlist

More Information

Run Plugin Action

or something completely unrelated to content acquisition.

That’s why I think this would be much more useful as a generic plugin API rather than an API specifically designed around Seerr.

Music requests could simply be one consumer of that API

For example, I already have the server-side pieces necessary to build something like:

Play · Shuffle · Request Music

on an artist page.

The plugin could then provide:

Request Missing Albums

Request Singles & EPs

Request Missing Releases

Request Discography

My MusicBrainz integration can determine which actual releases are present and which are missing.

For example, owning the recording One Step Closer as part of Hybrid Theory doesn’t necessarily mean the actual One Step Closer single release is present.

Those are different releases.

The plugin can already make those distinctions.

So it could determine:

Present: 27
Missing: 12
Already Requested: 2
Downloading: 1
Eligible to Request: 9

and act accordingly.

Again, none of that acquisition logic needs to be implemented by Emby.

The only thing I can’t provide myself is the native client button/action that lets the user invoke my plugin from Android TV, Android or iOS.

This would also solve the music presentation problem without involving acquisition at all

I think this is an important distinction.

Even if Emby cannot permit any acquisition-related plugin functionality, I would still like to request the native UI extension mechanism independently.

The:

Albums / Singles & EPs / Live / Compilations

feature has nothing inherently to do with acquisition.

I’ve already implemented the classification and Web presentation.

I simply need a way for my plugin to tell an official client:

Here are the releases that belong in Singles & EPs. Please render them as a normal Emby media row titled “Singles & EPs.”

That’s something I currently can’t accomplish in Android TV, Android or iOS even though the server already has all of the information required to do it.

I also don’t think plugins should inject arbitrary client code

I’m not asking for plugins to be able to send arbitrary JavaScript or UI code to every Emby client.

I actually think a structured API would be much better.

Emby could control exactly which components plugins are allowed to expose.

The plugin provides:

Data + actions + permissions

Emby provides:

Rendering + styling + navigation + platform behavior

That keeps the clients consistent and keeps Emby in control.

It also means D-pad navigation remains correct on Android TV, touch behavior remains correct on Android/iOS, and plugin developers don’t need to create separate interfaces for every Emby platform.

Even two extension points would get me most of the way there

If a complete plugin UI framework would be too large of a change, even starting with two relatively limited extension points would be extremely useful:

1. Plugin-defined actions on item/artist detail pages and context menus

and

2. Plugin-defined media rows/sections on item and artist detail pages

Those two things alone would allow me to take a large amount of functionality that I already have working in Emby Web and make it available consistently in the official apps.

I would still write and maintain:

• The MusicBrainz classifier
• The release grouping logic
• The request integration
• The external API communication
• The missing-release detection
• The permissions
• The status tracking
• The plugin backend

Emby would only need to provide the standardized bridge between a server plugin and the native client UI.

A very small first API could be enough

I’m also not necessarily asking for all of these extension points at once.

If exposing arbitrary new sections across every client would be a significant undertaking, even a very small first API could cover a large portion of what I’m trying to accomplish.

For example:

Plugin Action

A plugin registers an action for a supported Emby item type.

The server determines whether that action should be available for the current user and item.

The client renders it using its existing native action/button/menu component.

When selected, the client sends the item and registered action back to the server/plugin.

The plugin performs the operation and returns a success, error or updated status.

The client still controls the entire presentation.

Plugin Media Row

A plugin registers a row for a supported detail-page type.

The plugin/server supplies:

Title: Singles & EPs
Items: [existing Emby item IDs]

The client renders those items using the exact same native media-row component it already uses elsewhere.

If the plugin returns no items, the row simply isn’t displayed.

For my music implementation, the plugin might effectively tell the client:

Artist: Linkin Park
Section: Singles & EPs
Items: [existing Emby item IDs]

The client already knows how to render those Emby items.

I’m not asking the plugin to control what that row looks like.

I only need the ability to provide the grouping and ask Emby to render it.

That seems like it could provide a useful extension mechanism without exposing the internal UI implementation of any particular client.

Does anything like this already exist internally?

One other thing I’d be very interested to know is whether there is already an internal mechanism the official clients use for server-defined actions or sections that could potentially be exposed to plugins in a controlled way.

The reason I ask is that Home Sections already demonstrate part of this concept.

My current My Requests implementation works because I can translate that information into structures the Emby server and clients already understand.

The server exposes the Home Section, and the official clients render it using their own native components.

That’s very close conceptually to what I’m asking for elsewhere.

Instead of only:

Server → Home Section → Client renders native row

I’d like plugins to eventually be able to do something conceptually similar for:

Server/plugin → Artist Page Section → Client renders native row

or:

Server/plugin → Item Action → Client renders native action

If something similar already exists internally, even if it isn’t currently exposed to third-party plugins, I’d be very interested in whether making a limited version of it part of the plugin API would be feasible.

And if the answer is that native clients currently cannot accept any server/plugin-defined actions or detail-page sections, knowing that would also be useful because it would clarify exactly where the architectural limitation is.

So to clarify my original request

I’m not asking:

Can Emby build a Seerr integration for me?

I’m also not asking:

Can Emby build my music request system?

What I’m asking is:

Can third-party server plugins be given a supported way to expose structured native actions and media sections to the official Emby clients?

I’ve already demonstrated the functionality on the server and Web UI side.

What I’m missing is access to the app side.

If a supported extension API existed, I could move the functionality I’ve already built away from Web-specific modifications and into a proper plugin that works consistently across Emby Web, Android TV, Android and iOS.

That would also mean Emby wouldn’t have to maintain my integrations.

I’m more than happy to build and maintain them myself.

If content-acquisition functionality specifically cannot be supported even when implemented entirely by third-party plugins, I understand that may be a separate policy question.

But in that case, I’d still be very interested in whether the generic UI extension portion could be considered separately — especially plugin-defined artist-page media rows and plugin-defined detail/context actions.

The music release separation is a concrete example of why those extension points would be useful even without any acquisition functionality.

If it would help, I’m also happy to provide screenshots/video of the current Web implementation, API examples, MusicBrainz classification output, or code/prototype details showing exactly what I already have working.

Thanks again.

[yocker 1996]

@Samus512The devs have explained a couple of times in other threads that they won't allow users to make user accessible custom UIs for plugins as they want to distance them self from piracy as that could possibly get them thrown off stores like Google, Samsung and LG.

Look at Jellyfin as an exsample, it seems one of the reasons they can't get on the Samsung store is precisely piracy concerns from Samsung.

The closest you will get is the Seerr apps installed next to Emby.

Edited 1 hour ago by yocker

[Luke 43219]

I'm sure there are still some generalized things we can do, meaning the kind of things that would benefit all plugins.

[yocker 1996]

54 minutes ago, Luke said:

I'm sure there are still some generalized things we can do, meaning the kind of things that would benefit all plugins.

It would be awesome if plugins could have some sort of UI in the apps for users to play with.
Been wanting a report system in Emby for a good while now so users can report things like a broken video or subtitles missing.

[Samus512 2]

That generalized approach is really the main thing I’m hoping for.

I completely understand the concern about allowing plugins to provide arbitrary custom UI inside the official apps, especially if Emby needs to maintain control over what can be exposed through clients distributed through the various app stores.

I don’t think plugins necessarily need the ability to create their own UI, though.

What I’d love to see is a small set of Emby-controlled extension points that any plugin could use, where the official client still owns and renders 100% of the interface.

The report-system example @yocker mentioned is actually a perfect example.

A generic plugin action could potentially support:

Report Problem

Missing Subtitles

Incorrect Metadata

Refresh Metadata

Add to External Watchlist

Request

or any number of other plugin functions without the plugin actually injecting a custom interface into the client.

The plugin could essentially tell Emby:

I have an action available for this item called “Report Problem.”

Emby decides where/how that action is displayed using its normal UI components.

When the user selects it, Emby passes the action back to the server plugin.

That keeps the UI entirely under Emby’s control.

The same concept could potentially apply to plugin-provided media rows.

That part is particularly useful for something I already have working in my modified Emby Web client that has nothing to do with content acquisition.

I currently classify music releases using MusicBrainz and separate an artist page into:

Albums

Singles & EPs

Live

Compilations

Other Releases

instead of putting everything together under Albums.

The classification and presentation are already working on my server/Web client.

What I’m missing is a way for the server/plugin to tell the native apps something as simple as:

Title: Singles & EPs
Type: Media Row
Items: [existing Emby item IDs]

The Android TV/iOS/Android client could then render that with the exact same media-row component it already uses everywhere else.

The plugin wouldn’t provide HTML, JavaScript, Android layouts, Swift UI, CSS, or any other custom UI.

It would just provide the title and existing Emby items.

Emby would retain complete control over how it looks and behaves.

So I think even two generalized extension points could open up a lot of possibilities:

1. Plugin Actions

Allow a plugin to register an action for certain Emby item types/users, with Emby rendering the action using its own native UI and sending the interaction back to the plugin.

2. Plugin Media Sections

Allow a plugin to provide a title and list of existing Emby item IDs for an additional row on supported detail pages, with Emby rendering the row using its normal native components.

Neither one would require giving plugins arbitrary access to the client UI.

And both could benefit plugins completely unrelated to acquisition.

A reporting plugin is a great example for actions.

My Albums / Singles & EPs / Live separation is a good example for media sections.

Other developers could probably come up with quite a few uses neither of us has thought of yet.

That’s really the part of my original request I’d be most excited to see explored.

If something like a generic Plugin Action were the easiest place to start, even just that would be a really useful extension point.

I’m also happy to share screenshots or details of my current Web implementation if seeing a working example of the music sections or actions would be useful.