All Activity

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

You can try and take a look at:

@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.

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.

Hi, we work very hard on Emby and we thank you for your support.

So I found Emby on the store. I also discovered that Jellyfin has been uninstalled from the firestick without my say so. So I'm pissed at Amazon. If I buy a device, I own it. Them going it and changing configurations without my okay is not acceptable. As for Emby, It requires a subscription to use it on the Vega device. which is a step down from what U have running on every other device in my home.

Hi, can you please try 3.5.64? thanks.

OK we'll take a look at these. Thanks.

OK we'll try to chase this down. Thanks.

What is your highest priority metadata fetcher?

Oh, that’s both interesting and surprising. Perhaps my 2 example movies were fluke?!

Auto skip must be enabled. There is no manual skip feature and no skip button. If everything is setup correctly you should have an edl file in the same directory as the recording.

Emby Server 4.9.5.0 Nvidia Shield Pro Emby Android Ver 3.5.64 1) Start watching "Friends" for like 2 mins. (1080P) 2) Pause via center button. (run a stopwatch) 3) At 5 mins, the screensaver kicks in and it stays paused. 4) Left it on Screensaver for 3 min. 5) Clicked the center and the paused video screen comes back up. 6) Press again and it continues playback as expected. So it like the last ver, it is working for me.

Can they pull up the trakt or listenbrainz config screen?

Hi there, please attach the Emby server log from when the problem occurred: How to Report a Problem Thanks!

OK we are looking into it. Thanks.

Given all of the failures you had, it’s hard to say. We might be able to determine that with a brand new download.

HI there, can you please provide a specific example? How to Report a Problem Thanks !

Symptom: Downloads never start in Emby for Windows (v2.317.2.0, Windows 10). Items stay on "Ready to transfer", while the Android app downloads fine. Problem: The Windows computer name contained non-ASCII characters. Emby sends the device name in HTTP headers, and the sync fails with Request headers must contain only ASCII characters. Fix: Rename your PC (Settings → System → About → Rename this PC). Use only ASCII characters (A-Z, a-z, 0-9, hyphen). Letters with diacritics such as é, ü, ñ, ø, å, ß, č, or symbols/emoji will break downloads. Restart Windows. Sign out and back in to Emby. Clear the download queue and try again. Suggestion for the Emby team: Could you add support for non-ASCII characters in PC names, or show a clear error message when the name is not supported? It took me a while to find the cause. Logs:

We don’t get IMDb data directly due to cost. the rating you have on your server is not guaranteed to come from IMDb. We’re just labeling it as IMDb in the ui. but it’s really the rating that comes from your highest priority metadata fetcher in library settings.

Welp. Big power outage that took my server and client down today, but this works again after it came up. Maybe server needed a full restart.

Absolutely love this plugin. Really looking forward to the newer quality notification

These both work fantastic. Sorry I didn't want to post across both threads if that is OK. I initially misunderstood the BespokeDB - for some reason I thought it was similiar to this one, but then I realised it was a metadata & image source. Anyway, so far absolutely no issues with either. My Criterion Collection is about 600 movies and it seems to have not any issues with it. The A24 worked a treat as well and was able to use the studio tags perfectly. If I run into any issues with any of these I will update in the correct threads. But so far absolutely loving them both.

PageInfo = new PluginPageInfo { Name = "ManageComingSoonUser", DisplayName = "Manage Coming Soon", EnableInMainMenu = false, EnableInUserMenu = true, My plugin provides user functionality via "enableinusermenu" / PluginUI ecosystem, recently users are presented with an an 'access denied message' "user X does not have access to ManageServer feature" when initially accessing the page. Has something changed recently do i need to accomodate an updated way of working? It still working for admins. Thanks

Its not like the providers can't throttle or restrict/ration by IP. I meant if Emby were to programatically make it so that all our libraries were updating every single day auto"magically" without having to do anything. Where they (Emby) made the choice to hammer the provider, not the user (you). That would be seen as abusive. Not that you yourself a single person refresh your entire library is just a drop of water in an ocean of bandwidth. I meant this is why Emby isn't doing it. But once a month refresh them seems certainly doable.