Leaderboard

The first version will be released in the next few days. But I'll tell you right away that I don't know anything about programming skins - I've now rummaged through the individual files and changed something where I thought it would work. In den nächsten Tagen kommt die erste Version. Ich sag Euch aber gleich, von Skin programmieren hab ich an sich null Ahnung - ich hab mich jetzt durch die einzelnen Dateien durchgewühlt und da was geändert, wo ich der Meinung war, dass es passt.

Unless using some 3-rd party solution, the closest you can come to that in Emby is by TimeLord (premium) plugin, which overwrites Date added with Release date (and that change is irrevocable unless manually amended or full metadata refresh). As for covers, what naming convention you're using for your artwork? Edit: Looks like that's Radarr issue, removing all files/artwork in the folder on upgrade and Emby just downloading it again. Related topic:

Please add a setting for subtitle opacity, as it looks so much better on HDR TVs. Otherwise it's much too bright and hurt your eyes.

I like that Emby supports specials, it fetches the metadata, and it's *kiiiinda* cool that it shows them in the series timeline according to the "plays before [ep]" tags... But when these items are inserted into the series timeline, they seem to be played while playing through the series... this is not great. It especially sucks when some specials have "plays before S01E01", in this case, a bunch of junk appears as the first thing that plays when you start a new series. If you're in the main-menu, and you just press "PLAY" on a thing, it should automatically play S01E01, but instead, it starts playing a bunch of random special feature junk. Nobody wants to watch specials BEFORE they've seen the show... it's stuff you want to see only after you have seen and love the show. TL;DR: when pressing play, or moving to the "next" episode while binge-ing, always skip any material from the Specials. Please!

Hi. Perhaps for you but I can tell you that you are very far from a typical home server user. Attempting to setup and manage the SSO would be much more complex to most of our users I believe. Thus, as some sort of plug-in as opposed to core functionality is probably where this would end up.

I didn't wanted to sound like i'm denigrating the work done on Emby, I love the product and been using it for years. I prefer Emby for the features and stability. Plex's authentication system is what made me choose Emby in the first place. Thanks for taking the time to answer to your users ! The work to decouple the login from the rest of the application and integrate it in apps is understandably huge, but I still believe the benefits of offloading authentication (security, UX) to a standardized SSO system outweigh the initial complexities. By delegating the authentication process Emby can focus on media management and streaming. I tend to prefer OpenID over SAML (SAML is a bit older), but both are good standard used in a lots of corp applications and integrate in most Identity Providers (Azure, Okta, Keycloak, Authelia, etc.). Agreed that Device Code Flow is very good enough to setup a device. As you said the plugin can handle the creation of a device code that can then be given to the app, to login the user that was previously binded with the Identity Provider, like the LDAP plugin do. This might minimize the need to refactor the user system and the apps less to be "aware" of the protocol, as long as they can validate the code with the server.

@Luke, As per my access issue with the Android Server on Shield. Please accept this Feature Request for a WebView UI on the Android Server. Hopefully this will enable Direct (localhost) Web App access to the server on Shield - WITHOUT Internet Access. Making a truly Stand-Alone media player. This would be perfect for RV travelers who go where there is no Internet Access - and I am sure there are many... Thanks Jordy

Hi, no reason other than the feature just hasn't been built yet. But yes we will get there.

The beta is better with burning-in subtitles than the current release of the server. It is expected to become current in the next few weeks. If you want to try the beta, just remember that you can't simply go back to the release without a reinstall - so it might be best for you to set up an installation of the beta using the same files, or a sample (it can be on the same machine, but with the ports it uses changed) to try it out. Paul

I'm an idiot. I see it now.

This idea is to a degree more in alignment with the points I posted in the link above and would seem to be an acceptable trade off. My 2c.

So it's sufficient for you that it's working only when accessing Emby with a browser, but not with any of the apps? And that you have a different identity when signing in via SSO opposed to Emby login is acceptable for you? I sympathize a lot with the idea in general. In this case, it's not about de-priorization of security related matters. It's primarily about the fact that this cannot be implemented as a self-contained and rounded-up feature, as a quick and concise benefit for users. Let me explain by example what I mean by this: Assume there's a feature request for allowing users to change the size of subtitle text shown on the screen: (we already have that, just for the sake of having an example) When we go and implement that, we would: Add an option to a settings page Change player/subtitle frameworks to read the new setting and apply it accordingly Eventually, we ship that feature, users will be happy and we are done with it, put a checkmark behind and don't have to deal with it any further. The feature which is being requested here is of a totally different nature. Not only that we would need to implement this in all of the apps for once. There are often small nuances between different SSO providers and that means that any changes which are required to support a certain SSO provider would be made each time in all of the apps. And those changes and adjustments are also the core of the problem (I think I have sufficiently detailed those things in my earlier post): We would never be done with this feature - just the opposite. Once we would have an initial implementation, it would mark the beginning of a continuous amount of work that will be required for supporting it. We would be facing countless questions and issues about settings this up and why it doesn't work in each user's specific kind of setup and requests for supporting SSO provider X or Y. The inevitable outcome of implementing this would mean to put a huge load onto our shoulders for making just a small amount of users happy (and some perhaps even less happy than when we would have never tried to provide it). All in all, there's more to lose than to win in this case. It's not a coincidence that our forkers didn't implement it. The referenced plugin is of little value IMO, it's experimental (self-declared as 'alpha') and very limited.

Thank you Paul, The option I see for the folder structure are: 1. Other or unstructured. 2. Perfectly organised into artist\album folders, with track directly in the album folders. 3. Perfectly organised into album folders, with track directly in the album folders. So I'll try No. 1 and see how it goes.

Already did, also used LDAP for a couple of years with Emby, thanks for the advise ! MediaCenter is the last service I need to integrate to my OIDC. While I understand that this feature may not get prioritized as security is not always a priority for the typical user, it is a priority for me as I don't like Emby directly handling the auth part (I prefer emby to focus on what it does best) and not integrating properly with my other services. I've dropped LDAP support due to the OIDC one-way sync limitation that I had, as well as trying to move away from legacy protocols. Also this from your previous post, clear text creds : "With the LDAP plugin, Emby gets the user name and password of every user who logs on in clear text and the server attempts to log on with these credentials at the LDAP server. "

If anyone is interested - I'm currently making a 4K version of the skin.

Thanks Luke, that explains it. I looked at everything and couldn't find a way to change it. As I said, though, I'm very happy with the way it looks by default. I don't even generally mess with skins and themes, just thought I would take a look.

Yep, not sure if there is something I could do to fix it.

Yes same here. A library scan on Kodi 21 beta 1 crashes after finished, but scan was completed. I assume it's due to the xml bug in Kodi 21.

There is an option in Radarr to set release date, as file creation date, When importing movies. I believe that option is under media management settings in radarr. And yes, radarr is deleting files, when upgrading.

Thats also a problem that ive been having, although less significant. The reason many of my video has so many subtitles is because the original subtitle plugins such as opensubtitle has little support for Simplified Chinese language, so I'm using a plugin from github that uses Shooter (For better language support) as subtitle resourses. However this plugin was designed only for Windows/Linux Server, but I'm using an old Mac mini with Macos as my emby server. But I tried to installed it anyway, The plugin works, but every time I scan the media library or refresh metadata, it begins to download one subtitle file, hence after many years some video files are already attached with hundreds of subtitles. Every now and then, I'd manually delete some subtitles, but still not every file.

softworkz, Thanks for the extra info! By ‘much enhanced’ I was referring to the fact that ATSC1 as currently implemented tops out at 1080i/720p(8bit) and AC3 5.1, changing that would be a huge problems for many current TV/tuners (so that would effectively be the equivalent to a new standard (not unlike ATSC3)). But do note I’m not a huge fan of all that the ATSC3 spec is adding like requiring a license for AC4 and of coarse DRM (yes, it can easily be added to any digital stream but is useless if no one can decode it). As for targeted tracking/ads the cable providers already have and use this ability(mostly for regional ads currently). IPTV quality I think comes down the providers wanting to keep cost down by using less bandwidth. As it stands now US broadcasters will be allowed to turn off there ATSC1 channels as of June 2027(Cord Cutters) providing the have a ATSC3 channel to replace it. Anyway I was really just trying to help people understand the difference in what they are asking for (‘Nextgen TV’ or ‘TVnext’)

Hi, the Emby Roku app doesn't have themes. It's more of a challenge than other platforms, but still possible for future updates.

When I tried the Anime plugin my anime went all to pot. I use the default TVDB and it just works™. Here's Frieren, for example: Paul

it would be nice to have the Overview field if it can be added to the table view that would work as well

Actually it's not really "enhanced" in significant ways. It uses AC-4 audio which ties it to Dolby, it uses HEVC, but that's not something for which ATSC3 is needed for, and it uses a different container format, which makes it incompatible to everything else. It brings in back-channels via internet connection which allows them to display targeted ads and track users for what they are watching, when, how and how long. It's primarily a wet dream of the industry in order to fence their market and push their patents into it. Digital TV has always been driven by DVB and probably they didn't want to be the little brother or passenger anymore, just cooking their own little soup on top of it. Probably it's also an attempt to work around FCC regulations demanding a certain amount of free and non-DRM-protected content in broadcast TV. Technically, there wouldn't have been any need for this (when proceeding in parallel to DVB like usual) Interestingly, LG is no longer including ATSC 3 tuners in their TV models from 2024 onwards. North America, South Korea and Brazil (only testing/consideration), that's pretty much it. For using better video codecs, it doesn't require a new standard. Better radio transmission technologies could have been introduced with a small standard update which would have remained compatible (like DVT-T2 did). Content encryption has always existed for DVB standards. Actually, the first DVB broadcasts were paid services with encrypted content only, which hadn't changed for a while. Encryption exists and is in use for all variants (S/C/T) but there is a reasonable balance between free and encrypted channels. ISDB is a derivate of DVB and used in Japan and Brazil (DVB tuners can be used to receive ISDB with different firmware) Then there's DMB in China, about which I know nothing. All the rest of the world uses DVB (https://en.wikipedia.org/wiki/ATSC_standards#/media/File:Digital_terrestrial_television_standards.svg) It should be noted that these usually cannot compete with broadcast television in quality. A private beta is already behind us. Next-up is a larger-scale beta, involving a broader audience, so it won't be just a few hand-picked people like the previous one. Yet, I can't say when and how. Only thing I can say is that it hasn't been filed dead, and it's surely good to keep asking, even though it's probably the most requested major feature already.

Hi, that's strange. We'll test that out. Thanks.

For the last decade or so, I have used Plex as my primary media content provider. However, circumstances have caused me to rethink that decision, and I have started to lean into Emby as a total replacement to complete a lift and shift. One of the reasons behind that decision was the existence of the LDAP plugin in the environment to allow control from a centralized source. -- Thank you, @Luke I think there is a way to take on this kind of effort in a phased approach. I do not care if SAML is integrated into the numerous applications and environments that would need to be updated to make this function properly. All I would require to call it a reasonable success is the ability to incorporate Emby Connect into a SAML environment. LDAP is, in my opinion, essentially useless without being able to incorporate it into the pin authentication method. It's a tough sell to tell folks that you'll need to log in with that username and password (that happens to be 12 digits or more) on every TV system around the house. But my local LDAP can pipe into Azure AD (Or Entra nowadays) and then be SAML connected to Emby Connect. I now have a way to control access accounts that is friendly to end users and meets the need from a system administrator perspective. I know your average system user has this system, and this alone and self-contained passwords work fine. But this is a niche that no one provides for today and has what I believe is some value proposition behind it that a subset of your target audience would genuinely appreciate.

Requested on THIS thread in 2018, soon its 2024. So SIX years for this request that can't be that difficult to do compared to other stuff written

Overseer/Ombi would be better than direct Sonarr/Radarr integration as you could limit the number of requests and a user could track their own requests if you associate the request to a user in overseer/ombi, plus what if you run multi ARR for 4k/1080p etc Plus its only one api instead of 2.

Thanks, separate hdr options would be the best solution if possible, the other workaround is to add ability to change color of the subtitles in the subtitles menu while playback is active.

Correct. I love Emby and when I found out that iptv providers were going towards Extreme Codes and we were not having that feature supported in Emby had forced me to look at alternatives. If Emby could support XC, that would make Emby the goto app for everything. like you pointed out. IMPlayer is going in that direction, but they are still forcing users to have android based setups to support the app and from working with a friend last night, it seems the app does not retain the emby connection details after the app reboots. I would encourage the Emby devs to take a look at this as this could be what brings Emby to the next level. Users will still be able to have Emby play on almost all facets of devices and bridging the next Gen iptv services via XC would make Emby G.O.A.T. In my opinion, lol. (other may differ)

Be aware that almost no developer of closed-source software (Emby) is going to incorporate code that leverages GPL 2/3-licensed code. Any portion of their code that depends on such code would itself need to be opened up (in Emby's case, modifications to dependencies like ffmpeg are open/shared). Further, simply looking at such code itself is legally fraught, as it could be considered a derivative work. In OIDC's case, they provide a reference implementation for .NET (licensed under Apache 2.0, which is far more permissive). Similar implementation details for SAML are available from MS. I'd love to see improvements to security and authentication, but I would not recommend providing references to code that could embroil the developers of a product I depend on (Emby, or otherwise).