That means it had to analyze the file first before actually playing it. The analyze would only kick 1 worker up and that wouldn’t change until playback started.
Not sure if that helps or not, but those are my settings and I never get a stutter or buffer. Start time is probably anywhere from 1-5 seconds majority of the time as I keep everything analyzed and my only difference is that plexdrive definitely started almost always in 1-seconds at most.
Once playback starts for me, I notice no difference in rclone or plexdrive.
I was actually going to ask if your Plex server was on a local machine. I think that Rclone cache is not working with high bitrate material when using a VPS.
Rclone cache on my local server works perfectly with 30 - 40 Mbit material.
I’m a dedicated machine in my basement on gigabit Verizon FIOS running a tel® Core™ i7-7700 CPU @ 3.60GHz with 32GB of memory. It does it all. rTorrent/Sonarr/Radarr/Plex/Ombi/NBZGet/etc.
I never had a problem streaming from a straight rclone mount, but the problem lies in if you don’t use the cache, you’ll most likely snag a ban. You could do a mount for a specific folder/show and test that and see how it works, but I would be mindful as for me, if I lose my GD, I have an unhappy family
No sorry. I meant using a flag on the cache mount to limit functions that don’t need to be used and could be contributing to poor VPS network performance like the caching of played back material.
Not sure if that or other things could be turned off to try and improve things.
I spun up a new test VPS at another provider. Using Rclone Cache it’s streaming 30+Mbit media files with no problems. Smooth playback, 6-7 second starts.
Nice to see Rlcone Cache working the way it should on a VPS.
This test VPS has significantly lower specs than my SSDnodes VPS but its handling it like a champ. I don’t know whats happening with the SSDnodes VPS. Their tech support made adjustments like switching from intel1000 to VirtIO network adapters but it didn’t make a difference to streaming quality.
In my testing. ChicagoVPS would pull stuff down from Usenet at 70-80MB/s, SSDNode 30-40MB/s, but on the rclone to google drive copy feature, ChicagoVPS would do often times me 1-2MB/s and SSDNodes would be 12-15MB/s. I thought in the end this is all just TLS traffic. Who really knows what type of bandwidth shaping might be going on.
I look after engineering at SSD Nodes and deal with Level 3 support tickets. I am the ‘Daniel’ quoted by @mjmayer in the support ticket response above.
We have become aware that at least two of our customers have questions about the performance of Plex within their VPSes hosted on our service. I can see from this thread that sometimes there can be some confusion about what is going on ‘under the hood’ at a VPS provider. So I thought that I would join this discussion so we can answer your questions directly and, hopefully, help figure things out faster.
I was concerned that @jasanson was streaming content from a VPS located in Dallas up into Canada. So I have just set up a test server in our Montreal data center which will have a much better network path. We will see how that test goes.
We are not currently accepting new orders for the Montreal data center because we considered that we were full in that location. The “full” server that @jasanson’s test VM is on currently has 40% idle CPU (of 72 2.8GHz cores), 30% of 1TB RAM available and is only using 20% of 10Gbps network bandwidth. I don’t think those stats support the suggestion, earlier in this threat, that we ‘oversell’ our servers.
Please let me know if there is anything I can do to help our customers look into these Plex issues.
@jasanson’s network performance improved once we changed the network card from an emulated Intel e1000 to virtio. (Our new VMs are deployed with virtio NICs and we are steadily upgrading the older VMs).
Please note that using speedtest without manually selecting the correct server will often give inaccurate results. Server 11207 is located in Dallas, as is the VM under test.
@jasanson’s test server in Montreal has been set up. The speedtest results from that VPS are:
CPU usage is a very common problem when customers run Plex in a VPS where CPU capacity is shared (as it is on our service, like most VPS providers).
Transcoding consumes a lot of CPU and if you are going to watch a movie that CPU will be used for a long period of time. If your VPS plan has shared rather than dedicated cores (i.e. most of them) then you don’t get to use all your cores all the time. This is a common misconception. You can burst your CPU usage to use 100% of all of your cores for a short period but on a non-dedicated plan you can’t do that constantly.
If you need to transcode movies or stream to a lot of people then you need a VPS with dedicated cores or a dedicated server. The pricing would change accordingly, of course.
I’ve been digging through the Plex Logs and I’m seeing a good amount errors that seem to correspond with stuttering playback
Apr 14, 2018 08:41:39.490 [0x7f782c7fa700] ERROR - Throttle: timed out trying to read chunk 8
Apr 14, 2018 08:49:44.313 [0x7f782c7fa700] ERROR - Throttle: timed out trying to read chunk 87
Apr 14, 2018 08:52:43.056 [0x7f783afff700] ERROR - Throttle: timed out trying to read chunk 1
Apr 14, 2018 08:57:20.035 [0x7f7833fff700] ERROR - Throttle: timed out trying to read chunk 23
Apr 14, 2018 08:57:31.386 [0x7f783afff700] ERROR - Throttle: timed out trying to read chunk 26
Apr 14, 2018 08:57:51.032 [0x7f7828bfd700] ERROR - Throttle: timed out trying to read chunk 26
Apr 14, 2018 08:58:32.705 [0x7f783afff700] ERROR - Throttle: timed out trying to read chunk 1
Theses errors are related to the movie data not being available for the plex transcoder. Determining which link in the chain is the culprit is hard. There is the google drive api, rclone, docker, fuse, plex, network contention, and CPU contention. I’ll keep poking as time allows.
It seems that Library Scanning within plex can have a negative impact on playback. Which is probably why rclone implemented the plex integration. Which I have had disabled for several weeks.
I setup the new test Plex server at the SSDnodes Montreal location.
The install on the VPS was as minimal as possible and I’m only using Rclone Cache. The mount is of an encrypted and then decrypted GoogleDrive remote.
The results for playing media are significantly better than from my server at the Dallas location.
Play starts in 5 to 7 seconds and is smooth and without pauses, freezes or other buffer related network issues. Scanning forward works fine and as good as can be expected
Playing two directplay 25Mbit media files at the same time -no problems
Playing a single directplay 40Mbit file - no problems
I don’t know if this is working so much better because of differences in network peering or due to differences in the node. How would we figure that out?
Likely peering differences, I run on a 2vCPU VPS with 2GB RAM and a 100mbit connection but it’s OVH hosted in france (I’m in the uk).
Seems OVHs peering to google datacentres is good as it’s nearly always at the max 100mbit both reading and writing.
Glad to hear you got an improvement though! Virtio over emulated intel is super handy for overheard, I had a lot of softirq use when not using virtio network interfaces.
@jasanson is the test server continuing to perform as expected?
I’m continuing to see issues where movies won’t start streaming or stutter. Then I looked at the network traffic and it seems like rclone isn’t pulling anything down. Restarting services (rclone, plex) seem to temporarily resolve the issues.
