@hackztor@gmail.com said:
By the time Plex implements this everyone will have one gig connections and it wont matter.
I recently upgraded to the 1gb, and I’d still like to have some control. But, it is definitely not as big a concern now I have no data caps. Some folks still have caps, even on 1gb, and this would be useful.
It’s never been caps I’m fully worried about, its that my ISP doesn’t want people like us running servers, so limits upstream bandwidth to 1/6 download. Heck, my ISP even started advertising limited markets anti-Google and, in my mind, it’s no competition. Google = 1000mbps/1000mbps, my isp = 1000mbps/35mbps.
Big whoop.
And remember folks, typing +1 doesn’t do ANYTHING towards a vote.
Click first post = like.
Agreed this is a mandatory feature. It should require no voting and it is not that hard to implement.
I wonder how many other posts/votes have been deleted from this thread. Mine was 
I guess I should say only nice things about a company that does not listen to its customers for 4 years now and instead implements features never requested or wanted (indirect connections to name one)
It’s a shame this is a feature asked for back in 2013, has 22 pages of people supporting the suggestion for this feature, and here in 2016 it’s not only something we still don’t have but something the authors have not even chosen to reply about. I know they read these things, and they have listened to suggestions before from this community, I’m just not sure why this one hasn’t garnered any attention?
Feature desperately wanted +1
@Mwidders said:
Agreed this is a mandatory feature. It should require no voting and it is not that hard to implement.
Are you a developer? No.
Don’t say things are easy when you aren’t working on it.
@danjames92 said:
@Mwidders said:
Agreed this is a mandatory feature. It should require no voting and it is not that hard to implement.Are you a developer? No.
Don’t say things are easy when you aren’t working on it.
I haven’t done any coding for years. I now do the hardware side of Network Administration and Network Design. And I’m sorry, this is most definitely a MANDITORY feature that has been missing for a very long time from a full blown Client/Server suite like Plex. Just because it’s for streaming media and not IIS, Exchange or any other Client/Server suite doesn’t reduce the impact the lack of these controls can have on a network.
Easy to program? It shouldn’t really be all that hard to do. Of course it does require having some info in the API that just isn’t there now if we want to have a 3rd party doing the development, so yeah, it is going to require something from the team itself. Mainly changes to the API…
@MikeG6.5 said:
@danjames92 said:
@Mwidders said:
Agreed this is a mandatory feature. It should require no voting and it is not that hard to implement.Are you a developer? No.
Don’t say things are easy when you aren’t working on it.
I haven’t done any coding for years. I now do the hardware side of Network Administration and Network Design. And I’m sorry, this is most definitely a MANDITORY feature that has been missing for a very long time from a full blown Client/Server suite like Plex. Just because it’s for streaming media and not IIS, Exchange or any other Client/Server suite doesn’t reduce the impact the lack of these controls can have on a network.
Easy to program? It shouldn’t really be all that hard to do. Of course it does require having some info in the API that just isn’t there now if we want to have a 3rd party doing the development, so yeah, it is going to require something from the team itself. Mainly changes to the API…
It may be mandatory but you shouldn’t say it’s easy when you have no idea. Only the developers can comment on how hard / easy it is.
@danjames92 said:
@MikeG6.5 said:
Easy to program? It shouldn’t really be all that hard to do. Of course it does require having some info in the API that just isn’t there now if we want to have a 3rd party doing the development, so yeah, it is going to require something from the team itself. Mainly changes to the API…
It may be mandatory but you shouldn’t say it’s easy when you have no idea. Only the developers can comment on how hard / easy it is.
I’ve written a third party tool to stop transcodes, I’ve read through the decision processes in the log files, so yes it’s would pretty easy on their end. Their biggest decision would come down to whether or not they want to do it per user or have a server wide setting (per user!).
@random.server - Ok, fine, you think it’s simple as adding a limit on the server side.
Here’s a major choke point you may not have thought of;
Tell me - how do you propose the client tell the user trying to watch the (not allowed or speed limited or number per month limited or whatever server setting) stream from the server in a nice way that doesn’t crash the client or require every single client be updated to understand what the server is trying to say?
Decent list of clients - https://forums.plex.tv/discussion/190573/list-of-current-client-product-and-client-platform
Remember, each client is different. You can’t just pass them a text or photo stating “sorry, you’ve reached your limit”
I think each client would have to be updated too, just like the server would be.
That’s a huge undertaking.
This shouldn’t really require a rewrite of any clients. They don’t care how fast they get something. The client gets what the server sends it, if what is stored on the server itself isn’t as high of a bitrate as what the client requests. The server doesn’t transcode up to the client’s requested bitrate. It sends what it has. So no, there shouldn’t need to be anything touched on a per client basis. This is all server side.
So, instead of sending a 20Mbps version, and the user is limited to 4Mbps, then the server looks at the client request, and says “no” you can’t have your requested 20Mbps. The server compares the next copy (OM version?) and does the same compare. Until it finds one that matches or is under the bitrate limits for the user. If none match or aren’t within a set limit under, then it takes the lowest bitrate version over and transcodes it for the user at the server side designated cap. (Or can just take the one under instead.)
And yeah, this shouldn’t be that hard to do. Start out with the bitrates (already stored in the DB) and compare to the bitrate limits set for a given user. This has been done on FTP sites for decades, so the tech is proven. (Do you have a premium account on this FTP server? bandwidth X if so. No premium? X-Y bandwidth. Two premium users at the same time, total bandwidth is X+X and both users get fast downloads until the FTP server’s hard cap is reached.) Something very similar could be used, only using actual bitrates of the media instead of a logical switch.
The problem right now is, the client is often set to the highest setting (by default) it’s capable of using (20Mbps for most.) so the server tries to send that. And right now, that particular setting over-rides what the admin wants, even if he has an OM version available for that user to use. We can’t force a user to set a specific bitrate, and we can’t “push out” a set bitrate to the user/client based on permissions. That’s where being able to set up per user bitrate limits, on an individual SERVER side control becomes so important.
This wouldn’t even require adaptive bandwidth technology. As the limits are hardcoded to the user, and no matter what they request, they only get the server specified bitrate. If that’s not fast enough for their connection, then and only then does the user need to make a change to a lower bit rate (and only if they know how to do it.) to make up for any buffering they might have.
If 5 users are all on at the same time and each limited to 4Mbps on a 20Mbps line, then most are going to have some buffering. And there is where adaptive is going to come into play. The server and client renegotiate the streaming rates to get something smooth for ALL clients streaming at the same time. After someone stops watching and someone else starts another movie they would renegotiate again, to find the bitrates needed until the user cap is reached.
As for what needs to be put into the API? Well, combined stream bitrates for all parts of the media streamed would be a start. How much bandwidth does the given stream require for the user to get his movie? If the user doesn’t require subs, then he might get a bit higher quality video. Or if he doesn’t need 5.1 audio, same thing… higher quality video again.
As has been said many times in this and other threads, QoS rules could be used, but those rules are going to limit a port or range of ports, and not an individual user. If there are 20 users all requesting something from the server at the same time, and the QoS rules say 4Mbps, all 20 users are going to buffer their share of the 4Mbps. QoS isn’t even in the ball park for a reliable method for people with slower connections.
What really yanks my chain about all of this, is that most Android tablets don’t have phone services But they have a mobile and a WiFi setting for bitrates, instead of the way it used to be, Remote, Local and Mobile. It makes no sense to have mobile data on a device that doesn’t have mobile at all… So I set 20Mbps for my tablet on WiFi at home. And the mobile(?) for 2Mbps and have to change the WiFi to 2Mbps to watch something at a friend’s house because there isn’t a remote setting anymore… And little to no traction on the feature request I put in for getting this setting back! You can bet if/when I ever get to talk to any of the Team on a one on one, I’m going to mention this!
EDIT: It might not be easy to do, if the coding is done by 3-10 people and not documented well in the source, but for modular programming methods, this shouldn’t be hard at all.
@“MikeG6.5” - Your example covers a bitrate limit, yes; it doesn’t cover many features I and others would like to see - time slots (open to all midnight to 6am, open to 4 at a time M-Thur, 2 at a time Fri-Sunday), number of watched per user per time frame (3 movies per week, 6 total per month), video type (2 transcodes at once, 4 direct play at once, or 1 transcode + 3 direct).
Stuff like that.
But all that stuff is extra not required. Bare minimum is to be able to control the speed. That in itself atleast prevents buffering which leaves to a bad plex experience. They can add other stuff later on.
@JamminR said:
@“MikeG6.5” - Your example covers a bitrate limit, yes; it doesn’t cover many features I and others would like to see - time slots (open to all midnight to 6am, open to 4 at a time M-Thur, 2 at a time Fri-Sunday), number of watched per user per time frame (3 movies per week, 6 total per month), video type (2 transcodes at once, 4 direct play at once, or 1 transcode + 3 direct).
Stuff like that.
@JamminR said:
@“MikeG6.5” - Your example covers a bitrate limit, yes; it doesn’t cover many features I and others would like to see - time slots (open to all midnight to 6am, open to 4 at a time M-Thur, 2 at a time Fri-Sunday), number of watched per user per time frame (3 movies per week, 6 total per month), video type (2 transcodes at once, 4 direct play at once, or 1 transcode + 3 direct).
Stuff like that.
I want to see some of those features added as well, @JamminR but they aren’t a part of the original request, as proposed by the first post of the thread. The additional comments might outline them, but they aren’t part of what everyone has been voting on and discussion of them in this thread isn’t appropriate, IMO. Let’s put those discussions in the right threads, and then get the voting going on them as well. (Some of these ideas already have feature requests, if memory serves.)
My suggestions for the ease of implementing this above covers the things pertaining to THIS request, and only to this request. My ideas leverage data already present in the DB, and could use some fairly straight forward logic to determine how to play the media. Some of that logic is already in place within the existing code. The “Play Version” most clients already have could be leveraged from the server side to force a specific file for a given title. Assuming that there is a proper bitrate version already existing. If not, then instead of “Play Version” it becomes “Transcode Version” internal to the server itself. We already know the Plex New Transcoder can be used to generate media to fit a bitrate limit, through both the RT transcoding and through the OM feature.
So yes, some of the code for this particular feature already exists on everyone’s server. It’s the hooks to tie in a bitrate limit to the transcoder or an existing OM version we are lacking. (There’s a little more to it, but that’s the essentials.) Now it’s a matter of telling it which version to transcode, and to set the limits on the server side for each user. Then verify that those limits aren’t exceeded during the stream. Which I believe the PNT can do already when a client is set to a specific bitrate.
This whole idea hinges on the user not having visibility that there are limits to the bitrates set on the server side, and that changing his local client settings will have no effect on the actual stream he receives. He can set original or 20Mbps all day long, but the server says he’s only going to get 4Mbps, and that’s what determines what he gets after this goes in. No coding changes needed on the client, because as far as the client is concerned the only version that exists is the 4Mbps version he is streaming.
And if we are going to add to this request, I would like to see a setting for local to the server, and remote to the server for bitrate limits. If a user is streaming remotely they have lower bitrates than if they are local, because once you pay for your network hardware (router, switches/hubs, etc.) it’s basically free bandwidth locally. You’re just paying electricity to keep the things going. It’s the remote access that can get expensive for some people. That outside pipe can get spendy when you exceed your ISP’s cap by 2x, 3x or 20x every month running. Not everyone has an unlimited cap on their bandwidth.
@MikeG6.5 - Finally someone who gets what I’ve been trying to say! I access my server remotely during the week as I travel for a living. Last night I had 16 users streaming (including myself) and until the one or two users who were monopolizing the bandwidth stopped streaming it was buffer or stutter city. The new Apple TV seems to be the biggest culprit as they seem to always be direct steaming or direct playing large files. I have 150/20 bandwidth through my ISP and it just can’t keep up with streaming like that…
@jerseydevil62 said:
@MikeG6.5 - Finally someone who gets what I’ve been trying to say! I access my server remotely during the week as I travel for a living. Last night I had 16 users streaming (including myself) and until the one or two users who were monopolizing the bandwidth stopped streaming it was buffer or stutter city. The new Apple TV seems to be the biggest culprit as they seem to always be direct steaming or direct playing large files. I have 150/20 bandwidth through my ISP and it just can’t keep up with streaming like that…
You were streaming to 16 people on a 20Mbps upload link? You must keep some very low bitrate files!
You are saying you had 16 simultaneous streams going at one time on a 20Mbps connection and people were buffering? I wonder why??? There is no amount of bitrate limits that are going to fix this. There are only a few ways to resolve this situation:
Realistically, transcoding is out of the running for making 16 simultaneous streams, as most of us don’t want to have to mortgage the home again to buy the hardware to handle this. The highest rated CPU made only scores 22K passmarks, and sells for $3400 a chip. We all know Plex’s own support documents state a 1080p 10Mbps stream requires 2K passmarks per stream for On Demand transcoding, so there’s 11 streams in that CPU. What, just over half? So we need 2 of those CPU’s. And then a dual CPU board to support that CPU, so we’re already up to $10K+ for the cost of the system, and haven’t bought drives, case, PS, memory or anything else. Just CPUs and MoBo… And that’s just a 10Mbps original file. How much of your media is in a 15Mbps or 20Mbps? Increase CPU requirements for these accordingly. Yeah, On Demand transcoding is out of the running for most of us… so Bitrate limits aren’t going to help the guy here, with a 22K (or 44K) passmark machine
Faster connection speed? Ok this has potential. Let’s say you want a 4Mbps limit for your 16 friends. That’s what, 64Mbps worth of upload speed. (Where you currently have 20Mbps.) And realistically you want this higher, to support your own downloading, so let’s say 80Mbps for a connection speed. What’s the cost of this connection speed? I’m going to bet it’s probably 4x or 5x higher than what you are paying now. And remember, you can’t charge your friends legally for streaming your media, so that cost is out of your own pocket… Most of us aren’t going to be able to afford that for long, either… It’s still an option, so don’t discount it completely, it’s just not realistic for a lot of people.
Converting the media into a lower bit rate to support their streaming? Ok, this means you are going to use something like the OM feature or another tool to make a smaller bitrate file for every item in your library. (targeting 16 users, here…) So given that your 10Mbps original takes up 8-10GB each, that means that a 1Mbps file is going to take up about 1/10th of that. So 800MB to 1GB per file. Just how large is your library now? And how many more drives can you hang on your system? This is about the cheapest way to stream to that many long term, but you may be limited on how many drives the system can handle… This is a one time conversion, but you need to store the files for later reuse… That means they have to be stored someplace, right? Not many are going to want to do this either, but who knows…
Dropping off some of the friends you are sharing with? Well, now we are getting somewhere. Combining OM versions with fewer people streaming and maybe a bit faster connection speed, and 8-10 people streaming at a time might be affordable. Double the bandwidth, and increase your storage by 50% and now you can get those people all Direct Playing a 2Mbps or 3Mbps version of your media pretty easily. Creating OM libraries are going to help out here a great deal. (Remember, Direct Playing your library means that the CPU is using maybe 2-10% of it’s power, instead of 80-100% of it per stream.)
An OM library is where the main library makes an OM version of your media in a separate folder. then the OM library points only to the folder the OM versions are put in. The OM feature makes a new version, that version is added to both the main library and the OM library at the same time. And you can do this now with any media you already have, without bitrate limits. You just share out the OM library to your remote friends. Keep the main library for yourself and local streaming only.
So, you really think bitrate limits are going to help you with the given situation? Not bloody likely! In this case, the causes of your buffering are your own fault. You shared out to too many people, and haven’t provided a version for them to be able to stream that fits your network topology. You are better served with the OM library for now, and making sure you don’t have the extra 10-12 people streaming that your network can’t support. Combining the OM feature with a per user bitrate limit means not having to maintain 2 separate libraries. One library, with both versions (the main library from above) and then the user gets only the OM version when he streams from you as this is what he’s limited to based on the limits you created for his ID.
Combining the OM feature with bitrate limits and adaptive bitrates are where we all want to get to. Set Joe up with a 4Mbps max, but as more people come on, his speed drops to something lower, and then it picks up the next lower OM version to stream to him, all seamlessly as far as he is concerned. No matter what, he’s never going to get more than 4Mbps, but he might not get even half that if there are 4 or 5 others streaming from the server at the same time.
Wait, doesn’t that mean we need to have more than two copies of the media? Yes, it sure does, and the increase in storage hanging on our servers increased as well. And I think there was a discussion not too long ago about how Netflix is doing exactly the same thing right now with their streaming service. Multiple copies of the media, in various bitrates, and renegotiating if there are problems streaming the current version and then streaming a lower bitrate version to the user as a result of the renegotiation.
The bottom line is, we need bitrate limits, but with it we need adaptive bitrates, too. And we need to leverage the OM feature to make the best use of both bitrate features to make sure our users have a better experience. Nothing is going to fix 16 users on a 20Mbps pipe. At least nothing short of dropping about 3/4 of those users, anyway…
@MikeG6.5 word.
@MikeG6.5 - Yeah it’s not uncommon for me to have 10-15 users streaming at the same time (I share my server with about 40 friends and family members). Most of my content (4k+ movies, 25k+ TV episodes) are much smaller files. Most TV shows are less than 1 gig and moves mostly range from 1.5 to 5 gigs. No not all of the streaming is remote, at least 3 of those were on the local network. Most of the remote clients are running with direct play and direct stream turned off and video settings of 2.0 Mbps or lower so that we have a better chance of all “playing nice” together (when I’m remote I often run at 320kps or 720kps because it doesn’t need to be a high bitrate if you’re streaming to a crappy hotel TV). The clients are everything from the new Apple TV, various Roku versions, Chromecast, Web UI, Amazon Fire, and even some using PlexBMC. The hardware is a dedicated i7 mac mini with 16 gb ram and 4 Pegasus RAID arrays providing about 64 TB’s connected via Thunderbolt. Now I am eventually stepping up to a 12 core Mac Pro with 64 gb ram, and switching over to FIOS 500/500 to address my bandwidth problem. Hardware, clients, and content aside, bitrate limits and adaptive bitrates (like being used by services like Amazon and Netflix) are what is needed for any multimedia client server application with concurrent local and remote users.
