I’d love for all the clients to be the same feature-wise, however some are more behind than others and you have to realize that plex’s employees are not all versed in all the different clients programming.
I’d imagine that
some developers work solely on the backend (plex server, plex Apis)
Some work on mobile clients (android, IOS)
Some work on PHT.
As PHT was the first product plex had, you can assume more of its employees can add to that ‘branch’ than the rest. So PHT will be up to date first, whereas there might only be one dev that’s versed in IOS programming, meaning it will obviously be much slower to add to that branch, so in this scenario a ‘freeze’ means you have potentially 90% of your dev team not able to do any work, which is just silly.
Instead plex needs to have more developers/time for their products that aren’t updated as often/fast as their other products, so all clients receive updates in a realistic timeframe.
E.g feature release.
one or two clients have feature fully implemented at release
ALL clients have feature partially implemented 1 month later
ALL clients have feature fully 3 months after release date (unless not achievable on that client)
This might sound unrealistic, but remember this is 3 months after official release. These features should have had the groundwork layed for months/years beforehand, features being partially working 3 months after ‘release’ just makes the product look unreliable, which is exactly what plex shouldn’t be
The devs should have some kind of roadmap like this for the features, and I think this is a problem plex needs to address internally as they become a much bigger project than they were originally.
It needs management to follow up on these things, and find out early if a feature is going to be on time, if not why not.
Thanks for starting this well needed thread. I use the plex server, which works very well stability wise, but I think it’s sad that PHT is lagging so far behind kodi. I switched to kodi/plexbmc a while back and the playback experience is just day and night compared with PHT. But it shouldn’t have to be that way. I think it’s a big mistake letting the the main client slide this far. It’s like an old lady with a lot of new make up.
1. As has already been mentioned from my understanding Plex has seperate teams for each platform. So for feature parity those who are ahead would have to slow down and delay introducing new features. Which I just see no point to.
2. Also on the feature parity side the OP does not seem to have considered that some platforms might have limitations that prevents some features from being introduced. I would not want a requested feature to be not added simply because it is not possible on some platforms. The solution to this is simple you look at the features you care about and choose one of the platforms that has those features.
1. As has already been mentioned from my understanding Plex has seperate teams for each platform. So for feature parity those who are ahead would have to slow down and delay introducing new features. Which I just see no point to.
2. Also on the feature parity side the OP does not seem to have considered that some platforms might have limitations that prevents some features from being introduced. I would not want a requested feature to be not added simply because it is not possible on some platforms. The solution to this is simple you look at the features you care about and choose one of the platforms that has those features.
Good points however:
1. Teams that are ahead could focus of bug fixes / stability or performance optimisation. Their improvements could be implemented on other platforms easily enough.
2. If a feature cannot be implemented on a platform due to restrictions either hardware/software or the like, then explicitly say so. This gives closure to users of x or y platform instead of them sitting there in perpetuity waiting for something that isn't going to come.
I'm not saying "don't innovate if a certain client is where it needs to be". I'm more saying that ALL the clients I use have some pretty big backlog items that ought to be addressed prior to adding in any new features/random smart TV integrations/etc. PHT needs to merge with the Helix. Roku needs a lot of cleaning up and catching up (and maybe a Roku 3-only pretty UI?). PMS needs to merge the latest FFMPEG (which it looks like may be underway, which is exciting). Android seems to be in pretty good shape, save for some weird Sync bugs of late. iOS is a hot mess. Plex Web is in good shape, form what I can tell.
And yes..yes, yes, yes. I am not saying every feature has to fit on every device (does it make any sense at all to have Sync on a Fire TV stick with no storage, or have camera upload on a Roku that has no camera? No. No it doesn't). But PLEASE document what features go with what clients. There really ought o be a feature grid somewhere with "Consumer Reports" style dots for each to denote "Fully Supported", "Partial Support", "Support Planned in the Future", "Not Supported"
There really ought o be a feature grid somewhere with "Consumer Reports" style dots for each to denote "Fully Supported", "Partial Support", "Support Planned in the Future", "Not Supported"
I wholeheartedly agree with this. They can also use this grid to highlight features/clients that require a PlexPass.
But PLEASE document what features go with what clients. There really ought o be a feature grid somewhere with "Consumer Reports" style dots for each to denote "Fully Supported", "Partial Support", "Support Planned in the Future", "Not Supported"
Merge PMS with the latest FFMPEG (Atmos, H.265, etc.)
This, more than anything. It's sad when even good old DTS-MA, 7.1 audio etc. is not recognised properly and just shows as 5.1 audio in PHT. Audio is just as important as video for me :-)
So, not to be an ass, but what some of you guys are talking about contradicts the statement. People are voting for something that can't possibly be done. So before this get out of hand:
What is it OP really wants? Because at the moment the first post is basically saying: Freeze all features, but add more features.
How can a feature freeze be what you want if the first thing mentioned is to do a Helix integration?
Also, do all of those things mentioned in 1-2 release cycles? I might be misunderstanding what you mean by release cycles of course, so please restate what you mean in the original post. At the moment people are reading that and thinking that it can be done in a couple of sprints. That is just not true. Doing all that is listed is months and months of work.
And why merge Roku with RARflix? You just got a new release. I understand that you guys can request whatever you want, but this request will not gain any traction if you mix too many things. Sure, you will get a lot of votes because everyone has one of their favorite pet peeve in the list, but nothing will come of it if the request is not a bit more specific.
With that said, feature parity is something I long for as well.
What he means is not add anything that is not supported by some other Plex client already when he says Feature Freeze.
Until the clients all get to the point where they all do what the other clients can do so when you say "Plex does X" you can be sure your Client actually does X!
In the past it has been very confusing to read "Plex added Feature X" only to find that refers to only the iOS client but none of the others.
By putting a current feature freeze on the Plex Universe and using that time instead to make sure all clients support all features Plex currently has it will give all clients the chance to catch up to all the others and perhaps at that point it might make things far easier to add any FURTHER features to all clients at once.
Perhaps the way the clients are being developed is the issue here...
Clients for most projects use a single codebase that gets ported to the different OS' and Devices.
It would seem that each client in Plex is being developed as separate projects.
Considering that the Plex.TV site code is capable of doing most of the features it really baffles some of us why the various clients are not leveraging that code to make all features available to all clients at once. Or why you are even using different clients at all.
Get all the features into the Plex.TV (Plex Web), Make a client shell that can use that data either via Plex.TV (remotely) or via Local (Plex Web) and you won't need to add features to iOS then Android, then Roku, then Device X.
Code is code. What is written for one language should work in that same language across any device that has that language available to it, with minor modifications.
This is why it is so hard to understand how Plex is working things. You want to add Home Users to a client, drop in the module that is pre-written in the client's code, make the required calls in the main code and there is an updated, streamlined, modular updated client. New feature, add another module, make the calls and returns in the main code, there you have it, next client brought up to that new feature.
It sounds to me like there are devs doing work on iOS only (or perhaps one or two other clients) and they have designed things their own way. Then you get the Android folks doing things their way, and the code is different, with different modules, calls and returns. Then you get the next client and that group of devs, again, completely different approach to the code, and there isn't anything that can be dropped in from a different client. (With some basic modifications to support the device's implementation of the programming language.)
Feature Parity is going to continue being an issue, until they are all brought to the same level. You are always going to need the OS specific programers to tweak the code for that given flavor of the default programming language, but the lion's share of the work can be just a drag and drop, if the code is consistent and modular. It's obvious that this isn't the case with the current set of clients, though... :/
I haven't coded in YEARS, but the work I did do ran on Unix and with some small modifications Windows and Macs... Same code, just tweaked for the OS and the language's specifics.
Code is code. What is written for one language should work in that same language across any device that has that language available to it, with minor modifications.
This is the problem. Things like PMS and PHT are available to multiple platforms at the same time because of this, because they all use C or C++ or whatever programming language it is and all these platforms accept it. The other devices are a totally different story.
Android runs on Java. So you cannot take C code and just paste it into a Java compiler, it has to be rewritten from scratch. The Roku uses it's own programming language called BrightScript. Again, totally different programming language. The Samsung app has it's own (and they are switching to a different one in the future). I think the PS and XBox apps use similar code so they run almost parallel to each other. The WebApp is JavaScript and HTML and a bunch of other Web related languages mashed together. Apple, I have no idea.
So, I hope you can see the problem now and why parity is so hard.
So, not to be an ass, but what some of you guys are talking about contradicts the statement. People are voting for something that can't possibly be done. So before this get out of hand:
What is it OP really wants? Because at the moment the first post is basically saying: Freeze all features, but add more features.
How can a feature freeze be what you want if the first thing mentioned is to do a Helix integration?
Also, do all of those things mentioned in 1-2 release cycles? I might be misunderstanding what you mean by release cycles of course, so please restate what you mean in the original post. At the moment people are reading that and thinking that it can be done in a couple of sprints. That is just not true. Doing all that is listed is months and months of work.
And why merge Roku with RARflix? You just got a new release. I understand that you guys can request whatever you want, but this request will not gain any traction if you mix too many things. Sure, you will get a lot of votes because everyone has one of their favorite pet peeve in the list, but nothing will come of it if the request is not a bit more specific.
With that said, feature parity is something I long for as well.
We're asking Plex to freeze building new clients for new systems that currently have no client until all the clients that are currently available are stable and have feature parity. I don't need a plex client for my smart refrigerator, I need the ios app to have Plex home and syncing that actually works well and maybe the ability to play video out to hdmi without my iphone or ipad going to sleep. I don't think that's to much to ask for and it's more important than adding another half baked client to support another device.
First of all, I would like to give credit where credit is due, and say that some of this is being addressed.
The new Roku app, the forthcoming change to PHT to allow Atmos transcoding...very positive steps.
And I never meant for this to be an argument or contentious...it seemed fairly tame and common sense when I posted it (but, this is the internet, I suppose). At it's core, I just want Plex to get back to having the finished, professional "feel" it had a year or so ago, before everything got fragmented by vomiting out a player for everything with a screen and before new plex pass features started being rolled out faster then they could be finished (some day Plex Home will work on all the players. right?)
Ultimately, I just want less "PR/Marketing fluff" and more "unsexy maintenance to avoid falling behind". Perhaps I'm just reflecting my day job too much onto this, but it terrifies me when I see platform sprawl like this without a constant & conscious focus on maintaining "the core" and having a well defined "functional baseline" for all frontends. And perhaps some transparency about it all.
Nobody (well, OK...nobody who deals with code for a living or even a hobby) expects this stuff to be fixed overnight, or in a single sprint, or even 2-3 sprints. But without any clear communication of what's going on roadmap/"plan" wise (which I understand we don't and won't be getting) we're left only with the releases and trends therein to go by...and currently the trends are towards unfinished, fragmented, "preview quality" features sprawled out inconsistently across a growing & eclectic front end landscape.
TL;DR version: lately, Plex feels likes it's moving towards being both less consistent and less cutting edge. It would be easy to understand one or the other, but both is frustrating.
cayars had a similar thread that gained a ton of traction and elan even got involved. That combined with this thread and others gives me some good feelings on us getting through to the company as a whole. I don't expect things to change overnight but I'm optimistic about the future. I haven't given up hope yet.
Kodi is now on RC14.2 and an alpha of Isengard (15) has been released...
And Kodi they still lack a ton of things that Plex has. How come they release new stuff all the time and they still do not have the things that Plex has? How is that possible? Plex has been around for 7 years, and XBMC for soon 15 years (if my memory serves me). They really should have all the stuff that Plex has right? They have a ton of developers working on the same codebase right?
Yes, I know I was being a bit unfair. It is not the exact same thing. Its just that I get a bit ticked off by comments like that because there are so many layers to the onion that a comment like that is way to simplistic (in my view) to be fair.
Do not get me wrong, I understand that your personal preference does not match with the direction that Plex has at the moment, but stating that XBMC/Kodi once again has heightened their version number is saying nothing (in my book). They are adding things, Plex is adding things. And the things the two are adding is not the same. Should they be the same? Some think so. I do not. Because then I would use XBMC/Kodi instead.
Plex was created because of differences in ideology, and after that they split quite heavily in the feature set.
First of all, I would like to give credit where credit is due, and say that some of this is being addressed.
The new Roku app, the forthcoming change to PHT to allow Atmos transcoding...very positive steps.
And I never meant for this to be an argument or contentious...it seemed fairly tame and common sense when I posted it (but, this is the internet, I suppose). At it's core, I just want Plex to get back to having the finished, professional "feel" it had a year or so ago, before everything got fragmented by vomiting out a player for everything with a screen and before new plex pass features started being rolled out faster then they could be finished (some day Plex Home will work on all the players. right?)
Ultimately, I just want less "PR/Marketing fluff" and more "unsexy maintenance to avoid falling behind". Perhaps I'm just reflecting my day job too much onto this, but it terrifies me when I see platform sprawl like this without a constant & conscious focus on maintaining "the core" and having a well defined "functional baseline" for all frontends. And perhaps some transparency about it all.
Nobody (well, OK...nobody who deals with code for a living or even a hobby) expects this stuff to be fixed overnight, or in a single sprint, or even 2-3 sprints. But without any clear communication of what's going on roadmap/"plan" wise (which I understand we don't and won't be getting) we're left only with the releases and trends therein to go by...and currently the trends are towards unfinished, fragmented, "preview quality" features sprawled out inconsistently across a growing & eclectic front end landscape.
TL;DR version: lately, Plex feels likes it's moving towards being both less consistent and less cutting edge. It would be easy to understand one or the other, but both is frustrating.
Absolutely noted. It is not a request that is unreasonable. And work is being done to improve a few of the things in your constructive criticism.
