@emreunal said:
For the records, i had exact the same problems with 1.4.x on Centos 7(1Gbps Dedi Server). Streaming/Downloading from 1.4.x was a pain.
I have disabled Remote Access, created a domain for plex, created SSL Cert with Lets Encrypt for this domain and edited vhost Settings of this domain for Apache Reverse Proxying. My server settings for Custom server access URLs are now “https://mydomain.com:443 (for secure connections)” and “http://mydomain.com:80 (for insecure connections)”. voila!!! I can use now my plex server on all my devices(firetv, appletv4, pmp,iphone and web browser) without any throttle-connection problem.
The only problem was Plex App on my PS4 because the software giant(!) Sony dont trust Lets Encrypts Root Certificate. So, (on ps4) settings > allow insecure connections and ps4 app is using now http://mydomain.com:80 instead of https://mydomain.com:443 to reach the server.
Which problem are you addressing please?
Remote Accessibility or Speed? To me, it looks like you’re on the other problem (Remote Access)?
@emreunal said:
For the records, i had exact the same problems with 1.4.x on Centos 7(1Gbps Dedi Server). Streaming/Downloading from 1.4.x was a pain.
I have disabled Remote Access, created a domain for plex, created SSL Cert with Lets Encrypt for this domain and edited vhost Settings of this domain for Apache Reverse Proxying. My server settings for Custom server access URLs are now “https://mydomain.com:443 (for secure connections)” and “http://mydomain.com:80 (for insecure connections)”. voila!!! I can use now my plex server on all my devices(firetv, appletv4, pmp,iphone and web browser) without any throttle-connection problem.
The only problem was Plex App on my PS4 because the software giant(!) Sony dont trust Lets Encrypts Root Certificate. So, (on ps4) settings > allow insecure connections and ps4 app is using now http://mydomain.com:80 instead of https://mydomain.com:443 to reach the server.
Which problem are you addressing please?
Remote Accessibility or Speed? To me, it looks like you’re on the other problem (Remote Access)?
Speed. I had no problem with Remote Accessibility.
Then help me please? How does proxy / your own domain settings help? By having the reverse proxy put all “local vs remote” security requirements on your shoulders?
I ask because how can certs and your own domains change PMS core delivery speed if it’s not connectivity related?
Spoke with @cayars on the phone earlier. We confirmed the issue on his server as well. He will be posting logs shortly. Something definitely changed after 1.3.4, maybe unintentionally. But there’s a drastic speed difference in remote streams and it’s easily producible
@ChuckPA said:
Then help me please? How does proxy / your own domain settings help? By having the reverse proxy put all “local vs remote” security requirements on your shoulders?
I ask because how can certs and your own domains change PMS core delivery speed if it’s not connectivity related?
Where’s the 1:1 correlation?
I tried with apache proxy non ssl with open vpn same issue. Also setup a load balancer in pfsense same thing.
I just want to throw out that I am also have a similar issue:
OS: Ubuntu 16.04.02 LTS
Link Speed: 1gbps dedicated.
Plex Server: 1.5.0.
All files that have been encoded to direct play, which they do, but similarly at a high bit rate, I can see the network speed being throttled to around 10mbps, which makes playing most of my files (20mbps ripped blu-rays) impossible.
Just like everyone else, last perfectly working version of Plex Media Server was 1.3.4.
Roku 4 issues with delayed transcoding. Similar issues especially when watching a remote stream. Local even acts up but not nearly as noticable because of LAN speeds. I’ve included my issues as the generally revolve around the remote streams, but I really wanted to show that there is an issue after version 1.3.4.
Setup is as follows.
PMS: Win7 64 version 1.5.0
AMD 1100T
16gb ram
on fiber gigabit internet WLAN and wired gigabit LAN between all clients and PMS
remote IPTV example:
My m3u playlist plays quickly in all clients except the Roku 4 and Roku 3. This is a subscription based iptv playlist with an upload of 5-10mb/s as the source.
When starting in plex web either at the server locally, within the LAN or remotely from work the playlist is flawless and starts quickly. Also no issues on any iOS iphone or Ipad
The Roku 4 for instance loads list fine, but upon playback forces transcoding whether Direct Play or Direct streaming is enabled, or whether “Optimized for streaming - switching this off might force PMS to transcode everything even when Direct Play and Direct Stream options are unavailable” is enabled or not.
Sometimes it will convert the AAC and H264 stream and other times it will show the same channel link as copy AAC and copy H264. HLS transcoding seems to be slightly quicker to the Roku 4. The question I am asking specifically is there any way i can check the roku logs to look specifically what is causing the start up delay (sometimes up to 90 secs or more)? For those familiar with the Roku remote one thing that will speed up the initial delay is upon the individual iptv channel link loading after hitting play is to press the “*” button to bring up the settings page, then quickly again pressing *. This reduces the transcoding delay to roughly 15 secs. If someone can point me in the direction for which logs to look at (roku, PMS and the IPTV plugin)
I’d like to resolve as this is our main provider of entertainment for 2 screaming kids.
This issue is resolved by going back to PMS version 1.3.4.3285
@ChuckPA
mixolyd and I talked on the phone this afternoon and did a few tests. I’m in NJ and he in OR.
During part of our testing I set him up on my server and was TeamViewed into his desktop as well to watch network speeds.
On My side I ran different server versions from 1.2.0 through 1.5.0 including the latest Hardware beta. My Server is Windows 2016 Server and of course windows version of Plex.
Files played back are direct playable or AAC audio first track, h.264 all ran through my scripts per usual. Test were done via Chrome with Network Bandwidth monitoring.
It’s very easy to see a clear change from 1.3 to 1.4 code base. On the client side you could easily guess what server version is used (below 1.4 or above) just by watching the first second or two of the direct play stream. On older versions of the server you would see the network spike high as the buffer is built even before the movie starts to play. On anything 1.4 or higher the network bandwidth wouldn’t go over 1.8MB or so even when starting to load the movie.
Of course the older versions would play anything we through at it that was direct playable while the 1.4 and higher server versions would stutter with higher bitrate files.
Nothing stands out in the logs.
This is VERY EASY to reproduce and the devs should be able to find the problem quite easily. Fixing it on the other hand might be different. This seems to jive with the introduction of new brain functions. Me thinks it might be “drain bamaged”. LOL
A couple of things I wonder about. How would speed be with newer versions if:
A: user direct connects to server directly by IP address instead of going through Plex.tv (didn’t think about this till now).
B: if A is still slow, then what if direct connects remotely through VPN ran on server side (private VPN not public VPN service). Thus the remote computer would get a local IP in the same subnet as the Plex Server
C: Use of NGINX or similar REVERSE PROXY server on server side so Plex Server sees a local IP.
Not sure any of those tests are needed but could help to diagnose how/when the problem happens.
Carlo
PS If any Plex employee wants to do some tests with me against my server to see this happen just PM and we can easily arrange this. Also I can give PlexPy access so you/we can view logs real time while testing as well as clear gather logs. What ever it takes including remote access!
@cayars said: @ChuckPA
mixolyd and I talked on the phone this afternoon and did a few tests. I’m in NJ and he in OR.
During part of our testing a set him up on my server and was TeamViewed into his desktop as well to watch network speeds.
On My side I ran different server versions from 1.2.0 through 1.5.0 including the latest Hardware beta. My Server is Windows 2016 Server and of course windows version of Plex.
Files played back are direct playable or AAC audio first track, h.264 all ran through my scripts per usual. Test were done via Chrome with Network Bandwidth monitoring.
It’s very easy to see a clear change from 1.3 to 1.4 code base. On the client side you could easily guess what server version is used (below 1.4 or above) just by watching the first second or two of the direct play stream. On older versions of the server you would see the network spike high as the buffer is built even before the movie starts to play. On anything 1.4 or higher the network bandwidth wouldn’t go over 1.8MB or so even when starting to load the movie.
Of course the older versions would play anything we through at it that was direct playable while the 1.4 and higher server versions would stutter with higher bitrate files.
Nothing stands out in the logs.
This is VERY EASY to reproduce and the devs should be able to find the problem quite easily. Fixing it on the other hand might be different. This seems to jive with the introduction of new brain functions. Me thinks it might be “drain bamaged”. LOL
A couple of things I wonder about. How would speed be with newer versions if:
A: user direct connects to server directly by IP address instead of going through Plex.tv (didn’t think about this till now).
B: if A is still slow, then what if direct connects remotely through VPN ran on server side (private VPN not public VPN service). Thus the remote computer would get a local IP in the same subnet as the Plex Server
C: Use of NGINX or similar REVERSE PROXY server on server side so Plex Server sees a local IP.
Not sure any of those tests are needed but could help to diagnose how/when the problem happens.
Carlo
PS If any Plex employee wants to do some tests with me against my server to see this happen just PM and we can easily arrange this. Also I can give PlexPy access so you/we can view logs real time while testing as well as clear gather logs. What ever it takes including remote access!
Wow thanks Carlo. Sounds like you did some really amazing testing. I hope the Plex team can use your findings to help locate the problem!
Nothing really amazing about it. Just switch servers and replay while monitoring bandwidth usage. @mixolyd had the desktop setup with local bandwidth monitoring and he/we were testing against his remotely located server. We wanted to test some direct playable files with different bitrates and I knew I had some so one thing led to another and we switched to streaming from my server.
I had servers versions from 1.2 to 1.5 including the Hardware Beta so we tested with a variety of them. In all cases it was easy to spot a change between the 1.3 and 1.4 branches of code. NIGHT and DAY difference in the streaming bitrates. Anything from 1.4 and newer and it seemed like the “network card” was maxed out between 1.8MB & 2MB (throttled) where any lower version of the server software would jump way up to what ever the bitrate was. All files were direct played (verified) so transcoding was not involved in the testing.
Nothing special in the logs and it looked normal. The “only” problem is the client would stop playing to buffer and then start playing again on versions higher then server 1.4.
@cayars said:
A couple of things I wonder about. How would speed be with newer versions if:
A: user direct connects to server directly by IP address instead of going through Plex.tv (didn’t think about this till now).
B: if A is still slow, then what if direct connects remotely through VPN ran on server side (private VPN not public VPN service). Thus the remote computer would get a local IP in the same subnet as the Plex Server
C: Use of NGINX or similar REVERSE PROXY server on server side so Plex Server sees a local IP.
I can help with testing a remote connection vs nginx reverse proxy connection.
With an nginx reverse proxy, where Plex perceives the client to have a local IP, I get speeds of ~60MB/s.
I’ve been chatting directly with the Streaming Brain dev lead. He’d like us to construct a very clearly-defined and easily reproducible test case with everything, including client settings, documented. You know this will also mean log files (LognumFiles="10" or even “20” in Preferences.xml if we need it)
I see multiple sets of data coming from this. Therefore, it’s important to properly plan and agree on the steps
We need to document (with all playback conditions the same)
a) bitrate and format of the source material
b) demonstrate how fast it plays (PMS output rate) when streaming to a single local client
c) demonstrate how fast it plays (PMS output rate) when streaming to a single remote client
d) demonstrate how fast it plays (PMS output rate) when streaming to multiple remote clients
We can then show the interaction of changing only audio (DirectPlay -> DirectStream)
If ambitious, go to full transcode and demonstrate the problem seen where trancoding starves/stutters.
I am willing to jump in on this and help test as well. I cannot source material but do have 24 Mbps downlink.
I’m sure we can find a way to all get a vehicle to allow us group conversation?
We need to document (with all playback conditions the same)
a) bitrate and format of the source material
b) demonstrate how fast it plays (PMS output rate) when streaming to a single local client
c) demonstrate how fast it plays (PMS output rate) when streaming to a single remote client
d) demonstrate how fast it plays (PMS output rate) when streaming to multiple remote clients
We can then show the interaction of changing only audio (DirectPlay → DirectStream)
If ambitious, go to full transcode and demonstrate the problem seen where trancoding starves/stutters.
I am willing to jump in on this and help test as well. I cannot source material but do have 24 Mbps downlink.
I’m sure we can find a way to all get a vehicle to allow us group conversation?
If you like you can have a dev PM me and I’ll give them my phone number and we can test about anything they like in real time if it helps. I can provide remote into servers as well. Just thought I’d throw that out there. I’m got a fast upload so normal internet speeds won’t be a problem on my side. Same with you @ChuckPA if this will help (anyone from Plex).
This isn’t a transcode issue but just “streaming” or pushing files.
D above doesn’t have anything to do with it from what we’ve seen. It’s not a “combined” bandwidth issue but an individual stream issue. For example I could have 5 streams playing hi bitrate direct play files but none will go over 2MB. So the server could be streaming around 10Mb total. With 10 clients it would be close to 18 to 20Mb total but no client over 2Mb.
Local streams don’t seem to be affected but only remote streams connected as “remote” not “indirect” according to the browser.
Non of what I just mentioned means we can’t do a-d above, but just thought I’d try and clarify it seems to be remote and single connection “bug” regardless of how many streams. Each stream 1 or more is limited to 2Mb.
In a nutshell the server is acting as if the connection is indirect with a plex-pass account (2Mb limited).
I’m up for a group conversation and there are a bunch of “teleconference” tools available we could use. Video or no Video, doesn’t matter to me.
Basically, I’m up for anything that will help so count me in,
Carlo
@ChuckPA and I spent about 5 hours together on the phone doing testing of this problem. We used a file that will direct play and was safe for our purposes. We feel confident that we have reproduced the issue in this thread. We gathered both streaming and downloading performance metric and logs of each test.
We used my server as the “control” and ChuckPA’s as the desktop control using Chrome browser. We gathered logs from both the client and server side.
We tested going through plex.tv and directly to my server’s web using the “32400” port as well as through a VPN connection directly to my system.
I have sent logs and screenshots to ChuckPA for him dissect and reformulate to give to the dev team.
If I may add, now I will boil down and sort all the raw data into more meaningful (with data from logs) to show what has been observed.
I have limited time per day (in total) and other responsibilities. This will take me a bit. I will share how I summarize it before submitting to verify it represents observed behavior with all here?
@mixolyd we built on what you and I did the other day. But not only did we use multiple versions of server software we also tested both streaming and download speeds. Throw in VPN access to my network and you get the picture. We tested multiple things to help the devs…
We completely cleared all log files (deleted them) between server installs and individual tests, so each test run got it’s own set of logs/graphs with only ChuckPA accessing the server to stream or download. We ran through a bunch of different iterations to pre-test what we wanted to log to capture the info we were looking to capture/log.
On a personal note, ChuckPA is a really nice guy and wonderful to work with. You can tell he cares a great deal but I think that is apparent to all that have read this thread on the forum.
Thanks to all who have diagnosed this. It has affected me and was driving me crazy trying to figure out where the performance bottleneck was. Currently rolled back to 1.3.4 awaiting future resolution.
This seems to jive with the introduction of new brain functions. Me thinks it might be “drain bamaged”. LOL
This seems to jive with the introduction of new brain functions. Me thinks it might be “drain bamaged”. LOL
