Possible to cap VFS download speed

I’ve tried quite a number of variations and I can’t reproduce a consistent pull from rclone. I’ve tried by playing a movie for a few minutes and once my transcode buffer gets caught up, it drops down each time. I’ve tried small chunk size, larger ones, small caps, larger caps, no buffer, small buffer, large buffer size.

This is my current play on a 4K ~40-50Mb/s average bitrate movie.

Oh sorry! Yes, depending on the size of your pipe, the sweetspot might be different.

It’s by design to have spikes and drop down once transcode/playback/rclone buffer filled up. I think rclone buffer size option will have impact on ‘hiw high the spikes’ obviously this depends also on the var bitrate of the movie abd how aggressive buffer caching from client app

So when you play a movie (not analyze it), it sequentially reads and the chunk size will start to grow very quickly to the max-size configured.

Having a larger vfs-read-chunk-size-limit will generally cause bigger chunks to come down resulting in much bigger spikes, but it also should have longer peaks.

I’m wondering if having a 0M buffer-size with a 512M max chunk size is probably better as it’s already grabbing the 512Mb chunk so no real to buffer it.

This is actually good sign of healthy buffer caching and that your internet has good sized pipe. I’m guessing that movie has high bitrate spikes during that time too. You want plex and rclone to spike and download buffer asap sp getting that speed for 8 minutes is good if it fills buffer.

Try to use nethogs command to see whats really eating your bandwidth

What matters more is buffer size than max chunk size. Spikes speed is more likely shaped by buffer-size and vfs-chunk size combo. I don’t set max chunk size as my files varies so much between 55GB to 128MB. For me 128MB buffer-size size yield almost instant playback for all this file variation

I’ve been testing with 0M buffer as if it has to grab a 512M chunk to feed to the buffer, it still downloads a larger chunk and it’s there regardless of the buffer-size.

I wouldn’t think the buffer-size has impact unless you had a blip or retries. If it tried to grab something and it wasn’t able to, it would read from the buffer. You’d see those in the log as well if you were in debug.

I think it doesn’t work like that. There’s a post from vfs chunk size dev that I think basically mean grabbing chunk doesn’t mean putting them as buffer cache. You still need buffer size to control how much buffer you want, which then would have relation with your internet speed and the pms, and client of how aggressive it wants to buffer. Plex uses HLS in my case when playing to Android tv. To simplify 128mb buffer size sort of give me initial buffer of 128mb from client app point of view, which is initial spikes on rclone. As you further the playback it will just adds buffer slowly until the edge of chunk size position and then you would get another spikes for another 128mb buffer. The dev said chunk size is onky for how much it request, doesn’t mean how much it puts into buffer

Innever try 0mb buffer size but I tried smaller buffer size with same value of chunk size. Playing remux files 55GB with this setting, I can see from Android tv app it barely have enough buffered playback that results in buffering for few seconds when the movie bitrate jumps for action movies etc.

I think this can be caused by client app aggressiveness for buffering media and also when transcoding depending on the transcode throttling time. You should try to measure it not via plex playback but regular player like linux mpv on your rclone server

Sorry as it’s early here and my brain to keyboard isn’t working as much as I want.

I’d break it down into 2 types of playing.

Direct Play meaning Plex isn’t transcoding anything and Direct Stream or Transcode.

With Direct Play, I’d expect the rclone buffer to be the ‘saving’ point if something stuttered or got out of whack as Plex isn’t keeping anything anywhere for that.

With a Direct Stream or full transcode, it goes back to the Transcoder default throttle buffer in plex, which mine is 600 seconds so plex will grab/buffer/keep 600 seconds worth of content before it starts to throttle the transcode, which is normally what I was seeing as my ‘spike’ until that normalizes.

I’m the only one up and testing with a 4k movie now and it spikes as I’d want to fill the plex transcode buffer and than starts to really just sawtooth as it fills the buffer, but much smaller requests.

For Direct Streaming devices, I’d assume having a nice 512M buffer would be the way to go.

Ok, I’m watching the same 35GB 43Mbps (according to Plex) and my bandwidth usage is more sensible now - running around 16-35Mbps with spikes as expected 70-80Mbps to either get more data/fill buffers or because higher bitrate scenes are being played or coming up.

No idea what was going on last yesterday.

I think I’m going to throw in a --bwlimit 20M if I can’t traffic shape the rclone traffic in pfsense, as yes it’s ok grabbing as much as it can - when nothing else (and people!) on my network don’t want bandwidth.

I’m confused at why you’d limit it. Plex is going to consume what it needs to playback higher bitrate stuff.

I do the exact opposite and prioritize and shape the traffic as my goal is smooth playback.

Reducing the spike doesn’t mean the traffic goes away, it just artificially smooths it out and potentially creates problems.

Because I need to leave some bandwidth for the rest of the family e.g. if rclone is using up my whole 200Mbps then it will mean my wife can’t watch iplayer or the kids do their stuff. If Rclone/plex was my only priority then it wouldn’t be an issue, but I have other users and services running on my network that need some bandwidth.

As it is, I’ve managed to traffic shape it in pfsense so if nothing more important needs the traffic and rclone needs 100% of the line, it can have it.

Edit: I think my problems yesterday were caused by the streaming/transcoding limits in plex - I think I hadn’t restarted properly yesterday to remove them

I think that’s fine as I personally would rate my playing over wife/kids, but everyone has their own priorties :slight_smile:

I’d use pfSense as you stated and not bwlimit in rclone so it can use what it needs. I slice my traffic so Plex/GD gets the majority as a whole but the other stuff gets some weight, just not much.

@B4dM4n - I had one question regarding the vfs-read-chunk-size and what it does in regards to having a very large chunk to download. If the chunk size is up to 1GB as an example, does it perform 1 API get to get the entire 1GB and store that where? In memory until the client reads it? I’m trying to figure out how buffer-size interacts with the chunkSize that’s being requested.

This would my example log:

2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156017152 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: Read: ofst=3156148224, fh=0x1
2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156148224 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: Read: ofst=3156279296, fh=0x1
2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156279296 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: Read: ofst=3156410368, fh=0x1
2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156410368 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: Read: ofst=3156541440, fh=0x1
2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156541440 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: Read: ofst=3156672512, fh=0x1
2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156672512 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: Read: ofst=3156803584, fh=0x1
2018/07/14 06:20:50 DEBUG : Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: ChunkedReader.Read at 3156803584 length 131072 chunkOffset 2113994752 chunkSize 2147483648
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/Dracula (1992)/Dracula (1992).mkv: >Read: n=131072
2018/07/14 06:20:50 DEBUG : /Radarr_Movies/

vfs-read-chunk-size does not buffer anything. It just opens parts of the file and is otherwise fully transparent. Besides the management of this parts read calls are just passed down to the next layer (cache, crypt or gdrive for example).
bufter-size is the flag that controls buffering data in RAM. You can see the difference in the debug logs: without buffer-size, the ChunkedReader is called with a 128k array to fill (the “length” value).
With buffer-size ChunkedReader will be be called with a 1M array most times. This array is coming from buffer-size (AsyncReader to be exact).

I think I might be just confusing the terminology as when I see a chunkSize of 2GB, and I’m using 1 API get, I thought I was actually downloading that 2GB chunk as a whole and reading it through the other layers as it goes, which lead to my, where does it go question.

So if I used a 0M buffer and had no internet issues, I wouldn’t see any problems direct playing since there aren’t any retries or anything and things would just look smooth since I have a nice pipe.

I would use my spare memory and keep a 1GB buffer-size in case anything went bad. No harm no foul as if it’s not used, it’s going to play the file anyway. If I get some latency or some retries, the larger buffer size should compensate for that.

With direct streaming/transcoding, I’m assuming plex is going to have the data locally as it’s transcoding (based on my settings) 600 seconds of content so it can handle a blip here or there.

Right, with no internet or API issues, --buffer-size 0 will work fine.

--buffer-size will help to compensate retries and temporary bandwidth issues. But keep in mind that the --buffer-size value is per open file handle. So with --buffer-size 1G and 5 open files, rclone could use up to 5G of RAM for buffering.

Plex will store the 600 seconds on the local disc (in the Cache/Transcode Sessions folder in your Plex data folder)

Awesome. That helps clarify.

I have 32GB on my system and barely ever use more than 6-7GB so having 1GB wouldn’t be an issue for me as I could serve up 20-25 streams without running out of memory.

I capture all my rclone memory/open files with netdata so I have a good record baseline for anything I’m touching. I was thinking about going more to provide more cushion :slight_smile: