All Activity

Yes, but it not being a functional example, it really didnt show me how to do anything

Hi, I can't install the Emby app on my new LG TV. The app is listed in the TV's app store, but installation fails with this message in Hebrew: "The application was not installed. Try again." TV details from the attached photo: - Model: 75QNED70B6T - Model code: 75QNED70B6T.AMFFLJD - Device name: [LG] webOS TV QNED70B6T - webOS TV version: webOS26 / 11.2.0-2909 - Total power-on time shown: 9 hours Emby app details shown in the store: - Version: 1.0.51 - Last updated: 26 August 2026 - Publisher: Emby - Publisher contact: apps@emby.media I've attached photos of the TV information screen and the app page with the installation error. The relevant Hebrew text is translated above. Is this TV/webOS version supported, and how can I get the app installed? Thanks.

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

Hi, how about the Console tab of the debug console?

OK, this is a good sign. One thing you could try is going to user permissions for your admin user, go to the access tab and just click Save.

Hi. Have you seen this? https://dev.emby.media/home/sdk/plugins/index.html

Since most of the examples out there are non-PluginUi based, the plugin I have been working on is non-PluginUi. In fact the only examples are the doc examples, which not being real world plugins are hard to use for a guide. Is there any documentation for migrating from the JS/HTML views to the PluginUI?

New version, slightly rearranged positioning. Buttons on the right just appear on hover. Emby.SpotlightWebMod.dll

26.0.31 Support automatic subtitles on skip back (requires Emby Server 4.11.0.5+)

Emby Web App Update: Version 26.0.31 The Emby Web app has been updated to version 26.0.31 Go and try out: https://app.emby.media/ Changes 26.0.31 Support automatic subtitles on skip back (requires Emby Server 4.11.0.5+)

Hi, if you disabled the VPN then you need to use a different remote address now, right? Are you sure you're trying to connect with the correct address?

EmbyVision Credits 1.0.0.4 What's New EmbyVision Credits 1.0.0.4 fixes the Library Auto-Scan and Scheduled Task settings so they now save correctly and control their intended behavior. Fixed Library Auto-Scan — The setting now saves correctly and properly controls automatic library scanning. Scheduled Task — The setting now saves correctly and properly controls the scheduled task behavior. Updated Plugin Store Image — Updated and centered the EmbyVision Credits plugin image for a cleaner, more professional appearance. This release focuses on making the plugin settings behave correctly and ensuring the plugin store presentation is polished and consistent. EmbyVision Credits 1.0.0.4 Better detection • Smoother experience https://github.com/encryptedcity/EmbyVision-Credits/releases/tag/v1.0.0.4

Hi, this will be in 4.11.0.5.

@Yambmare you sure your emby server is up and running?

Nevertheless ^^

Here is the testing thread where you can report issues: Thanks.

As soon as the first 4.10 release goes out, 4.11 starts moving forward with new development. We can't just merge all of that to stable as you'll get all of the instability that comes with that. We will look into whether there is a discrepancy with the Sqlite versions, and if there is, it will be corrected in the next 4.10 maintenance release. Thanks.

It seems like there are no log entries for the attempted play. The play button itself is acting like it is calling nothing at all on the backend. I can see where I reauthenticated to the server, but the only related line that seems related to playback after that is:

I call my custom first, and then the provider search second. In the log I see the Http request for mine 2026-10-02 11:13:48.261 Info HttpClient: GET https://api.themoviedb.org/3/collection/115838%3Flanguage=en-US?api_key=‌<api_key> 2026-10-02 11:13:48.387 Info HttpClient: Http response 200 from https://api.themoviedb.org/3/collection/115838%3Flanguage=en-US?api_key=‌<api_key>after 126ms but I see nothing for the provider, I do have debug logging on

@GrimReaper @Luke public async Task<TmdbCollection?> GetRemoteCollectionMembersAsyncViaProviders( string tmdbId, CancellationToken? cancellationToken = null, string language = "en-US" ) { if( string.IsNullOrEmpty( tmdbId ) ) return null; if( !CheckIsValid( false ) ) return null; var languageCode = string.IsNullOrEmpty( language ) ? "en" : language.Split( '-' )[ 0 ]; var countryCode = ( !string.IsNullOrEmpty( language ) && language.Split( '-' ).Length > 1 ) ? language.Split( '-' )[ 1 ] : "US"; var boxSetLookupInfo = new BoxSetInfo { MetadataLanguage = languageCode, MetadataCountryCode = countryCode }; boxSetLookupInfo.ProviderIds[ MetadataProviders.Tmdb.ToString() ] = tmdbId; var searchQuery = new RemoteSearchQuery<BoxSetInfo> { SearchInfo = boxSetLookupInfo, ItemId = 0 // Provide an existing Emby item ID if updating a specific item }; var cancelToken = cancellationToken ?? CancellationToken.None; try { IEnumerable<RemoteSearchResult> results = await _embyInterfaces!._providerManager!.GetRemoteSearchResults<BoxSet, BoxSetInfo>( searchQuery, null, // referenceItem: Pass a BaseItem instance if contextual lookup is required cancelToken ).ConfigureAwait( false ); foreach( var result in results ) { foreach( var providerId in result.ProviderIds ) { _embyInterfaces!._logger!.Info( " -> External Provider: {0}, ID: {1}", providerId.Key, providerId.Value ); } } } catch( Exception ex ) { _embyInterfaces!._logger!.Warn( "Failed to discover remote BoxSet results", ex ); } return null; } My custom search is the following: public async Task<TmdbCollection?> GetRemoteCollectionMembersAsyncViaCustom( string tmdbId, CancellationToken? cancellationToken = null, string language = "en-US" ) { if( string.IsNullOrEmpty( tmdbId ) ) return null; if( !CheckIsValid( false ) ) return null; //string url = $"https://themoviedb.org/{tmdbCollectionId}?api_key={kApiKeyV3}&language={language}"; var builder = new UriBuilder { Scheme = "https", Host = "api.themoviedb.org", Path = $"/3/collection/{tmdbId}?language={language}" }; var query = HttpUtility.ParseQueryString( builder.Query ); query[ "api_key" ] = kApiKeyV3; builder.Query = query.ToString(); var url = builder.Uri.ToString(); var options = new HttpRequestOptions { Url = url, CancellationToken = cancellationToken ?? CancellationToken.None, // Optional: Set cache timeout if you don't want to hit TMDB constantly CacheLength = System.TimeSpan.FromDays( 1 ), CacheMode = CacheMode.None }; try { using( var response = await _embyInterfaces!._httpClient!.GetResponse( options ).ConfigureAwait( false ) ) { var collections = _embyInterfaces!._jsonSerializer!.DeserializeFromStream<TmdbCollection>( response.Content ); return collections ?? null; } } catch { return null; } } Both are using the same tmdbid. The custom one works the provider one does not TIA

This makes sense, I think this is only affecting extremely large libraries as well. 4.11.0.4 beta is fine searching with every app. My question to Luke is why aren't you and your team just promoting full beta's to stable? instead you guys cherry pick parts of beta to create a build that's not even be tested and tag it "stable". curious as to why you guys do that when the majority test a beta release.

@GrimReaper To be clear, it works fine with this "URL" https://api.themoviedb.org/3/collection/<collectionTmdbId>?language=en-us&api_key=<KEY>, what fails is using the provider connection. Ill get you my code in a couple of hours.

Ill have to "undo" my direct call, but Ill get that tried out later today. Thanks for the response.

Yes user84 showed how to sort by number in his screenshots above.

agreed, but is there any way to use meta track numbers in folder view of a music library? sorry, that's a bit vague....I mainly mean to play in that order - although if you have other ideas, please let me know.