This one is interesting and I can’t believe I haven’t seen anyone else complaining about it in forums yet.
I am currently running v 1.3.3.3148 which does not exhibit the issue. I’ve tested the issue happens with v1.4.1.3362 and v1.4.2.3400 and I’ve tested with both Apple TV and Plex Web Player. Remote clients appear to have some type of bandwidth limit to download media.
I’ll try to explain what I visually see: I am looking at a bandwidth chart on my MikroTik router for egress bits as I don’t see any different in the logging of the content. I can upgrade and downgrade my server version and see the immediate change in behavior so I know it isn’t an issue with my egress or download speed of the remote client or the file being played.
On v1.3.3.3148: When a remote client begins to download using video/audio transcoding I see my server immediately generates a bunch of .ts segments in the transcode directory and the end user begins downloading pretty much as fast as they can for the first X segments until the initial buffer is full. This usually takes 2-3 seconds and they begin playback. Then every 10 seconds I see the end user download the next .ts chunk which downloads at a very high speed and the connection to them looks very spiky as they download chunks for the remainder of the video. Usually no buffering or issues are seen.
On v1.4.1.3362 or 1.4.2.3400 When a remote client begins to download using video/audio transcoding I see my server immediately generates a bunch of .ts segments in the transcode directory and the end user begins downloading only this time I immediately see a flattop on the egress to the end user. It takes usually 10+ seconds before they see any initial playback and because the bandwidth is sitting around ~2Mbps they start buffering when trying to stream a 4Mbps stream after ~15 seconds because they cannot keep up. If they drop their bitrate on the stream to ~2Mbps they get a better experience but its still right on the edge of what appears to be an artificial throttle of ~2Mpbs.
As soon as a downgrade to v1.3.3.3148 they resume from where they started and it works flawlessly. I upgraded and downgraded 3-4 times to be certain and like I mentioned I tested with the end user on AppleTV and Plex Web Player in their browser. Similar behaviors across all version as mentioned above.
How has no one else complained about this or did I just not see the thread when looking?
Plex Admins: what was the fundamental change between these versions that makes such a massive change? The only thing I could find in release notes is possibly this(all files have been MKV so far - tried 4-5 different files as well) but I don’t think so:
It sounds like they are connecting via Plex Relay instead of a direct connection to your server. I have seen several times my server says it is not reachable outside since the 1.4.x releases came out. It seems a little better now, but also AWS had some issues (don’t know if it would have affected Plex though) last night that may have contributed.
Do you know an easy way to check if an end user is connected via relay or not or is that all on my server side showing public availability? Also my server is located at my home with no interaction with S3 so their outage shouldn’t have impacted.
This would mean also that they changed some code to their networking setup since I’m obviously not changing my network or port settings when upgrading.
I’ll check my connection status under network after an update tonight and report back. Still odd that others are not seeing this same thing.
I upgraded to v1.4.2 and then moved the binary file for Plex Relay on my server after update to a different location. After doing that the same impact as stated before. Remote user can hardly stream at all and bandwidth looks capped. I downgraded back to v1.3.3 and it works flawlessly. I also moved the Plex Relay application after downgrading and it still works perfectly.
I believe this rules out Plex Relay as the issue.
Anyone else care to help out or share similar issues with any version after v1.3.3?
I upgraded my 1.3.3 to 1.4.3 this week and my TV at home keeps disconnecting every couple of minutes (server is semi-remote, connected through point-to-point VPN).
Reverted back to 1.3.3 and it seems to be OK. I’ll wait and see.
On a separate note, it really pisses me off that I feel like I am being a beta-tester for everything, from Plex to iOS.
Is it this difficult to release software that WORKS as expected?
All I want is to sit down and use it, not keep fooling around while the whole family waits to watch a movie.
Get your stuff together, gentlemen!
Had the same issue. I was setting up a new plex server and put the plexpass release, I wanna say 1.4.2 - and it was unusable. Constant buffering. Downgraded to 1.3.3 and it’s been solid everywhere on all platforms.
Anyone from plex dev wanna help make a comment on a “known bug” or something that we can trust will be fixed in the future? I’d rather not upgrade if you know something is broken and it would be awesome if you were open with the users about what is going on.
Latest 1.4, bandwidth from pfsense shows 1.5MB/s and having issues streaming longer than 3minutes on shows that have never had trouble before. Constant buffering.
Downgrade to 1.3.4, pfsense shows 6MB/s spikes like normal and everything streams normal. Maybe related to the client bandwidth limit?
The client isn’t changing tho - upgrading and downgrading the server is what impacts it. How is it that Plex dev isn’t coming out and informing us on what is going on?
I encountered it first when I updated my PMS through the plexpass update channel during February. Switched to public channel to rollback to last public and the issue disappeared. I though this was just an unstable release and didn’t report it. I have it again since I updated to last public available version.
Well the 1.5.2 came out today for plex pass members and with something looking like a fix for this issue :
(Network) Slower than expected streaming over fast connections with high latency. (#6548)
I will give it a shot to see if I don’t need to rollback to a previous version.
I also just tested and confirmed this fixed my issue. My test environment was a single client playing the same video and upgrading from one version to the next. Green qualifies streaming and red qualifies endless buffering or no video start