All Activity

Working on another video cost like $30 a video hopefully it looks ok when is done

Installed it today been on it all day you get hooked easy, suck at making videos but whatever Video.mp4

The ideal will be to have extras at: Show Level Season Level Episode Level

@Lukeadditionally: Imagine doing it on Shows with hundreds of official Specials like Doctor Who 2005 with 169. I have to scroll down to the bottom to find an Extra ? When maybe I only have 3 of them that no one has put in TheTVDB ? Or the opposite, I configure no Season Folders and I see 169 Specials + 3 Extras in a row. Has no sense at all.

How difficult is to understand that: A Season 0 Episode (Aka Special): Can be: a) Episodic Special b) An OVA c) A Movie d) Season Recap e) Webisodes and Shorts f) Uncategorized All the above is from TheTVDB Rules on Episode Categorization for Season 0 (Aka Special), that can be matched and retrieve it's metadata to feed emby: An Extra has it's own categories and are not included in 99.9% of the cases in any Metadata Source that Emby is using: a) shorts b) scenes c) featurettes d) behind the scenes e) deleted scenes f) interviews g) trailers h) Openings i) Endings j) etc So why mixing it ?????? Specially when you have it already solved in Movies:

Did someone else setup your server installation?

OK that is not true. Collections are still fully supported and a major part of Emby Server.

If you're showing the Season folders, then you can click Season 0. Isn't the specials line redundant at that point?

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.

So you have to choose or have the extras as properly be displayed as IT WAS until YOU REMOVED it or seeing Seasons in folders .... my media YOUR WAY ....

Yes, I am not sure where they're located.

yes That's what I read on discord. At this time, Is what I believe, is what was said.

Hi, this has been resolved in 4.10.1, so please update to that. Thanks.

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.

With the 4.10 server, if you enable your display option to show all episodes on the series screen, then you should be getting an extra row now: Additionally, individual episodes can have their own extras, and you'll see that on the episode screen.

Amazon sells you that device probably at a loss to them because it is actually a revenue generation mechanism for them. If it weren't it wouldn't be nearly so cheap. Still, I'm surprised an app actually disappeared - unless it became incompatible.

@JJKOMcan you please provide a new log example using the latest version of both the server and the app? Thanks !

It does still work automatically (if turned on) but the times are fairly tight.

Nevermind, just realized you can go into the app's display theme and manually select Halloween theme or Holidays theme. Good enough for me.

Is this the final word on this? On the EMBY fire stick/tv app there is still an option, but it doesn't seem to work. Is there any chance of bringing seasonal back?

Anyhow this is available in 4.11.0.5 beta. The testing thread where you can report issues is here:

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.