HeyI have a 100mbps downstream and I'm trying to get a 4k movie to stream via plex. My testing movie bitrate is 49.9mbps so one would assume I could play it without much effort, however short buffering occurs every 3-4 seconds after playing. If I pause the movie for a 1-2 mins I can get about 5mins of playback before buffering starts again. I've scoured these forums for tips on cache settings but can't get much better performance. Here are my settings:
EDIT: I increased the chunk size to --cache-chunk-size=32M which slows the start time but seems to work much better. The traffic monitor shows the bandwidth getting much closer to my available downstream too, should I assume doubling this again to 64M would perform even better?:
I'd read that can cause API bans. If this isn't the case then it'd make my life much easier to remove the cache altogether, however my understanding is that the cache specifically helped with media streaming.
Regardless of a cache or non cache, if you don't have enough capacity to stream a higher bitrate movie/show due to a slow connection, nothing can fix that as you either have to limit in Plex to a lower bitrate or get a faster connection.
Kept buffering, loosing connection to the server you name it. It may have just been bad timing idk. Will keep playing around with it to see. The strange part is there were no additional load, network usage etc other than trying to play plex during that time.
i think it starts after is full i could be wrong with my speed its hard to tell load time just seems quicker when not using a large buffer just enough kinda thing note this is testing on a vm running on 4 threads and ssd and i think around 7GB of ram allocated to it i figure in small test environments are better for testing things and well just plain using them XD
upload on a rented server and enjoy at home with a vm.
Thats not the case for sure, however you could be right that there could be some delay because of it.
You can check it for yourself by monitoring ram rclone is usingm chabe bellow the acdcrypt: to match your mount ( so the proper pid may be grabbed if you are using multiple rclone mounts and/or copy/move/sync something at the same time
Not set your buffer to 1GB eg something you know it wont be filled instantly with your connection and you will see that movie will start playing way before buffer is filled. On my server in average i need around 4 to 5 minutes to copy 10G and I tested playout with 10G buffer and out of 5 tries the playout speed was exactly the same as with buffer set to 0 ( default is 16M )
Could we have an option to tweak that setting as it would solve the problems when ACD start delivering files with slow speed so we could use buffer to solve it. --buffer-size 1G --fuse-pass 500M the play back would start when rclone have at least X amount already buffered.
I saw a lot of people have problems that movies can start stuttering at buffering at beginning of the play and sometimes never recover so it would be preferable to wait 20, 30 seconds more and have continues playback.
the mount is runing on the vps not your local computer.
so the mount will download the entire file to the vps before plex can stream it.
this would test if the problem is between gdrive and the vps
drive-chunk-size does nothing on a mount, this is used for copy/move/sync commands. Value should be 32M,64M, or 128M depending on your ram, disk performance, and other factors. 64M should be plenty to hit max upload speeds. This is the only flag needed to control upload speeds (unless --bwlimit). The tps-limit flags that people think increases speed doesn't.
--vfs-cache-mode=minimal \ - don't need caching for plex, in the future cache mode improvements will happen, when that does, full will be recommended. do not use full now because it will download the file first before starting playback, which isn't what you want.
I am curious if this is like my issue. Instead of messing with the mount, set your client to not allow direct play and force it to direct stream. Not all clients will support this, you will have to check on Plex to verify it is not direct playing.
Direct stream does not transcode video and does not use the transcoder default throttle buffer. There can be partially transcoded direct streaming, but that occurs when the audio portion is transcoded. The video portion is simply copied unchanged into a compatible container and streamed to the client.
You aren't transcoding though. You are remuxing. The video and audio streams are being copied to the transcoder temp folder and then placed into a container compatible with your client. Direct streaming uses very little CPU (unlike transcoding), but it still needs a temporary place to put the video/audio streams while it remuxes.
So the first part of your statement is right as it's not being transcoded but is using the Plex Transcoder and the second part is just wrong for Direct Streaming as my logs/screenshots show. That's why I used "Transocder" and not "transcoding".
I have a VPS that i use for Plex and use Rclone to mount Google Drive to it and when i am trying to stream 4K (via direct play or direct stream) it gets so far then buffers forever until Plex calls it quits
Now the "plexlib" was more me testing, i tried to avoid using the cache entirely and just see what happened if i mounted the drive directly as read only and pointed my plex library to it. My theory was the cache just being another step in the chain slowing it down but it did not go to plan if anything made it worse
I did play around with the cache sizes and making cache directories and cache DB directories, using --fast-list, increasing the workers and a whole lot more but i feel like i am more tryagnosing than diagnosing at this point
as for resource utilization the CPU sits around 40% when playing media from rclone, Plex isn't doing anything at all but might jump to about 10% every so often. the network from Hetzner is not limited in terms of throughput. The average when playing media is about 180mbps download (maximum, it spikes a lot) and about 10mbps upload.
Now i have seen some improvement. It buffers however does try and start playing again (this is via direct play not direct stream). I am not hitting the buffering wall so to speak where Plex just gives up and tell me to go away
Direct Play means the file does not go through the transcoder so you are limited to buffers on your player only so you are very much limited to any latency between the player and the server. Increasing buffer-size may help for this but maybe not.
If you try Direct Stream, this does use the transcoder settings and just remuxes the container which has limited CPU overhead on it. You can adjust the plex transcoder settings to read ahead. If you use this and still get buffering, the problem is most likely from server to player and it isn't getting a consistent enough connection to play.
With my setup, I stream 4K without any issues but I am using a home server on a player I know is direct streaming on a network I have full control over that's gigabit with very good peering to my Google Drive on a hard wired 4K ATV.
As you toss in variables with wireless, VPSs and going from other providers, the game gets much harder to troubleshoot and you'll find it's tough to 'tune' your way out of network latency from a VPS provider.
generally the content that goes via direct stream is because the audio needs transcoding but i can toggle a setting on my TV's Plex app to allow the audio as i can support it with the sound system but my goal is get both working as not all devices i own have support for it
Latency is one part of the equation, but any packet loss would also come into play. For some perspective, I have a 8ms ping to my resolved Google Drive API endpoint. Are you suing a US Google Drive or a European one? Anything to reduce latency down would help.
I thought you removed the cache? It's more a juggling act based on your specific setup. I have my setup documented that works very well for my very specific use case and I try to share what works for me. The problem with any guides is that your setup is so different from mine, it makes it tough to say exactly what would work for you. Some folks have had great success with using the cache backend. Some folks have had great success using plexdrive instead of rclone. Use what works for you and if something doesn't work, you have to experiment a bit. I used plexdrive for ages because it worked better. rclone works better for me now so I use that.
This does nothing when you are direct playing though as it's not using the transcoder, which is why I suggested making a bigger --buffer-size as that may help out as that means rclone will read ahead and keep that much in memory. The problem still means the VPS has to talk to the plex player so if there's latency / packet loss from that connection, nothing will help as if the buffer empties on the player, you see the buffering message.
I had no idea you can choose a location for Google Drive so i don't know. I'd assume google are smart enough to notice i am UK based so would go for european but again, that's just an assumption. I have will 'have a google' and find out
Testing with the transcoder for direct stream i had that setting at 120 and i hit my so called buffering wall where Plex just gives up, i will have another play around with it again just for due diligence
I will increase the chunk size to 64M and buffer size to 256M then try again via direct play, i will also find another device and let you know. I'll clear the log down and start a fresh and further upload it. with packet loss i would expect to see other issues occur if that were the case not just direct stream/play for 4K. Everything else is flawless... again i could be wrong
3a8082e126