Leaderboard

The Admins have decided this is how they want to deal with first posts by new users. Nothing for you to concern yourself with. Thanks.

@samuelqwe Holy $#!7 Sam she workin' The code needs refactoring, it's dirty because the finger prints was split up from the encoding. I need to put it all together.

As I mention in a related post, I love the additional subfolders for Movie Extras (eg, Shorts, Scenes, Interviews, etc.)! It would be awesome to extend this functionality to TV Series as well. Specifically to add support for many/all of the same folders supported for Movie Extras, eg, extras specials shorts scenes featurettes behind the scenes deleted scenes interviews trailers As well as any additional folders that get added in the future (eg, hopefully Galleries). Support Placement of "Extras" Folders Within Each Season Folder, Plus A Naming Scheme to Link A Particular Extras Folder with a Specific Episode (eg, "\Season 1\E1 - Deleted Scenes\" for episode 1 deleted scenes): I want to clarify that it would be great if these various "extras" folder types could reside within each Season folder. So for example, within a Season 1 folder we could then have an "Extras" folder, a "Deleted Scenes" folder, a "Featurettes" folder, etc. And furthermore, that we could designate a particular folder to refer to a specific episode (eg, "\Season 1\E1 - Deleted Scenes\" for episode 1 deleted scenes). See more below, particularly why I think this would be so useful: https://emby.media/community/index.php?/topic/55915-emby-server-theater-additional-extrasspecial-folder-types-for-tv-series-similar-to-movies/&do=findComment&comment=587195 Thanks for your consideration! PS - If this is something you might like to see implemented, be sure to "Like" this top/first post (as well as any subsequent posts in this thread that highlight particular aspects of what you are interested in) -- "Liking" the top/first post helps the Devs to know how much interest there is in a given Feature Request.

Please read this post first. I was wondering if it would be possible to add something that would allow you to skip the intro to shows automatically while binge watching. When watching Netflix it does this for some shows, and im not sure if thats a feature of Netflix itself or a Chrome extension i use called "Flix Assist" but it would be a nice feature to have within Emby as well. and possibly even create a custom timed skip for specific shows

Feature request: Roadmap/Development transparency In scrolling through the current feature requests, and having put in a few myself, I'm curious: How many upvotes does a feature request need to get before you guys actually start working on it? Is there a certain number of votes per period of time, or how do you decide what actually gets worked on? I ask because I often see a feature request, and the response is generally something along the lines of: If the Emby Team already agrees with the user, the script goes: Emby team - "It's something we'd like to do in the future, thanks." But no timeline is given. A year goes by and it still hasn't been implemented, so the user asks again, and gets a response similar to: Emby team - "We are working as hard as possible to make everyone as happy as we possibly can. Thanks." User gets frustrated, asks for an ETA, response is like: Emby team - "Hi. We have never stated this feature was slated for any particular release. It is planned for the future but not under active development yet." 2.5 years have gone by for this feature request, with almost 30 upvotes, and active development isn't even on the horizon. If the Emby Team disagrees with the user request, the script goes something like: Emby team - "This is why we think the way we are doing things is right, thanks" Users - "Hey, I see what you are saying, but here are 9 reasons I disagree" Emby team - responds to 1 point of the 9 made to tell the user they are wrong, or that that 1 little point isn't relevant, ignores the other 8 points User - gets frustrated, keeps pushing Emby team - "This thread is here to gauge user interest, we will see how many upvotes it gets and may implement it in the future" Years go by, thread gets upvoted, feature never gets implemented. The highest upvoted feature request right now in the top 20 pages of this forum has 63 requests (not even counting how many similar threads may have been locked for being duplicates), and it's not even under active development at this time, despite being created by a developer and being over 2.5 years old. To get ahead of some of the responses I'm sure I'll get, let me just say: -I absolutely appreciate that Emby exists, and I appreciate and respect the time that goes into its creation and development. I know that developing a program takes time. -Yes, I am a premiere subscriber -No, I'm not just trying to complain about this. I am simply asking for realistic responses that actually have usable substance and transparency. Some actual follow through or a roadmap so that users know if their requests are even being considered for active development, rather than waiting for ages only to be told that the item they thought was getting worked on or had a chance at being worked on isn't anywhere on the horizon. -Yes, I do really love Emby, and I want to see it grow and get better, which is why I have chosen to give you guys my money, and why I recommend it to people. Unfortunately, that doesn't negate my frustration with this current process.

I too am not buying the performance implications, I've got 80TB of media and my data folder is only 530MB, I've got databases elsewhere a couple orders of magnitude in this size. 6.3M ./config 3.9G ./cache 5.2M ./plugins 1.0K ./.gnupg 393K ./root 31K ./.dotnet 18K ./sync 33G ./metadata 366K ./.nv 21K ./localization 529M ./data 4.0M ./fonts 40K ./.cache 273K ./transcoding-temp 14M ./logs 37G . You are not really going to gain anything performance wise out of having an external database with a pittance of a dataset like this. You will however, as I pointed out before.. gain the ability to configure high availability.. and potentially performance gains from distributing transcoding jobs across machines. These are not enterprise desires, we can spin up highly available setups with COTS hardware and recycled gear.. I understand this is not a priority, and there are other more important features I'd like to see first (like HEVC output on transcode) that potentially have a bigger impact on more users first.. but this is definitely a feature I'd like to see work its way out sooner than later. If the underlying design always had this in mind then the effort required to implement this should not be as technically hard as some of the other things on the todo list, low hanging fruit. I believe this would make a fine premium feature, none of your competition supports highly available configurations and those evaluating the options available will see that and it will stand out among the crowd, even if they dont have immediate plans to use it its one of those things I believe if you build it, they will come.. People will keep it in the back of their minds and once they have a highly impactful outage the chances are high they will consider building towards a HA goal.. its unlikely to be a feature widely used by the masses, but it is a feature that I believe will be attractive to those whom use Emby as the primary/only source of media. I can pretty much guarantee soon after you finally implement this feature you will have several users publish quick/simple/easy to follow guides for spinning up a HA k3s config on whatever hardware they can scrape together, from lil arm boards to big xeon recycler servers... The community will start writing charts, other automation and dramatically simplify this for everyone else, it will then take off as people see the advantages container orchestration brings and the vail of technical debt is lifted, it will only take a few days before less technical Emby admins can understand and deploy their own HA setup too with a few simple commands.. this is not a bespoke feature request that will languish such as the LDAP implementation, k8s is a major technology player just gaining more and more adoption, You are going to have a ton of HomeLab users jump on this so they can run personal production workloads at home simply for the exposure and experience they will use in their professional careers.. The Staff must see this, how much uptick have you seen in your docker container downloads since you released it.

You should be able to bring up the context menu and select mark watched for an item. EmbyCon has a custom context menu that should override the default context menu by default. This behaviour can be changed in the addon settings.

A plugin that lets you search for a tmdb collection, shows you your entries for that collection, then lets you add them all to a new/existing Emby collection with a confirmation click might be interesting.

Oh, okay. Well, right now I register to have this great complement, since it will help me with my great film base. Thanks

Emby is going embedded metadata based for music. So folder structure becomes less relevant in 4.6.

As CBers said. This admin's decision's and it will stay, thanks.

@Abobader Why do you keep spamming the same post in almost every thread, regardless of whether or not it has any relevance?

So we should be looking forward to this nice new feature soon then?

EDIT: I just realized I had this backward, as I just noticed this thread started waaaay back in March 2019 (!?!?!?). The most important point is I want to thank everyone, really everyone (point and counterpoint) that contributed to this thread. Strive to improve a good product to a better, if not best in its class, and the next day, start over with the exact same goal. Last but not least, more options for users is better than less options for users.That should take cares of about half the FR that gets a "mmm, not sure this would please everyone here" My point is, it doesn't have to please everyone, just give us an option to choose from, we're smart enough to find out what works best for our particular needs.

And that's the BOTTOM LINE! If Emby provides a login for the new API then each person get's to make up their own mind and subscribe or not.

Devil's advocate here is that early Google wrote their own indexer to harvest the data they needed to deliver a more useful service than the hand curated web directories that were more popular initially. Their index was essential to their competitive advantage and it wasn't crowd sourced. Of course, when Google decided it wanted/needed to make money, they just bought an invasive ad tracking platform and set out to destroy the open web, so it's all relative.

Yep, thank you !

SUBRIP subs have to be extracted first. For a 4K movie, this can take several minutes.

Currently I'm reviewing the "split" TV Show issue. Syncing leads in my case to an duplicate TV-Show record. One is empty, other one includes all seasons. This looks quite good so far, just remove the empty recordset. ...but users reported differently. I need exact specifications how you setup your Emby libraries and folder structure.

The plugin currently doesn’t actually add any skipping functionality, that would need to be added by the Emby team. The plugin simply serves as a proof of concept to test out if detecting the intros automatically is viable (you can see the detected intros on the plugin page). If we can prove that it works well, then perhaps we can convince the Emby team to implement the functionality.

Well I've got 78 John Wayne movies so I guess you could say I've been know to watch him.

On one hand: Exactly this. On the other hand: Also absolutely true. So, in my case I will just pay the buck per month and that's it. Easily solved and worth to invest more time...

Thank you GrimReaper, I had his account linked to the same EmbyConnect name...I unlinked it and it is now working as it should.

What you described is how the system is supposed to work (and how it does work for majority of users, I guess), Watched status is tracked for each User independently. There's obviously some synchronization going on somewhere. Did you maybr associate same EmbyConnect name on both Users? Do you have some sync plugin, like Trakt?

Hello @quickmicand thanks so much for taking on the endeavor of maintaining this amazing addon for KODI. I have a question for you because I don't know if something changed, but a behavior that used to exist before 5.x no longer seems to be valid: I added a duplicated TV Show Season 1 to my server and scanned it (). Kodi also synced and duplicated it (of course). After noticing this, I removed the duplicated TV Show Season 1 from the server like I used to do before, and on the next .db sync on Kodi, the addon usually removed it too. It didn't happen this time. Its present on my Kodi, altough without art, plot etc. Even worse: I added season 3 (on the correct folder in the server this time ), and when Kodi synced it, it's showing season 3 as an indepedent show with Season 3 being a single season. So now I have 2 entires on my KODI. I'm now repairing the TV Show library using the addon function "repair database", but wanted to leave this feedback here This didn't happen before. Something you did changed this on purpose or...? Removing a library to repair it became so slow as well. 15min and I'm still at 16% removing process. I have 1500 shows. Something is making this drag for no reason. PS: Regarding libraries and removing stuff, if we "reset the database" now, we no longer get presented with the pop-up option of "remove cached artwork? yes/no". It simply removes everything together everytime now. Which makes creating a new database, over 2h30 long for me (lots of movies and shows). Could you consider implementing it back again? Its a time saver for people that don't need to remove artwork when they reset the .db Cheers and thanks for your time! Looking forward to debug stuff for you

Yes please, thanks. But remember as ebr said, subtitle selections are remembered, so please try it on a brand new video.

@chef, something like this? \Install\ffmpeg\ffmpeg-4.3.1-2021-01-01-full_build\bin\ffmpeg.exe ^ -i "C:\Data\media\movie.mkv" ^ -ss 00:00:30 ^ -t 00:01:00 ^ -ac 1 ^ -acodec pcm_s16le ^ -ar 16000 ^ -c:v nul ^ -f chromaprint ^ -fp_format raw ^ audio_chromaprint.bin This is what TeamB sent a while back in our message chain.

I've got the ffmpeg version and I'm trying to implement the chromaprint this weekend. @TeamB what was that chromaprint flag on ffmpeg? Or... Is it -chromaprint

I'll add a option, but this feature has low priority. I'll check this is an easy to implement.

Currently, I'm rewriting a major proportion of the code. I hope it'll fix those issues, please try again as soon as 5.2.X is released. Actually, 5.1.17 already covered most of the design flaws of 4.X, but there are still some modules untouched which also needs redesign.

You must use the full URL as shown in the xTeVe app 'M3U URL' http://192.168.0.38:34300/m3u/xteve.m3u

Actually, using Language as Property Key and full language name (i.e. English, Japanese, Croatian...) as Value does not produce results. Likely because in MediaStreams table language codes are used: eng, jpn, hrv... DisplayTitle or DisplayLanguage should be used in that case.

You can have two rules, each with two Property Key/Value pairs to limit each language rule to the MediaStream type you want for that rule. For audio, it would look something like this: Subtitles, would look similar. You can check what MediaStreams you have for a particular movie by going to that movie's detail view and scrolling to the bottom.

Hi. You don't want to try and duplicate the series to track different watch status. That is what our User system is designed for. You just have one copy and then each of you have your own watch status. Users

Kevin Bacon

Apparently, restarting ALL my associated devices resulted in it now working. Thank you for your time. Now... how do I close this out?

The plugin is mostly in a proof of concept phase to show that it’s possible to detect intros automatically fairly well, so the data currently isn’t really used by anything. Eventually, I think the goal would be to have a Netflix-like “skip intro” button, but that’s not something a plugin can add and would require work by the Emby team to add it into clients. Perhaps chapters is doable in the meantime, but there are only a few clients that let you skip chapters during playback. Hopefully, as @chef improves the plugin, we can get to a point where it works well enough to get implemented natively by Emby.

here: IntroSkip.zip It should be mentioned that the new version of emby will use ffmpeg to detect intros. So things will change again. If you install this, please be aware that it is still in it's infancy. It saves data in the plugin configuration folder which is not ideal, and will most likely change in the future. If you aren't sure about how the inner workings of emby folder structures are laid out, I would probably skip trying this out.

Lets think outside the box. the present forum software and present format of FR is unable to fullfill the needs of many loyals users and supporters, how about a dedicated webpage, eg: emby.media/feature request. Instead of revamping the forum, just a new link to a fancy pants webpage that analyze keyword in new feature request and suggest "is this what you're looking for?" Then you can vote it up. No more Duplicate FR mgmt, 100x more accurate Likes matrix. You could even show what has already been done, what is being worked on, and inevitably, what can't be done (and explain why). Think of a prospective Emby subscriber looking at this and thinking, "wow, the orange co does not offer this, I think I'll go blue !" Having worked in various form of customer service 40 yrs, no one has to remind me how invaluable users suggestions/comments/complaints and criticism are. This is the stuff that the Emby of tomorrow will be made of. But if 99% of it is forgotten/lost by sundown, I call this standing still. Disclaimer: The following might sting a little, but like a flu or covid shot, its for your own good. Lets do a forum search on "we'd like to have this in the future" and all variations. Not just within the feature request thread, but in all sections of this forum; thousands of FR all scattered and "lost". Now out of this mass, how many have been seriously considered, put in to-do list, fullfilled . . . Where I presently work, if a customer's improvement suggestion is discovered to have not been forwarded upstairs, the employee is reminded of our policy. Incidentally, my employer is rated # 1 in customer satisfaction in the whole country in our field. Just my 2 cents.

I'm the same way. Spoiled by Netflix . CBS sure hyped the heck out of this series during the NFL playoffs.

To make any computer the most secure, just turn it off and unplug it. Thanks.

@PuffyToesToo thanks again for the new icons been off line for a couple of weeks so would have replied sooner

excellent !!!

Thanks for these as i can replace my old images which i dont like anymore how it looks so far

The addon does not support python 3 yet.

I think it could be as simple as a post every couple of weeks on what they're working on. I'm a software engineer and we all meet every week for 5 mins to tell eachother what we're each working on. I think that would be more than enough in this case.

This is revisionist history and a bit hypocritical. Emby up until very recently Emby was exposed both for the source code and the issue trackers as a whole. Then code started being closed source and both the code and issue trackers have essentially went private. Emby was the "no body" for a long time as it grew. It copied numerous features from Plex and other software like Kodi/XBMC. It's a mute point if features were directly copied or if the features were copied due to user request or just because they made sense. Point being, if a feature makes sense to have it will get added regardless if someone else has it or not, regardless of when it was added to another software or in development. The open source/issue tracking worked extremely well previously when no one was worried about competition and just worried about MB/Emby and being the best it could be without worry or regard for other software. Emby became very popular because of this. The whole point of open source code was to allow the code to be used by others to improve software AND to appeal to people who didn't want to "feel locked in" to closed source code or development. Many people switched from Plex to Emby because of this originally, even when it wasn't as feature rich. This isn't rocket science type code. An idea can usually pretty easily be duplicated by any other software if they want it. Users ask for the same features on different software so there is nothing honestly being protected by this. Who ads a feature first is more about priority than who can rip off a competitor first. The code base with the best devs will rule the day when all is said and done. When you stop and think about it. Emby would likely NEVER have been what it is today if it wasn't open in the beginning. Why fight what helped you to become successful in the first place? I actually feel the same way about JellyFin as you. LCD is a good way to express that type of user. IMHO Emby only has two software competitions. One is Kodi which is open source but a different market. It's great software but highly "directional" in doing one thing well. It basically is great for a standalone system but not to share media or to act as any type of client/server or to share media with family and friends. Plex is really the only other software of similar nature to Emby. Emby could literally give them the code every day along with any notes, tests, design and technical documents and it wouldn't matter. The software is written in different languages with different structures, APIs and frame works. The "idea" is really all that would matter as the code would be mostly useless. That's assuming they were even interested in the ideas or could program well enough to incorporate these ideas at the pace Emby has been adding them. 99% of what gets added to Emby has already been talked about in the forum or is just common sense so all a "competitor" would need to do is read the forums here or their own to see the same requests and ideas. Emby adds features to it's code at a rate AT LEAST 2 or 3 to 1 vs Plex. With Plex said features get implemented at best 85% to 90% but never 100%. They never finish features properly which is why they bleed so many users to Emby. Besides the technical reasons the other reason people used to switch was for the openness (being talked about here) and support of Emby. Plex is far more interested in being the next Netflix/Amazon/Apple Music then it is being an Emby. They have already started the slow death spiral in many, many ways.

This is one of the things I miss about the source being 100% open as you could previously just view works in progress. As far as Plex ripping off stuff from Emby, they have enough problems with their own code, redoing their own UIs in clients after botching them for 3 years. They've spent a large portion of the last two years coming out with features/services to then remove them (cloud features) and they spend a lot of their time these days working on features they want users to have (podcasts, news, music services, etc) that they can monetize while removing competing features like channels and plugins. Plex has just after 3 years, gotten their DVR to work 90%+ of the time correctly but only with a single EPG source and single "tuner type". They've got recently allowed someone other than the admin to set recordings! As a long time user/supporter of both systems I can tell you that most of the feature requests here are also over on the Plex forums. People on both platforms tend to want the same things (big surprise). Plex is growing in a different direction then Emby these days and going after different feature sets as a whole. Ironically, the bigger threat to Emby IMHO is JellyFin which is really Emby 3ish without the current Emby clients. They are more "PR" then deliverable and doubt this will change much in the near term. JellyFin is realistically 2 to 3 years behind current Emby at best case as they don't support the multiple platforms, multiple clients, NET framework, Guide data built in, the new features in clients like Video (BIF) snapshot support, etc... JellyFin will likely expose more people to "Emby Lite" and then Emby then detract from Emby long term assuming JellyFin sticks around long enough. To me this would be like MS worrying about a competitor with source code to Windows 7 32 bit being a competitor to their current lineup. Just not going to happen (open or closed source). More likely than not, people will would play with it to find they like it then when they discover the "real version" has a lot more features, clients and support then they pony up the $ to get the real version. The person likely to run JellyFin is also the same person who would run Plex without subscribing as well, so really not a person to worry about as they likely would never be a paid user. Agree, disagree?

I get where you are coming from, but the thing is, it's going to happen one way or another. You aren't making a unique product here, so you can't expect that other competitors won't have the same functions and features as you, as there is nothing truly novel about what we are doing here. Apple constantly gets beaten to the punch on features by other phone manufacturers, yet you don't see them going out of business, or exiting the phone market because someone implemented fingerprint ID before they did. Among all the things Apple is known for, they do 2 things extremely well: First, they have excellent customer service and support. Second, they are smart enough to realize that there is a natural flow to the way people expect things to work, and they are very good at shaping their products to follow that flow. So when people point out something that doesn't make sense (like this), which is simple to fix (this is literally changing the order of a few lines of code, or alternatively, adding a flag to show that there are extras), it's frustrating to get rebuffed (see my first post above re: If the Emby Team disagrees with the user request) As pir8radio pointed out earlier in this thread, if people really wanted to steal your features, they could look at your product, then look at the forums for what people are requesting, and implement the features themselves. What keeps them from doing this? Well, for major things, it's like you said earlier: If you know that, your competition knows that as well, and either: 1. They won't do it either, hence not beating you to the market, or 2. They will spend WAY too much time working on that one thing, thus falling behind YOU, and surprise surprise, you still win. The only thing keeping your users in the dark does is frustrate them, and cost you more time closing and merging redundant threads on here asking for the same thing. If we had some kind of roadmap to reference, we would at least know something is on the horizon, instead of going almost 2 years in a thread thinking it was on the horizon, before finding out it's not even under active developtment: For reference Let's be honest here, liking a post really does nothing when it comes to feature requests. Look through the first 5 pages of the feature request section and you'll see that the vast majority of posts that have over 10 "likes" are at or well over a year old, and have yet to be implemented. The highest upvoted feature request right now in the top 20 pages of this forum has 63 requests (not even counting how many similar threads may have been locked for being duplicates), and it's not even under active development at this time, despite being created by a developer (i.e. you) and being over 2.5 years old. If THAT feature request can't even get implemented, why would anyone bother to upvote anything, after seeing that go nowhere for 2.5 years? Despite this, your go-to response for users is still, "Liking the original post on these topics is the best thing to do." As far as simple requests vs. complex ones, well, I already addressed the complex. For the simple ones, it goes down exactly how I described in my first post that started this thread. If the Emby team agrees with you, you might have a chance at getting it implemented (granted, it will be at some unknown date in the future, and maybe not even then). If they disagree, you get the script. This is part of the "Transparency" I was talking about. As I explained earlier, this is more often than not because you guys give convoluted answers that leave people thinking things are getting worked on, when in fact they actually aren't. If I think something is being worked on, I'm not going to bug the developers about it and bump an old thread. Look at any one of those threads you are thinking about, and you will see the same pattern of a convoluted answer, no activity for a while while the users think it is getting worked on, then after a year somebody pops in and asks why it hasn't been implemented, cue another convoluted response, wash rinse repeat. In addition to that, keep in mind that you have FAAAAR more server admins on these forums than you do just regular emby users. So while you may be speaking with only one admin, that one person could be representing 20 different users that are on their server asking for the same thing. I'm sure you guys have hard numbers on emby users vs. installed server instances, so it can't be hard to understand that you are dealing directly with only a tiny fraction of the people who actually interface with your service. It's like voting in the general election: How many people are registered vs. how many actually turn up at the polls. Just because you don't have 1,000 people beating down your door to get a feature request implemented (i.e. "liking" the post, or adding their commentary), doesn't mean that there aren't still 1,000 people out there that want the feature. Just like you have a huge number of users with only a small number of admins, you have the same thing within the admins themselves: Out of all the admins, there are only a fraction of those that are going to get on these forums and put in feature requests to begin with. I'm not going to go back and reiterate, I think I've already responded to all the points in your first 2 paragraphs. I bolded that last line because it epitomizes everything I've been trying to explain throughout this post. I will end with this: We appreciate what you guys are doing, and we thank you for doing it. I wouldn't be a premiere subscriber if I didn't like the vast majority of Emby, and want to help it improve and grow. That being said, things would go much smoother for both your users and yourselves if we had more information, and some realistic responses that didn't come off as completely canned while providing zero definitive information. I for one appreciate the dialogue we are having here, and you taking the time to respond. Thank you for listening and continuing to have a constructive discussion with me, so that maybe things can get better for everyone

I've often wondered, why do you care if your competition knows what you are adding to emby? Who cares if they steal the idea and push it out faster than you, they could just pluck the good ideas from the feature request section here anyway right? You are not really losing customers? I mean I don't think emby users are going to rush away from emby to try another server due to a little new feature.