Both clients and server are both exceeding >100mbit/sec download and upload, but are in different countries. I usually can’t go above 8-10mbit/sec without buffering every minute. Everything is connected via. Ethernet
I’m guessing this is down to latency? Locally I can stream direct play at 10-30 mbit/sec, which I am assuming is 1ms or less, where the latency between the two countries is roughly 50ms.
Do the math.
At 30 Mbps (Audio + Video combined), you must deliver roughly 33 Mbps to the player of raw data.
At 8 bits/byte, that’s 4.125 MB.sec which translates to 1 MB every 242 ms.
Round trip delay time plays an important role.
If you have a high RTT, transcoded and Direct Streamed playbacks in Plex are usually laggy to unusable.
'Direct Play’ed playbacks are usually much less affected.
That is the main reason why commercial ‘video suppliers’ like netflix, hulu, youtube etc all have several/many datacenters placed geographically around the world, so the RTT never gets too high.
Thanks for taking the time to answer.
So in theory, when I am experiencing stutter/buffering over longer distances/higher pings, would I benefit from increasing ‘Transcoder default throttle buffer’ and pausing to let the transcoder work a little longer?
Depending on the client used, you can have more problems with low latency then with high latency 
Check out support.microsoft.com/en-us/kb/2675785
@tommehnet said:
So in theory, when I am experiencing stutter/buffering over longer distances/higher pings, would I benefit from increasing ‘Transcoder default throttle buffer’ and pausing to let the transcoder work a little longer?
No. This won’t help much.
You are welcome to conduct some testing yourself though.
Only change these parameters in 50% increments of their original value and perform extensive testing with different files and bitrates inbetween.
@razvan.constantin said:
Depending on the client used, you can have more problems with low latency then with high latency
Check out support.microsoft.com/en-us/kb/2675785
That is not a true statement in general. That affected specific operating systems due to programming bugs not networking conditions in general. Code is only as good as the developers behind it. Besides MS put out a hotfix for that to fix it. 
High latency is a killer in real-time environments.
Wouldn’t a ‘Transcoder default throttle buffer’ time to 50% of most movies effectively force the transcoder to work non-stop, producing a temporary ‘Direct Play’ environment?
@tommehnet said:
Wouldn’t a ‘Transcoder default throttle buffer’ time to 50% of most movies effectively force the transcoder to work non-stop, producing a temporary ‘Direct Play’ environment?
No, it won’t.
The video file will still be chopped into small chunks which each has to be transported to the client individually.
With Direct Play however this ‘chopping up’ won’t happen.
Can the Plex client be configured to preload all the available/ready chunks ahead of time, to mimic buffering?
has no idea on the technical workings, so just going by layman’s terms
@tommehnet said:
Can the Plex client be configured to preload all the available/ready chunks ahead of time, to mimic buffering?
It cannot. This would then also be no more ‘streaming’, but ‘downloading’.
That being said; the Plex client with the biggest download buffer is Plex Media Player.
You can increase its size to max 500MB. (only when running on a PC type device - not a Raspberry Pi)
@cayars said:
@razvan.constantin said:
Depending on the client used, you can have more problems with low latency then with high latency
Check out support.microsoft.com/en-us/kb/2675785That is not a true statement in general. That affected specific operating systems due to programming bugs not networking conditions in general. Code is only as good as the developers behind it. Besides MS put out a hotfix for that to fix it.
High latency is a killer in real-time environments.
I have no idea what are you talking about
If you read the KB page you would have seen it only refers to W7 and W8 server.
I never said anything “in general”. That is why I started with “Depending”
Because it’s not true “Depending on the client used, you can have more problems with low latency then with high latency” unless of course you run 7+ year old operating with a patch that breaks some network functionality but then also fail to install the fix for the bad code. What you posted is an anomaly.
Indeed. I see you have no idea about what I am talking about or what the KB does.
The KB in question does not appear in Windows Update. Not even as an optional update.
On top of that you need to request it by email from MS.
All Windows 7 and Windows 2008 R2 server editions exhibit this behavior without the patch.
For your information, that +7 year old operating system is still the dominant version on the market. 48.5 % to be precise.
https://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0
I really don’t want to argue the point. It was/is fixed and isn’t a problem. MS puts out some hotfixes that are only available by request or special download for those with a specific issue. Otherwise the fix is combined with many other fixes as part of a normal update rollout. This was the case with this. It even says so if you read it. This problem only happened in extreme conditions with certain networking equipment. The large majority of users would never experience the issue because TCP window scaling worked correctly.
“This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.”
No you will not see this specific hotfix listed in your updates list nor the other 5000+ hotfixes that MS has released. It doesn’t work that way. All the small fixes get reworked and are released as bigger updates.
This hotfix has always been available for direct download and IS STILL available for direct download (but probably shouldn’t be). Go back to the link you provided open the page and look at the big blue button up top that says “Hotfix Download Available” and click it. On the next page you are given two ways to get the fix: 1 download it, 2 have it emailed to you.
So just to make sure everyone is on the same page. If you run normal windows updates as recommended then forget anything you read about this as it’s been fixed years ago and doesn’t apply to you. If you just installed a fresh version copy of Windows 7 or Windows 2008 then apply all updates and then forget about this.
Carlo
