@kanabrewski said:
@ChuckPA @cayers @mixolyd Thanks you guys for tracking this down. Hope we can get this streaming brain a slight lobotomy.
You not like it “Drain Bamaged”??? 
@cayars said:
@kanabrewski said:
@ChuckPA @cayers @mixolyd Thanks you guys for tracking this down. Hope we can get this streaming brain a slight lobotomy.You not like it “Drain Bamaged”???
I’m reading these forums and looking at posts since mid February. There is clearly something since 1.4.1.3362 that has affected users across multiple platforms, so yes “somtin Bamaged”
@kanabrewski said:
@cayars said:
@kanabrewski said:
@ChuckPA @cayers @mixolyd Thanks you guys for tracking this down. Hope we can get this streaming brain a slight lobotomy.You not like it “Drain Bamaged”???
I’m reading these forums and looking at posts since mid February. There is clearly something since 1.4.1.3362 that has affected users across multiple platforms, so yes “somtin Bamaged”
This issue was dating back to December 2016 if you check out the Hardware Transcoding Preview 2 thread. It just took the bug reaching the standard non-plex pass released before it gained enough traction to be taken seriously.
Guys, if any of you are in a position to help test something on your server let me know. Basically, if you have a remote client and can identify their IP address and it doesn’t change much then try adding this to:
Settings/Server/Network/LAN Networks
So for example if you have a family member/friend coming in from this made up IP of 123.145.14.3 then you would add:
123.145.14.1/255.255.255.0 to that entry.
You can have multiple entries listed by a comma. So you could have as example only:
123.145.14.1/255.255.255.0,201.103.17.1/255.255.255.0,96.75.114.1/255.0.0.0
Note that last entry I opened the subnet up to the class A address space.
So in a nutshell what this does is tell Plex Server that those IP/Subnets listed above should be treated as LOCAL IP addresses. From my testing this seems to get around the limited throughput bug many are experiencing. I do think there is another related bug but don’t want to express this yet.
From some quick testing on my side I’ve found that this allows the client to exceed the 2MB bandwidth “bug” many have been experiencing.
For those who can do this for family or friends who have reported a problem to you does this help them if you add their IPs to this setting?
Carlo
PS If any of you have high download bandwidth and wouldn’t mind doing a few private tests with me let me know. The more info we can gather for the Devs the better.
thanks @cayars — I’m giving this a shot. Been making me a little crazy the last while that streams were buffering that shouldn’t. Quick question, do I need to add anything referencing my own local network when I do this? Maybe selfish of me, but if there is gonna be buffering, I would prefer it’s someone else, not me. 
I’m on the phone with @cayars. we both saw this at the same time. 
He was operating the server for me. Local LAN is not impacted. Specifying the address/subnet in that field only benefits remote users… which seems to be somewhat outside the scope of the original intent of that field.
This isn’t a “solution” or “workaround”. This is his requested change for testing purposes only.
when this all gets resolved, that field will go back to normal (blank).
PS: He won’t stop talking in my ear while I’m typing this.
This isn’t a “solution” or “workaround”. This is his requested change for testing purposes only.
when this all gets resolved, that field will go back to normal (blank).
Completely understood. Just hoping for some positive results I can report back to you guys.
@cayers I have 800/800 roughly up/down if I can be of assistance
Adding the IP addresses for remote users seems to work for me. I noticed right away that streams were sent out in 6-8 MB “chunks of data” to remote Rokus again, not at the constant 1.8 to 2 MB of steady, continuous streams that have been the norm recently. PlexPy and “Now Playing” no longer indicate buffering every few seconds, so I assume all is well at the other end.
I added the external address to LAN Networks and I’m not seeing much of improvement. I’m getting around 6-9Mbit streams.
Check out the bandwidth graphs between the versions. On the latest versions 1.4+ remote stream is constant low out stream vs bursts of high bandwidth on 1.3.4.
Version 1.4.3.3433 (steady 5-90Mbit)
Version 1.3.4 (Bursts 20-72Mbit)
@leelynds glad to hear it helped for you!
@daveposh kind of hard to tell anything from those graphs. One is steady while the other is very spikey. CURIOUS do you know what the bitrate and codec of this file being streamed were? Same file playing from the beginning on both server versions? Direct play or transcoding?
@cayars said:
@leelynds glad to hear it helped for you!
@daveposh kind of hard to tell anything from those graphs. One is steady while the other is very spikey. CURIOUS do you know what the bitrate and codec of this file being streamed were? Same file playing from the beginning on both server versions? Direct play or transcoding?
I’ll explain the graphs the top displays a limit to upload bandwidth sent to the client. The client never gets its buffers full so PMS is constantly sending traffic at 1MB per/sec
The second graph show a burst of unrestricted traffic to the client. Client buffer are filled PMS stops sending data until the next burst of data.
Same file is being sent to client in both tests. In client original is selected.
Stream Details 1.3.4
Media
Container: mpegts
Resolution: 1080p
Video
Stream: copy
Width:
Height:
Codec: h264
Audio
Stream: transcode
Codec: aac
Channels: 2
Source Details
Media
Container: mkv
Resolution: 1080p
Bitrate: 19352 kbps
Video
Width: 1920
Height: 1080
Codec: h264
Aspect Ratio: 1.78
Frame Rate: PAL
Stream details 1.4
Stream Details
Media
Container: mpegts
Resolution: 1080p
Video
Stream: copy
Width:
Height:
Codec: h264
Audio
Stream: transcode
Codec: aac
Channels: 2
Source Details
Media
Container: mpegts
Resolution: 1080pp
Bitrate: 18072 kbps
Video
Width: 1920
Height: 1080
Codec: h264
Aspect Ratio:
Frame Rate: PAL
Audio
Codec: aac
Channels: 2
@cayars - After adding my IP to the list, I cannot see a difference. When I am downloading the media, it seems to cap around 12mbps (measured from the client task manager windows 10 version). It makes no change with not adding the IP (and restarting after changes). I verified that it is the IP it sees. To test my download speed from work (we are also an isp) it is fine downloading. I uploaded the same media file to OneDrive (via OneDrive built in sync) and got over 20mbps upload from the server. I also tried disabling HTTP pipelining and http vs https. Nothing is helping on my side yet. If you come up with any more tests, I will try to provide feedback.
If I may augment?
When looking at the data rate being transferred… Instead of referencing as Mbps, also show the MBps.
The reason for this is because of how S.B. is accounting for the data and overhead of all the packets (which is counted for in actual bytes, not bits)
@daveposh is this AFTER you set the client IP as requested in the LAN NETWORKS setting?
If so do me a favor and stop/start the server (after the change).
We want to try and eliminate variables so PLEASE ONLY use a file that will direct play. We don’t want any transcoding getting in the way of this testing.
If you don’t mind please post the exact IP/subnet you entered in the LAN NETWORK setting. Feel free to randomize the IP numbers so an IP of 1.2.3.4 could be posted as 3.1.2.4 or similar and show me the complete line you used. We just want to verify the input is correct. If you feel more comfortable just PM that line to me.
Carlo
I’ve now tested the LAN NETWORK settings with a few additional clients using 1.5 server on windows and I’m getting good consistent results.
Would love to hear other’s experience as well!
Carlo
It’s great to see some heavy hitters getting involved with this issue to try & get it resolved for us, but there’s a part of me that thinks it kind of sucks that us lowly users are having to do all the donkey work to prove there’s a problem.
@“Stewie Griffin” said:
It’s great to see some heavy hitters getting involved with this issue to try & get it resolved for us, but there’s a part of me that thinks it kind of sucks that us lowly users are having to do all the donkey work to prove there’s a problem.
You may feel like you’re doing the ‘donkey work’. It’s impossible to have all the different combinations of media and media connections a ‘user base’ does. What you don’t see the work I do after the work here is done to actually get it completed.
I fully replicate the issue, collect all the user-supplied documentation, cut out all those important pieces which are directly applicable, and document the finite steps-to-reproduce. After I prove to myself that works, I then give it to the team. (Think transaction-based processing). I’m writing the transaction ‘ticket’.
I’m sure you’ve seen how I follow this stuff through too?
Yea I understand what you’re saying and I’m really surprised this and a couple of related bugs made it past the DEVs and QA team in the first place. It should not have been out there this long regardless. but that’s just me. 
Besides just this issue ChuckPA and I have documented a couple of other issues as well that I haven’t seen pop up in the forums. Some issues having to do with wrong reported user and device for example in the Now Playing and similar.
Hey @ChuckPA don’t get me wrong, I’m including you in the people that are doing the donkey work here.
I know you work very hard to help us out and I truly appreciate it, as far as I understand you are volunteering to do so.
