Elan,
INTERNET REQUIREMENT OF CLIENTS
Concerning consoles and 3rd party service requirements that are out of your control. Not really sure what you are getting at. xBox and PSx consoles can run apps that only work locally and not need to "phone home". They could just as easily pull information from a local Plex server then having to go online to pull from plex.tv. All credentials could be pulled from the local server. It may take a few more lines of code and a bit more architecture to cache the info on the server but it's in your control. So I'm not sure what you are getting at.
Also on a related note on these console with HOME login. Try the xBox One Netflix application. You do not need to switch users on the console to use a different user in netflix. Plex should handle this the EXACT SAME WAY. Same with all consoles and applications.
There may be a few devices such as TVs that may require always on Internet but they are probably the exception rather then the rule. In either case this should definately be noted on the application description (on the website).
But for things like the PSx, XBOXs and smartphone this is not the case and the plex app could work without internet.
XBOX DIMMING
Yea, I don't know about that. I guess we have a different oppion as to what "a tiny fraction" is. The forums here, Redit, AVS all had people with this issue. I'm sure a large portion of people either just stopped using it or didn't post in the forum about it. Or they dealt with it not knowing better. Doesn't mean that only a "tiny portion" were affected however.
But for those that did experience the issue, it was sometimes maddening. Any my point was that Plex Inc. didn't learn from that as they started putting the exact same feature into other clients without it being configurable which is crazy considering how easy a configuration section for this would be.
If you would quit adding new features without administrative functions it wouldn't be an issue. This is becoming a common theme with new stuff. No control over it. Of course said features will work for the majority (I hope) because you designed to meet the majorities need, BUT you also cut off a minority in doing so. If you make said new features controllable then they are usable by everyone, even if that means turning off the feature.
SWISS ARMY KNIFE
Yea I got it without the picture. But you do realize that is EXACTLY how people feel about Plex right? It's got a whole lot of tools and features but many of them don't feel like stand-alone tools or don't work fully. Some of the features are like the utensils on the knife, they can do some basic stuff but nothing heavy duty.
COMMENT TO SURFSWITCH about OUTGOING STREAMS
Without coming out and saying it specifically, you just said his idea will probably only affect a minority of users and it's not going to be that important.
This goes back to "half done" or "half assed" released mentioned before. You're giving us new tools and features without the ability to control them properly from the server. If proper tools were put in place to control new features then lots of this stuff wouldn't happen and you would have a stronger overall product.
You will see these kinds of requests popping up more and more as time goes on (already is). It's inevitable because as people actually start to use these features in the real world for anything more than 2 or 3 friends/streams you start to hit these "walls" and issues. Once people hit the "magic" demarkation line of pegging their CPU with transcodes it will be even that much clearer that there needs to be ways to manage this.
MikeG6.5: WHITELISTS
Not sure about this. Did you specifically ask the majority of users if inclusionary restrictions are fine? :) Since it's THE ONLY CHOICE people have had to find ways to make use of it. Many surely can get by with only whitelists. BUT when you read what the users had to do to get whitelists to work and when you understand how it could have been setup/designed it's way different. Instead of having to work around things to get whitelists to work the user could have tagged a couple of files and just setup a blacklist for them.
Had both of these WHITELIST and BLACKLIST functions been in the server then you would probably find that many more users would make use of the blacklists for many things. But since it's not an option you can't say they are "fine" with the current implementation. They have to be "fine" with it if they want to use it at present. Just because they found a work-around doesn't mean it's the ideal implementation.
There is also a serious downside to only using a whitelist. If I need to add a new tag or rating or similar to make sure these videos show up in the filters then if I add a hundred new files (any time new files are added) I have to also check the meta on each and every file to make sure it has the proper tags or it won't show up in the whitelist filter. That is a LOT MORE WORK then only having to ever touch a file I don't want to show up.
NOT REALLY UNDERSTANDING THE CUSTOMER (last response)
We totally understand wanting to ship a product and having to have a cutoff on items. However, if you go back and read some of the forums on some of the HOME/FILTERING options when people brought up these things you will see where there is no mention of version 1.1, 2.0 or anything like that. In some cases you will see the opposite and something to the affect of "we discussed it and it's not going to happen". I believe some of these comments came directly from you.
Probably contrary to internal planning and thought, you might find that users would probably prefer a release to have only 2 new items that are well thought out and have a solid implementation then 5 new features "half done". Done correctly you end up with a more solid code base that needs far less modifications and client changes down the road, less iterations overall and more solid feature set. Maybe I'm wrong but many here in the forums of late are expressing this same sentiment.
We don't like it when you create a new feature that changes or takes away a previous feature like DLNA. Unless the code is really convoluted I just don't get why this couldn't be tied to a new user account. I'm sure it would take some work but good things often do take work. What it sounds like to customers is that you "cut corners" to get a new feature out. If it's that bad/hard to implement than that might be another issue. If the core codebase isn't easy to work with and you keep piling more stuff on top you end up with spaghetti and tend to never get said functionality back because it's too hard. We've lost great features in the past because of things like this (2 steps forward, 1 step back)
LASTLY and HARDEST TO EXPRESS
I really don't like to pull one or two sentences out of a post such as this with many good responses (and they are good) by you, but I think this really is the "heart of the matter":
We’re not going to start pre-announcing features and publishing roadmaps, but we WILL BE BETTER about communicating in the forums.
The first part of that probably tells many of the bigger and more complex system operators everything they need to know. Roadmaps is a much bigger deal then you think. 10 to 15 of the bigger system operators from here talk we me offline almost daily as we help each other out from everything like being an offsite backup to each other to the "tips and trips" we use to work around plex features. We are all of the exact same thought that not knowing if certain server management features are going to be available in 2 months, 12 months, 24 months or never is A BIG DEAL.
We might be in the top 1% or even top 0.5% of unique users but we are also the same people here in the forums helping others out with our knowledge and expertise. To PLEX INC we may be a small minority of users with needs that get put at the bottom of the list (apparently) and won't factor in much when it comes to changes or new features.
HOWEVER for us 1%ers being able to control users more precisely is a BIG DEAL. Being able to limit the number of streams they can use, or the minimum bandwidth a client must support or the maximum bandwidth a user can support or the number of transcodes a person can use is the way to trade bandwidth for CPU use (transcoding). Being able to suspend and to set an allowed schedule of times the user can/can't use the system or specific features such as sync is big also.
Keep in mind this is ONLY ONE EXAMPLE and there are many like this. But by your very statement, WE will never know if these or similar features are in development, on the drawing board or if they will ever happen. By recent "track-records", what will most likely happen is a new release with even more features thrown in that we can't control from the server making the management that much harder if we want to take advantage of said features. We can't keep getting new features that don't support control of them. Only so many things can run at one time and the CPU resources are limited. Even on very small systems these types of things are needed. One rouge family member setting a library or whole tv series to sync can cripple a server. So these "management" functions aren't just needed by big systems.
Elan, now put yourself in our place. Would you not look for alternative software to run your system? If you had to base your business on a decision of what software platform to use and was looking at 2 or 3 different vendors what criteria do you use? If a couple of vendors meet most of your current needs but you have other needs and one shows you a roadmap and one doesn't and the one showing you a roadmap has features upcoming that you need, what do you do?
So what I'm getting at is that the Plex Inc. policies are pushing people to look for alternatives where this is a roadmap and people can plan ahead.
I sure hope that you and Plex Inc. have an internal roadmap you use to plan features and development. However by not sharing things like this at a high level you take this planning away from us. This might be ok for the medium and small systems but not for larger systems.
The downside to this for Plex. If the 1%ers or some of them are forced due to policies to switch software then a few things happen. They stop contributing (at least at the same level) here. They take their knowledge to another provider of software and the knowledge of how things should/could work get absorbed into this other product making it even that much more powerful. They start participating in the other products forums making the knowledge base of the other product that much greater and bringing on more expertise to the other product while decreasing here.
In some ways this is even compounded for a product like this because many of the 1 to 5%ers are technical and many are programmers. So if they seek out an alternative product that is also open source then they themselves can also use their own expertise to make that product better and to contribute.
Many of the 1%ers talk offline to 2%ers and 5%ers. Guess what happens. These 2 and 5%ers get thinking. Jeeze if so and so is now using product X for his system then I better make the switch too or at least evaluate it. It becomes something of a snowball affect. I'm sure this sounds familiar because this is sort of how Plex came to be.
I really don't know what to tell you other then what has been said over and over in the thread regarding the "roadmap policy not working".
What is being said is that we WANT to have some type of roadmap and what you are answering, NO you can't have it. I would urge you to just ponder and think about this. There HAS TO BE SOME TYPE OF MIDDLE ROAD or this will continue to haunt you over and over again.
Maybe you stick to your guns and don't announce NEW features but open up the roadmap to fixes and management of existing features for example which would probably be a fine compromise.
Maybe doing things a bit different in the future as suggested would help. For example do a NEW feature release. Then nothing but maint releases until said features are brought up to needed specs by users. You could space new releases out but then maint releases should come much quicker. For example getting weekly or bi-weekly releases (only an example) that fix and add needed management features to existing items would go a long, long way to good will.
I know some of the messages and this thread are probably hard to take or digest in both length and content. We very much appreciate your feedback and your willingness to have something of an open dialog with us.
Carlo
