Take a look at 0.9.15.0 and see if you see what I’m seeing. Settings -> Server -> Network and about the middle of the boxes on the right side…
Does anyone else see a couple of new lines there that read:
-> External network upload limit per stream
and
-> Cloud Sync upload speed limit
Uhm… Are these what I THINK they are? Did Elan and Team give us server side bandwidth limits and sneak it in without telling anyone?
The CloudSync preference has been there for a while, actually.
The second one shouldn’t have been user-visible. Yet 
It would make sense I wouldn’t ever see it, I don’t use outside cloud services… And I just tested this while I was waiting for a response… If I have the client set to whatever, and I put in a limit of 1.5Mbps on the settings for each stream on the server side, I get the 1.5Mbps Optimized Version sent to the client app!
What a great thing… 
I’m stoked! And soon we’re going to get per user limits, too, right? (Hoping so, anyway…)
What a Merry Christmas present for those of us with limited bandwidth!
I do hate to disappoint, but that preference isn’t hooked up yet, so I’m not entirely clear what you’re seeing
But yeah, expect great things in 2016!
Well, something must be hooked up, cause it seemed to be working on my end,… Of course the only thing I have to work with off the local network is my cell phone, and that may have it’s own limits from the company…
hehe, so someone let the cat out of the bag a bit early you’re saying??? Does Barkly know about this yet?
I feel like cheering, TBH…
First I’m very HAPPY to see something along these lines for bandwidth management.
However, when implemented this may help a few people but if it works exactly how it’s implied it’s not going to be very popular overall since you have no control over the total streams.
What is really needed is:
Per user stream limiting. Example I give 3Mb to friends but 8Mb to family.
A Total Bandwidth usable for the server (not per stream) setting.
The server then sets each stream no higher than the per user setting BUT ALSO takes into consideration the total server bandwidth of the server and splits this among the total streams decreasing the highest bandwidth users till they all fit the server max bandwidth.
The current setting just per stream doesn’t do a lot. For example if I set it to 3Mb and have two users streaming my server would be using 6Mb. If I had 10 users streaming then I’d need 30Mb of bandwidth.
Granted if you only had 20Mb available and know you typically have 5 streams going during prime time you could set the per stream limit to 4Mb. But then during non-prime time when you only have 1 or 2 streams they are still limited even though you have the bandwidth you could give them.
Ideally each client should have a max bitrate setting. Then the client requests this bitrate/resolution from the server. The server does it’s thing to adjust the bitrate it can give the client. If it’s less than what the client requested, TOUGH, the client needs to use what it’s given. The server can use a form of Dash or HLS showing 3 streams (one higher, one lower) that are “fake” but would allow the client to shift bandwidth. The higher/lower “fake” streams might cause a new transcode to take place or could use an “optimized” file version which could cause a pause on the client but would be no different than manually changing resolution/bitrates. It’s just done automatically adjusting to the bandwidth of the file given by the server.
The client technically wouldn’t need to use Dash/HLS either. It could simply automagically tell the server it’s changing resolution/bitrates when the client is buffering and runs out of data. One of these two methods should work for all the present clients I believe.
It sounds harder than it really is but the above would give us pretty decent bandwidth controls that would fit the large portion of our audience.
My 2 cents,
Carlo
It won’t make everyone happy but it’s an excellent start. This guarantees that someone doesn’t crank up their bit rate and start hogging limited upload speeds. That’s good enough for me.
It’s a privilege to have access to my library and it isn’t handed out willy nilly and I keep the number of shared users well within my upload bandwidth.
Bravo!
@Dr Tone said:
It won’t make everyone happy but it’s an excellent start. This guarantees that someone doesn’t crank up their bit rate and start hogging limited upload speeds. That’s good enough for me.It’s a privilege to have access to my library and it isn’t handed out willy nilly and I keep the number of shared users well within my upload bandwidth.
Bravo!
Why don¨t public out thee people who use your bw? every tcp stream can be traced then published the the corresponding IP to an web interface. where IPs are linekd to names
@cayars said:
Ideally each client should have a max bitrate setting. Then the client requests this bitrate/resolution from the server. The server does it’s thing to adjust the bitrate it can give the client. If it’s less than what the client requested, TOUGH, the client needs to use what it’s given. The server can use a form of Dash or HLS showing 3 streams (one higher, one lower) that are “fake” but would allow the client to shift bandwidth. The higher/lower “fake” streams might cause a new transcode to take place or could use an “optimized” file version which could cause a pause on the client but would be no different than manually changing resolution/bitrates. It’s just done automatically adjusting to the bandwidth of the file given by the server.
This is a proper solution and one Plex team should pay attention to (this is how Netflix etc does it, but they have Optimized versions for each “quality” instead of live transcode)
It’s easy to make optimized versions now, but the quality isn’t going to be the greatest. It’s using the same basic settings RT transcoding is using, so the quality is the same as that. We can hope they will allow us to use custom settings as this feature gets fleshed out a bit more.
@cayars has a discussion about that in another thread as well. I hope that between the feature of bandwidth limits and optimized media we can get a really good working solution that will answer everyone’s requests. and still serve quality streams to our users.
And before someone says they don’t want to “waste” the extra HDD space the optimized versions are going to take, well… For $125 you get an external 3TB HDD or larger to store those optimized versions on. It’s easy to add more storage, to almost any system with usb3…
@MikeG6.5 said:
And before someone says they don’t want to “waste” the extra HDD space the optimized versions are going to take, well… For $125 you get an external 3TB HDD or larger to store those optimized versions on. It’s easy to add more storage, to almost any system with usb3…
Optimization is only feasible for small libraries - for larger libraries I still prefer to transcode in real-time, that’s why I bought a Xeon processor in the first place.
.> @mshe said:
@MikeG6.5 said:
And before someone says they don’t want to “waste” the extra HDD space the optimized versions are going to take, well… For $125 you get an external 3TB HDD or larger to store those optimized versions on. It’s easy to add more storage, to almost any system with usb3…
Optimization is only feasible for small libraries - for larger libraries I still prefer to transcode in real-time, that’s why I bought a Xeon processor in the first place.
I guess it depends on what you consider a large library… I have a middling sized library, with 1700+ movies and 14,000 or so TV episodes. I am using Optimized Media to maximize my library’s potential to be Direct Played and not transcoded. I’m sitting at about 16TB of the 28TB of space I have available. There are others on these forums that have 2, or even 3 times the disk space and are doing exactly what Optimize Media feature is doing, but they are doing it with scripts or apps and getting good quality conversions, instead of the same as what comes from the RT transcoder.
I’ve had 7 streaming at one time, and still not greatly taxing my NAS. And yes, I’m running my entire PMS on a NAS… All but 2 of those were Direct Play. And had I had the bitrate version of the media to fit those 2 transcoding streams, everyone would have been Direct Play. Instead of an on-demand session getting deleted after those 2 shows were transcoded, I would still have the media in the format for the next guy or gal that wanted to watch the same show at the bitrates they required for the connection they had at the time, without RT transcoding.
Of course everyone has different ideals of how to run Plex the most optimum way. IMO having to transcode something 10 times, and then deleting each of those transcodes to fit the 10 requests for the media just seems kind of wasteful. If it’s already converted and sitting there waiting to be sent, then I don’t have to worry about taxing the system or having the fans kick into high gear to support the on-demand cooling requirements of a transcode that gets deleted after it’s run by the user…
My method means I have CPU left over for other tasks. Yours means you have more space for storing more media… You aren’t likely to change my mind, nor I yours.
But if I had the upload speed to support 10 requests at the same time, at 4Mbps, and the media is already made to support those requests, I’m betting I have 10 happy users watching my media on their devices. I’m also betting if you had the same 10 people asking your system to transcode your BR rips of 20Mbps down to 4Mbps to support their requests, that someone buffers. (Likely most if not all) Unless your Xeon is capable of 20,000 passmarks, anyway… (Do they even make CPU’s with that high of a rating yet? At least commonly available?)
You reach a point of diminishing returns with transcoding. CPU’s can’t be made to do the task without handing it off to other units with distributed transcoding. As of right now, that’s pie in the sky for Plex…
And this little thought exercise just confirmed in my mind that having multiple versions of the media is the only way to go with bitrate restrictions on the server side, and not the client side. I set the bitrates I want my users to have for remote streaming, and then I provide the media in that bitrate for them to stream. Easy… And a no-brainer…
To me, what’s another 3TB drive? Pocket change… For you, what’s another machine to do your (not yet working) distributed transcoding on? Another year or more away in software updates before Plex has something built in? And another $3000 or more in expenses to build the machine? And then what happens when that machine gets saturated? Another $3000 or more? For me, it’s another $125 drive, or at most $1000 for a 10-20TB enclosure. I’m WAY ahead on the money game, and it would look like on the user experience game, too…
But hey, you invested in CPU. Good for you. If I had that CPU in my NAS and the bandwidth to support it I could have had half of the town I was in, in Alaska, watching media off of my NAS instead of drinking their livers to death. And they all would have been Direct Playing media and not buffering as the CPU chokes out on transcoding sessions it can’t support.
Transcoding works great, for small libraries and nearly unlimited bandwidth or local streaming. Remote streaming with multiple streams going at once, it’s literally a nightmare. Transcoding is NOT a viable solution at all in those circumstances. And as more and more people find out you have all of your movies available to watch with Plex and request access, I think you’ll have a change of heart…
I think the biggest difference is the quality of the encoded material. If you pre-transcode outside of plex and create a couple versions before adding the media you can have high quality files that are superior to anything Plex can transcode in real-time. Right now until changed the Media Optimizer is basically the same as the real-time transcoding quality wise. If Plex allows the user to choose the Profile and Quality used for the transcode it’s a whole nother ball game and the Optimizer built into the server would be near perfect.
This is not a knock on Plex at all. But there is only so much you can do with a real-time transcode especially if you have to do multiple at the same time. A transcode done for quality can take 2 to 5 times the length of the show/movie to do without GPU assistance but the quality will be as good as possible. This file will have far better detail in action scenes, will not be no where near as “blocky” and will actually be smaller overall which is even more important for streaming with limited bandwidth or storing for long term archival.
So if you take that same argument to CPU vs storage and what is going to work best overall for the END USER it’s going to be the solution that streams easiest (no pausing) and looks best which in the ideal world is the pre-transcoded material.
I mentioned above the Media Optimizer is near perfect if it would allow us to change the profile and quality. Once those 2 things are added you/me/anyone could setup a hybrid system. You can setup MO to pre-transcode the last 10,50,100,etc newest movie/show for each section which is typically what people go for and use the CPU for real-time transcoding of other files. You can add tags to files like “recommended” or “popular” or “top 500” and setup MO to keep these files Optimized regardless of their “newest” status.
MO has the potential to be a very good addition to system due to it’s flexibility in this regard. It just needs a bit more work to control the conversions and to work better with SYNCing.
But getting back to powerful CPU or not. By making use of MO (even in it’s present state) to keep your popular and newest additions already optimized you’ll find you can get by with much lower overall CPU power. Since doing this and using MP4 files I’ve went from running on a quad 12 core (48 cores, 96 with hyperthreading) server back to an old i7 which handles the transcoding just fine for when it’s even needed.
Carlo
I’m the one responsible for the External network upload limit per stream preference and I can definitively state that it is currently being ignored everywhere in the code. It was not intended to be visible at this time but is a placeholder for future work.
@gbooker02 said:
I’m the one responsible for theExternal network upload limit per streampreference and I can definitively state that it is currently being ignored everywhere in the code. It was not intended to be visible at this time but is a placeholder for future work.
No need to test this then… but you know it’s got a lot of us pretty happy to see it… Even if it’s a screw up… 
I just hope you guys are listening to what @cayars and others are saying about having a per user limit, and an over-all limit instead of just a per stream. Don’t give us just half of the solution we need. Give us the whole thing from the start…
@MikeG6.5 said:
I just hope you guys are listening to what @cayars and others are saying about having a per user limit, and an over-all limit instead of just a per stream. Don’t give us just half of the solution we need. Give us the whole thing from the start…
I believe the intent is to give you what we have ready as it becomes ready rather than holding some features until everything is ready. The other limits are well known, but a per-stream limit can be delivered faster than others and thus is better than nothing until the full solution is ready.
@gbooker02 said:
@MikeG6.5 said:
I just hope you guys are listening to what @cayars and others are saying about having a per user limit, and an over-all limit instead of just a per stream. Don’t give us just half of the solution we need. Give us the whole thing from the start…
I believe the intent is to give you what we have ready as it becomes ready rather than holding some features until everything is ready. The other limits are well known, but a per-stream limit can be delivered faster than others and thus is better than nothing until the full solution is ready.
Thanks for the reply! Believe me, we’ll take what we can get. Any type of control is better than no control.
I easily can see this rolled into the mis-named “Restrictions” settings for users. A setting there for bitrates allowed remotely for each user, and then an over-all not to exceed on the main server settings.
Tie in the Bitrate settings for a user’s On-Deck and the OM feature and every x number of episodes ahead of the user’s current on-deck for that series gets pre-optimized at the bitrate limits set for the user. If I know user ABC binge watches 5 or 6 episodes a day, I set his user profile to optimize 6-8 episodes at his bitrate limit. User DEF only watches 2 or 3 max per day, so I set OM to do 5 episodes ahead at his bitrate limits.
All of this is set once and forget options that can make a huge difference in how our users are going to experience Plex. And since I’m setting those limits on my end, it’s not going to matter what the user’s app settings are, they get what I want them to get and what my network supports, optimized for that particular streaming experience. I’m basically making each user a tailor made copy of my media just for him, in advance of what he requests.
If someone is allowed to sync, and we have an OM version made for him, he gets the OM version synced automatically that fits his bitrate settings and these are marked as “pending” and the OM takes the next set to make based on the syncing request. So if he syncs 5 and I have him set up as 5 ahead, it keeps the 5 he has synced until they are marked watched, but adds in another 5 to the mix to pre-make.
After the user watches the next episode, another setting in the User Profiles tells Plex what to do with the watched media. Does it keep it for user LMN if he is 3 days behind DEF? Does it delete the OM version? All from the individual user’s profiles.
I see some really great potential here.
Of course this only works with TV Shows… But if Movie Collections were implemented like the mockup Feature Request has, something like that could easily be done for them as well. Pre-make 1 or 2 movies ahead in that collection for the user, since we know people seldom stop watching Harry Potter until they have watched ALL of the movies…
The ways this could come into play are really staggering!
I’ll believe it when I see it… then I’ll wait for it to be taken away in some update because it isn’t a “very used” feature or something… I have been migrating users away from my plex server to emby… has all these features and more, and it’s free… plex really needs to catch up and I don’t mean adding support for more devices… get your core fixed up first
I didn’t test yet, but can plex confirm that the limit will ‘trap’ a user in a specific transcode or optimized version? i.e. limit to 1.5Mbps and they get 1.5Mbps optimized version, or they get transcoded to 1.5Mbps stream? …or the source is <=1.5Mbps and it streams direct…
This option isn’t live yet, so testing it right now won’t work. But that’s the idea, I think… and I hope that using this and the OM feature we can do what I outlined 2 posts up sometime in the very near future.
I know if I set the client’s settings to 1.5Mbps I get that optimized version right now if there is one made for the media. This has been tested and works very well. Now the issue is going to be if the force of a 1.5Mbps can be enforced past the client app’s requested bitrate. If the server can enforce the bitrate cap, then selecting and streaming the requested media at that bitrate should work as intended.
and to @flecom hey, thanks for your informative and well thought out post. I hope Emby does all that you want it to do. And please, close the door on your way out, would you? The rest of us are waiting to see what the future brings to Plex…
