Jump to content

FR - Move play next episode overlay to plugin


dcook

Recommended Posts

dcook

Please remove play next episode overlay from Emby Server and have it as a plugin, this way users who want this feature can choose to have it.

Link to comment
Share on other sites

dcook

Because you have to disable it per user, and this kind of "feature" should be optional and installed via plugin, not in the core Emby Server code.

 

 

 

 

Why?

You can already disable it.

Link to comment
Share on other sites

pünktchen

I'm only using Emby for metadata management, so can the streaming/playback part be moved to a plugin?!

Link to comment
Share on other sites

Happy2Play

Who will maintain this plugin?  Plugins just make more work for someone to maintain.  Are you volunteering?

Link to comment
Share on other sites

Untoten

@@Luke @@ebr, you can see this guy pretty much wants emby gutted from his last few posts.  Perhaps for minimalist users like him you could offer more toggle options?  But, correct me if I am wrong, most if not all the functions he has mentioned do not consume resources unless actively used, correct?  So toggling or removing would do nothing other than aesthetic.

  • Like 1
Link to comment
Share on other sites

But, correct me if I am wrong, most if not all the functions he has mentioned do not consume resources unless actively used, correct?

 

Correct, this is how everything is designed, however like many users often have, he has a perception about it and it doesn't sound like that's going to change.

  • Like 2
Link to comment
Share on other sites

Untoten

Correct, this is how everything is designed, however like many users often have, he has a perception about it and it doesn't sound like that's going to change.

Understood, I was unsure just wanted to hear it from the man himself.  Are you able to close these as it would make no functional difference?

Link to comment
Share on other sites

dcook

Now you are just being stupid

 

I'm only using Emby for metadata management, so can the streaming/playback part be moved to a plugin?!

Link to comment
Share on other sites

dcook

Its no different then now with the current devs.

 

All I am saying is that anything that is not required for streaming of media from your library should not be in the core product and should be available as a plugin.  

 

I have listed some examples and as per Luke's request listed them individually here instead of all together.

 

 

 

Who will maintain this plugin?  Plugins just make more work for someone to maintain.  Are you volunteering?

Link to comment
Share on other sites

dcook

Its not a perception its a fact, if you take the code and run a diff on it from a previous version without user messaging for example and the version with sever messaging you will see the newer version is larger.  Its pretty simple fact and not perception

 

How can you say that user messaging is a requirement in order to stream media?  of all the examples I have given user messaging is probably the best that should have been developed as a plugin.

 

Look at how Wordpress works for example there is a core product and then you can add themes and plugins to customize it how you want, this is how 99% of products are made now, and the fact that Emby is stuck in the past and not evolving is the issue.

 

 

 

 

 

Correct, this is how everything is designed, however like many users often have, he has a perception about it and it doesn't sound like that's going to change.

Link to comment
Share on other sites

this is how 99% of products are made now, and the fact that Emby is stuck in the past and not evolving is the issue.

 

This is simply not true either.  The industry is moving towards simple, plug-and-play, install-and-run and "it just works" from the user perspective.  This is due to what I said before - most users do not want to mess with options or additional configuration.

  • Like 1
Link to comment
Share on other sites

dcook

When you install word press its just install and run and "it just works"  as you said,  then if you want to install additional plugins or themes you can just click on the install button for them, again its very simple and easy to click the install button.  

 

This is how modern apps work, trying to incorporate every possible wish, desire, idea into the core product especially those that have nothing to do with the purpose of streaming media is just stupid.

 

You have built plugin support, you have a plugin catalog, its easy to use and you just click install and it works, so why not use it?  Move stuff that is not needed for streaming media into the plugin catalog.

 

 

This is simply not true either.  The industry is moving towards simple, plug-and-play, install-and-run and "it just works" from the user perspective.  This is due to what I said before - most users do not want to mess with options or additional configuration.

Edited by dcook
Link to comment
Share on other sites

BAlGaInTl

When you install word press its just install and run and "it just works"  as you said,  then if you want to install additional plugins or themes you can just click on the install button for them, again its very simple and easy to click the install button.  

 

This is how modern apps work, trying to incorporate every possible wish, desire, idea into the core product especially those that have nothing to do with the purpose of streaming media is just stupid.

 

You have built plugin support, you have a plugin catalog, its easy to use and you just click install and it works, so why not use it?  Move stuff that is not needed for streaming media into the plugin catalog.

 

What a terrible example.

 

I use WordPress.  I could go on and on about features that aren't "core" to a Blog or CMS that WP includes by default.  There are tons of features that I don't use.  But I recognize that it's created for the 99%, not the 1%. 

 

Emby is almost an exact parallel to WordPress.  A fully featured base application with a plugin ecosystem.  To be fair, the WordPress plugin ecosystem is much more mature than Emby's, but it's a MUCH larger project.

  • Like 1
Link to comment
Share on other sites

Jdiesel

Its not a perception its a fact, if you take the code and run a diff on it from a previous version without user messaging for example and the version with sever messaging you will see the newer version is larger.  Its pretty simple fact and not perception

 

 

 

You seem to think that the number of lines of code directly affects the amount of hardware resources consumed. The amount of resources consumed is dictated by the type of work being done and if a feature is not being used it has little to no effect on resource usage.

 

If you are worried about "size", Chef's messaging plugin which could be argued is more featured packed then the built in support when compiled comes in at of size 29Kb. Is 29Kb of "size" or "larger" really a concern in 2017?

Link to comment
Share on other sites

dcook

Yes it is, when you keep adding more and more "features" into the product that has nothing to do with the purpose of Emby which is to stream media from your library

 

Its going to keep growing and growing, and require more and more cpu, memory

 

I don't think its unreasonable to ask that all non essential "features" be kept out of the Emby code and created as plugins, that is what they are designed for and we should be giving all users the choice if they want to have these "features" running on their server or not.

 

 

 

You seem to think that the number of lines of code directly affects the amount of hardware resources consumed. The amount of resources consumed is dictated by the type of work being done and if a feature is not being used it has little to no effect on resource usage.

 

If you are worried about "size", Chef's messaging plugin which could be argued is more featured packed then the built in support when compiled comes in at of size 29Kb. Is 29Kb of "size" or "larger" really a concern in 2017?

Link to comment
Share on other sites

BAlGaInTl

Yes it is, when you keep adding more and more "features" into the product that has nothing to do with the purpose of Emby which is to stream media from your library

 

Its going to keep growing and growing, and require more and more cpu, memory

That's not really how it works. There may be some truth to that, but it's been explained, and you don't seem willing to accept that the developers can code and use resources efficiently. The storage needed will grow, but that isn't really a critical resource in today's systems.

 

You can always stop updating the application if you think that any additional features are not needed.

 

I don't think its unreasonable to ask that all non essential "features" be kept out of the Emby code and created as plugins, that is what they are designed for and we should be giving all users the choice if they want to have these "features" running on their server or not.

What's unreasonable is the unilateral decision of what is "essential" without listening to the users/developers.

Link to comment
Share on other sites

dcook

So your saying messaging or camera upload is essential l for a media server to work?  

If that is what you are saying, you are delusional.  Those have absolutely nothing to do with the purpose of streaming media.

 

Examples of essentials would be:  transcoding, metadata

 

Examples of NON essentials:  messaging, camera uploads, auto organize, 

 

I am pretty sure if asked we could all come up with a list of what is essential and what should be optional

 

 

 

That's not really how it works. There may be some truth to that, but it's been explained, and you don't seem willing to accept that the developers can code and use resources efficiently. The storage needed will grow, but that isn't really a critical resource in today's systems.

You can always stop updating the application if you think that any additional features are not needed.


What's unreasonable is the unilateral decision of what is "essential" without listening to the users/developers.

Link to comment
Share on other sites

Jdiesel

I am pretty sure if asked we could all come up with a list of what is essential and what should be optional

 

And every list would be different. I get that you want to have options but your reasoning for removing options is flawed. Based on the feedback you've been getting you seem to be in the minority when it comes to stripping Emby server to its bare core features. 

Link to comment
Share on other sites

BAlGaInTl

So your saying messaging or camera upload is essential l for a media server to work?  

If that is what you are saying, you are delusional.  Those have absolutely nothing to do with the purpose of streaming media.

 

Examples of essentials would be:  transcoding, metadata

 

Examples of NON essentials:  messaging, camera uploads, auto organize, 

 

I am pretty sure if asked we could all come up with a list of what is essential and what should be optional

 

I'm not sure one could say I'm delusional.

 

What you are asking for is a major design shift that would degrade the user experience for the majority of users.  You are basing an ideal on your use case and limited understanding of just how it is that Emby actually works.  You're ignoring the market that Emby is in, and what it takes to be successful in that market.

 

Emby isn't just a "server" of video files.  It is more of a set of client/server applications.  They work together to provide a personal media experience.  I'm not sure why it is that you think media = video.  Photos are a very essential form of media to many people.  There are many people that strive to build everything around Emby to direct play.  So in that case, transcoding would be an additional feature they don't need.  Yet you list it as "essential."  What if I only used Emby as a tool for photo management?  To me, photo upload would be essential, and transcoding should be moved to a plugin.

  • Like 3
Link to comment
Share on other sites

dcook

I think you guys are missing the point and coming up with extreme examples such as someone who only uses Emby for photo management, sure such a person could exist, but we all know that the very large majority of Emby Server users are using it for Video (tv/movies) and Music

 

All I am saying is any so called feature that people request that doesn't directly relate to Embys function of being able to stream Video and Music should be developed as a plugin and the people who want it can install it.  Instead of being added into the actual Emby Server code.  That is all I am saying.

 

I have given examples of so called features that should be plugins

 

If they don't change how they are doing things, Emby will keep getting bigger, more bloated, slower to use and require more server resources such as CPU and Memory.

Link to comment
Share on other sites

FrostByte

This thread is bloated and has taken up too many of my precious resources just reading it :)

  • Like 3
Link to comment
Share on other sites

BAlGaInTl

I think you guys are missing the point and coming up with extreme examples such as someone who only uses Emby for photo management, sure such a person could exist, but we all know that the very large majority of Emby Server users are using it for Video (tv/movies) and Music

 

All I am saying is any so called feature that people request that doesn't directly relate to Embys function of being able to stream Video and Music should be developed as a plugin and the people who want it can install it.  Instead of being added into the actual Emby Server code.  That is all I am saying.

 

I have given examples of so called features that should be plugins

 

If they don't change how they are doing things, Emby will keep getting bigger, more bloated, slower to use and require more server resources such as CPU and Memory.

 

Perhaps "I" am missing the point then...

 

Sounds like you have great ideas for a competing product in a market that you clearly understand.  Something far more scalable than Emby.

 

Do you really think that the Emby devs are not acutely aware of every change they make and how it drives/slows adoption in highly competitive niche market? 

 

You've basically insinuated that they (devs) are ignorant of their own work.  You've implied that Emby is doomed to failure unless a change is made.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...