All Activity

It's already present in the media info section.

HI, I guess we could put that at the bottom in the about section. You can also see it in the metadata editor.

HI, it will use fanart, fanart1, fanart2, etc.

3.5.64 Attempt to fix gray background with HDR videos on certain devices Fixes related to device entering and returning from sleep Core UI Changes from 26.0.30 to 26.0.31 Support automatic subtitles on skip back (requires Emby Server 4.11.0.5+)

Emby for Android 3.5.64 Released Download Emby for Android Changes 3.5.64 Attempt to fix gray background with HDR videos on certain devices Fixes related to device entering and returning from sleep Support automatic subtitles on skip back (requires Emby Server 4.11.0.5+)

@LukeThis is such an easy addition, so why is it so hard to add? if the replaygain tag is there - respect it, if not - carry on as usual. I really wish i had access to the source - it's a 10 minute add. people have been waiting years. So, perhaps just add it. I am now using JELLYFIN for playing music because it does it perfectly - don't make us choose!

Pretty sure this will go on deaf ear. I would like to see added when in a movie/series or really anything you would show full path to the video. I have several NAS drives. Now I have to search for the thing. Click on the thing. Last click the ellipsis, then go to identify in order to see path info. Saving some steps on that would be great, but sense a lot of people asked for better actor info 10 years ago, and still it is missing. I don't really see this getting done anytime soon. Maybe next decade. Thanks

Hi, can you please try 3.5.64+ and let us know how that compares? Thanks !

What is the current default name for backdrops? Fanartx.ext or Fanart x.ext (space between name and numeric) I understand that it accepts both, but if missing what does Emby create. Everything I have found seems ambigious. Thanks in advance.

As you can see, Android displays the primary image as the Library icon, Roku displays the Backdrop. Android: Roku:

Hi, can you please provide a log from the android app? Thanks !

embyserver.txt Just tried to recreate right at the end, long pressed on Starship Troopers and pressed play from that menu and it did not load anything. LG TV is the device. Let me know if I can help with more info. Thanks!

Not sure what to make of @Lukethanking that comment just now...

The redundant right arrow button has been replaced with a redundant right arrow non-button? There's still no left arrow despite the same funcionality being available in both directions. I feel like the dots at the bottom adequately convey that you can scroll through. When shifting from the last item on the spotlight back to the first item, it cuts instead of playing the scrolling animation. Pressing left from the first spotlight item opens the left menu. I would prefer it instead scroll back to the last spotlight item. The left menu can be accessed by navigating up or down before pressing left. Disney+ works this way. I know there might be some arguments on that one, though—both behaviours can be frustrating depending on what you're trying to do, but going down and left is two clicks while going all the way through the spotlight is [number of items in the spotlight] clicks. Individual spotlight items remain visible for too long. In the ATV app, which has a setting for this, I have it at four seconds. That can sometimes be too short, especially if images don't load right away, but I definitely wouldn't want it longer than five seconds.

Hi, we can look at increasing the limit of the safeguard to prevent something silly from occuring. Thanks.

Hi @bzellingercan we please see an ffmpeg log example? By the way you can also accomplish this with the diagnostics plugin. It has an option to search and replace on the generated ffmpeg command line.

@sa2000

Hi, we will look at improving this. Thanks.

Hi, that's really odd. The app supports WebOS 1.0+, so it should install on your TV. In any event, we are preparing a new submission to send to LG for review. Sometimes what happens with brand new TV models is that they can't install the app until after the next time the app is updated.

New Emby server Beta release, v4.11.0.5.

So after two weeks testing i guess i figure it out. When pc launch , external hdd launch but when get to windows emby start but hdd power down (power saving) and sometimes i guess it corrupt data. After i turn off all possible power saving managament and i delay emby launch everything seems fine. Also i install app called KeepAliveHDD which write 1 kb txt file every five minutes and so far everything is fine. If i undarstand correctly some hdd have agressive power managament in firmwareand powerdown but when emby or anything else start crawling library it get corrupt,

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