How is a client broken, if it worked fine last month? I will assume that all clients worked fine last month? Devs wanted to optimise/fix/implement something better and broke compatibility with something else, simple as that.
We’re not talking about new features or functionality, but resume.
We’re not talking about 10 year old apps, but apps found in TV’s sold even 2-3 years ago (and the premise was that they support Plex)
Sure, if all PLEX clients were managed by Plex, fixing them would be the best scenario. But that is not the case, and since the API was open to third-party clients (which are not always open-source), decisions that cut them off or break essential functionality should not be taken lightly.
API’s can have versions. Not all clients must use the same.
I can see how this can create overhead in code management though.
Bottom line is: I downgraded and stopped updating the server because 1 out of 10 clients (the main one, the TV) in my house is now considered broken,
Because the server was broken (to use your term; more accurately there was a bug on the server side).
Bad assumption; they did not. In order to fix those clients, the server bug was fixed, which in turn exposed the bug on a few clients. More clients were fixed than were broken.
You keep saying this but have provided no information to back this up !
What client was broken ?
As I said I have the following clients running fine on so called broken /buggy server version:-
Android App
OPHT on windows 7.
Kodi app (sucks but I got it)
Web app via Google Chrome on and Android device and on a PC.
All are still fine except Kodi which is very buggy anyway.
Evidence please or stop repeating the same stuff it’s getting old now.
I agree it’s a bug that Plex noticed , impacts probably 1 client and not noticeable by anyone other than plex…how do I know this ? Because the forum is the “ONLY” source of support or complaints and I have looked through a lot of threads and found Jack which is why Plex are refusing to answer my questions and backup with evidence.
Not asking for the code just a simple English response of we fixed it for IOS app or android app or X y z etc then if you are a moderator I am sure you can point me to the posts of actual users saying oh Plex our clients are not working then the oh thanks Plex for sorting my client out. All I see in the current forums is bad press updates breaking stuff and you all saying the fix was required but not indicating which clients were actually fixed which takes me to the question on loads of your users minds is was the fix required? No it wasn’t no evidence to back it up. The answer of we fixed more than we broke is unacceptable from a so called professional business.
Clearly nobody cares about what you fixed because no one even noticed it was broken to begin with. If you weigh it up you have more unsatisfied users than you had before you applied the fix
Not going to hunt down every thread here, nor ask Plex for details.
They said it was changed due to bugs with other clients, and yes, bugs doesn’t always have to surface to the end user, but could be a blocker for future dev!
And when said, @elan did point out, that somebody is looking into this!
Just wanted to give a quick update here as some of our engineering staff has been able to look into it (and thanks to @dane22 for the help here!).
OpenPHT and the Samsung client thankfully appear to have a similar bug where they send a play time of 0 as they start or end playback. This is clearly wrong We’ve had a go at detecting this specific buggy scenario and avoiding the new code in this case, which seems to work.
Engineering just needs to get the code through release and onto a release train, which means it should be available over the next few weeks.
Thanks for this, however, whilst patching this specific issue is good news, it still leaves the question of what Plex plan to do longer term to support platforms that are not currently supported?
the Samsung app is the biggest case in point here, just how many of your current base is made up by these?
We all know the history, however, you need to make a commitment to your current user base and get a new app developed for the non-Tizan Samsung platforms.
You’ve sort of answered your own question there; unsupported platforms are by definition ones we don’t spend any time on.
We’re always evaluating platform support based on userbase sizes and platform performance (e.g. if there’s a low-end platform with few users, it’s not a good use of our time). At the end of the day, we don’t have infinite resources, and there are a growing number of platforms (every year there’s a billion more TV models), which makes it a complex issue.
OK, can we speak specifics then? the non-Tizan Samsung’s.
there are literally millions of these out there, between myself and family/friends, we have some 18 of them, all running the old Plex app that’s now on its last legs, and by the looks of the responses on the smart-TV section, we are far from alone here.
Care to post up the number of sets running the old app? (I’m sure you know from the authorised devices lists)
Just how big does that number have to be for Plex to consider it worthwhile?
I appreciate this all cost resources (and thus money) but as has been punted before, however, are you really telling us that developing one app is prohibitively expensive? care to put a number to this?
Hell, if it’s really that big a squeeze, how about all us users with the older Samsungs chip in?
How about you come up with the numbers and then propose a solution that works for you?
Im a Samsung app user here, and also a dev, so if I’m reading this correctly, the client should send a non 0 play time at the start or end of playback.
What should be sent for the start of playback? 1? Or a state change of? I assume end of playback should also send item length in milliseconds? Or another state?
We’ve had a go at detecting this specific buggy scenario and avoiding the new code in this case, which seems to work.
So I’m really looking forward to this fix