Also to improve the experience try to ensure as much content can direct play as possible.
Forgive me… I’m going to unwind us to be the beginning and walk through diagnosis again. Something must have been missed / I assumed something which is not true.
Please confirm with me as we step through.
I will assume you’re using Plex/Web (in your browser), your Plex/web Player settings are like mine shown below. If your browser supports AC3 playback, you can enable that checkbox. Your Remote quality should be Original.
Next, Please copy/paste the media info of the file you’re actually trying to play. Let’s see how well it lines up with your Plex/Web settings and whether or not full transcoding is going to be required or if Direct Play / Direct Stream will be the case.
@brendonwadey said:
Also, if I am able to download from Plex on the server at above 3MB/s, then why when I set a file to 2Mbps for testing, it still had the issue?
see my explanation above.
If you set a bandwidth limit, the server starts to transcode, to comply with the bitrate limit.
If transcoding happens, the video doesn’t arrive in one contiguous data stream but in many small files, which are all transferred independently. Much differently from a regular download.
The speedtest only tests with very few bigger files, not very many small files.
That is the main difference, and that is where geographical distance gets important, because with a longer line, the ping time (or ‘Roundtrip time’) inevitably goes up.
A plex server on the opposite side of the world is not a good idea.
Just thought of another piece of info.
traceroute to your server…
VERY interested in the latency and ping times along the way
While you’re at it, Please get a fresh set of logs. zip them up and attach here. I’ve got some ‘high powered’ help to figure this out.
@ChuckPa said:
Forgive me… I’m going to unwind us to be the beginning and walk through diagnosis again. Something must have been missed / I assumed something which is not true.Please confirm with me as we step through.
I will assume you’re using Plex/Web (in your browser), your Plex/web Player settings are like mine shown below. If your browser supports AC3 playback, you can enable that checkbox. Your Remote quality should be
Original.Next, Please copy/paste the media info of the file you’re actually trying to play. Let’s see how well it lines up with your Plex/Web settings and whether or not full transcoding is going to be required or if Direct Play / Direct Stream will be the case.
Yes mine looks like that. I have turned off Direct Play & Stream, but turned it back on. Didn’t seem to make a difference either way. Remember though, those settings are for Plex Web only, I do have people using Chromecast and iOS/Android as well, which they are all different.
I can tell you right now, most of my files require transcoding. They are all MKV h264 files. Very few do not require it. I can get you that media info if you want, I haven’t been testing the same files, different ones.
As for the Traceroute (please tell me if I should remove my servers IP from the forum, was not sure if that is a bad idea or not)
1 <1 ms <1 ms <1 ms 192.168.1.1 2 * * * Request timed out. 3 30 ms 13 ms 18 ms van58-6-240-149.dynamic.rogerstelecom.net [209.148.240.149] 4 24 ms 30 ms 125 ms van58-9-231-69.dynamic.rogerstelecom.net [209.148.231.69] 5 21 ms 22 ms 21 ms van58-9-229-229.dynamic.rogerstelecom.net [209.148.229.229] 6 40 ms 47 ms 41 ms van58-9-230-134.dynamic.rogerstelecom.net [209.148.230.134] 7 * * * Request timed out. 8 45 ms 40 ms 44 ms be2766.ccr42.ord01.atlas.cogentco.com [154.54.46.177] 9 48 ms 45 ms 46 ms be2718.ccr22.cle04.atlas.cogentco.com [154.54.7.130] 10 58 ms 66 ms 62 ms be2879.ccr22.alb02.atlas.cogentco.com [154.54.29.174] 11 63 ms 76 ms 70 ms be2302.ccr22.bos01.atlas.cogentco.com [154.54.43.13] 12 126 ms 128 ms 125 ms be2983.ccr42.lon13.atlas.cogentco.com [154.54.1.177] 13 145 ms 141 ms 137 ms be12488.ccr42.ams03.atlas.cogentco.com [130.117.51.42] 14 146 ms 166 ms 145 ms be2814.ccr42.fra03.atlas.cogentco.com [130.117.0.142] 15 165 ms 166 ms 165 ms be2960.ccr22.muc03.atlas.cogentco.com [154.54.36.254] 16 154 ms 152 ms 153 ms be2270.rcr21.nue01.atlas.cogentco.com [154.54.37.217] 17 153 ms 153 ms 154 ms te0-0-2-3.nr11.b040138-0.nue01.atlas.cogentco.com [154.25.2.118] 18 152 ms 151 ms 156 ms 149.6.158.22 19 163 ms 166 ms 266 ms core12.hetzner.de [213.239.245.25] 20 154 ms 165 ms 153 ms core22.hetzner.de [213.239.245.213] 21 155 ms 156 ms 154 ms juniper4.rz16.hetzner.de [213.239.245.146] 22 157 ms 158 ms 156 ms hos-tr4.ex3k26.rz16.hetzner.de [213.239.233.110] 23 155 ms 291 ms 157 ms static.87.118.9.5.clients.your-server.de [5.9.118.87]
I’m not entirely sure how to get the logs. One I’m not sure where they are on the Linux version of Plex, and not sure how to download them. I haven’t got wget to work yet, because I think it requires a webserver to be installed on the server, and well that is not something I want.
@OttoKerner said:
@brendonwadey said:
Also, if I am able to download from Plex on the server at above 3MB/s, then why when I set a file to 2Mbps for testing, it still had the issue?see my explanation above.
If you set a bandwidth limit, the server starts to transcode, to comply with the bitrate limit.
If transcoding happens, the video doesn’t arrive in one contiguous data stream but in many small files, which are all transferred independently. Much differently from a regular download.
The speedtest only tests with very few bigger files, not very many small files.
That is the main difference, and that is where geographical distance gets important, because with a longer line, the ping time (or ‘Roundtrip time’) inevitably goes up.
A plex server on the opposite side of the world is not a good idea.
Yea I was told this before I got the server, but wanted to try. The issue is if I get a server located near me, it’s like 10x the price sadly. Though I think because of how Plex works is why it’s almost working for me. I feel like it’s possible to get it work smoothly, even at a lower quality if needed.
Thanks for the details though.
@brendonwadey said:
I feel like it’s possible to get it work smoothly, even at a lower quality if needed.
Well, conduct an experiment:
Make yourself an ‘optimized for mobile’ version of one of your movies.
Then stream this by explicitly selecting it for playback. (Make sure to adjust the bitrate limit in the client to 4mbps or higher)
If you can’t use the Plex Optimizer, because PMS is not allowed to write to your media storage, make a custom version yourself with Handbrake.
Ensure it is in MP4 format and the file is ‘Optimized for streaming’.
This should now Direct Play, thus the issue with the bigger roundtrip delay won’t be that important.
Is there a difference in behaviour?
The optimized for mobile file played without issue for 50 minutes, until I didn’t feel like watching any longer. Before, the longest I got before issues was about 20 minutes.
Though I swear, last night I tried setting one of my files to 2Mbps, and it made no difference, this optimized version is 4Mbps. So your whole thought is, if it needs to transcode, its causing the issue, but you said
“If transcoding happens, the video doesn’t arrive in one contiguous data stream but in many small files, which are all transferred independently.”
Which to me sounds like, that would be better for a smooth stream.
@brendonwadey said:
“If transcoding happens, the video doesn’t arrive in one contiguous data stream but in many small files, which are all transferred independently.”
Which to me sounds like, that would be better for a smooth stream.
No, the opposite. The test showed this.
The optimized file played in Direct Play mode. This is streamed as one, big “download”. That’s why it worked so well.
If the Plex server is transcoding “live” (i.e. when you restrict the bitrate), then the transmission is not in one piece but in lots of small data chunks. This is a problem with a long line.
For optimum playback you must either Optimize your whole library, and then always only play the optimzed versions
or
Pre-Optimize your files at home (for instance with Cayars’ conversion scripts) and upload only those pre-converted versions to your server.
That is very interesting to me. As to me, it makes sense that a smaller file in peices should have an easier time over distance or at all. I guess I should go learn about how the internet actually works. Thanks for the help.
Optimizing my collection, either way isn’t very viable sadly. So I’m out of luck. It’s been an interesting and useful experience though, that is for sure. Setting up this server, trying to get it to work, learning this now…very cool.
Still wait to see if @ChuckPa has anything to add though.
See last night I watched two videos that were around 4Mbps, but they were fully transcoding. No issues.
I just don’t get the problem.
@brendonwadey said:
See last night I watched two videos that were around 4Mbps, but they were fully transcoding. No issues.I just don’t get the problem.
The internet has a rush hour too. With less traffic, the roundtrip time delay is shorter - then it works.
But if you try the same at a different time, it may be just that tiny bit slower so you experience buffering.
You know, your ISP only guarantees you the speed from your house to the internal network of your ISP. But then the data must travel over other networks which belong to other operators. All the backbone internet lines in the world don’t provide enough capacity so that every domestic internet line can stream at its full nominal capacity 24/7.
There will be always congestion. And ISPs always lie when it comes to the actually usable bandwidth of their connections. Always.
