Rclone Cache Is Better/Faster for Plex Than VFS

Just for some numbers, comparing a mediainfo command against a VFS mount vs Cache:

Cache


real	0m4.389s
user	0m0.056s
sys	0m0.034s

VFS

real	0m1.836s
user	0m0.063s
sys	0m0.020s

I use the same file in both and use the command:

time mediainfo filename.mkv

Once the chunks are 'cached', you get much better results as expected as Cache gives near disk speeds:


real	0m0.300s
user	0m0.061s
sys	0m0.007s

What I've generally shared is that the cache backend is a great solution for Plex if you have particularly bad players, built in apps and items that tend to not direct play or buffer very well. Music is a great example as it constantly opens and closes files all the time so the standard VFS does not work well for that.

My setup is all ATV's with my server local in my basement and I have gigabit internet so my use case is very specific to me and what works for my setup.

When I hit play on something, it starts in 1-2 seconds so it's almost hard to tell it's even remote media. I use the enhanced player on my ATVs with Plex so almost 99.9% of everything direct plays.

thanks for clarifying in such detail.
i didnt mean just you though i've seen @thestigma and @ncw push for vfs over cache backend at every turn.
i'm not complaining. i'm really just trying to understand why we are trying to move forward away from cache in develepment of rclone while vfs is good for some use cases, and cache is good for others.

I noticed your old mount doesn't have bind, while the new one does... I've noticed that OVH defaults to IPv6, and their routing to Google is not the best using IPv6. Try the old mount command with bind to compare IPv4 with IPv4. OVH has direct peering with Google and it is really fast with IPv4.

Yep, Verizon FIOS is only IPv4 currently so I have no use for it. I wonder if that's a good command to put in for a default as using IPV4 is just faster in my tests currently when I tried some Google Compute machines as well.

I think the focus is putting the functionality in the base VFS mount and expanding that rather than maintaining another backend. I'd personally rather see them merge up and have one to maintain to keep things simple and get the functionality that would be more helpful for streaming in there :slight_smile:

1 Like

Unless i'm misunderstanding, vfs will never be able to do certain things cache backend can such as seeking backwards.seeking backwards on vfs will always just recreate the stream and cache backend doesnt and is much faster to seek backwards.
doesn't vfs also rely heavily on memory rather than your disk? what about those people who rather have it rely more on disk?

It just depends on how things are implemented. I don't see any issues moving backwards when I try to as I tested a bit last night. I went back a few minutes and things started right back up for me. Cache would be faster since the chunks are local on disk though so that's definitely correct.

Both use memory for reading things as it depends on how you configure it. VFS has buffer-size which is configurable and only is used until a file is closed so it's really only good for sequential reading / playing with direct play since transcoding reads ahead based on your plex setting.

How do I cache it in a manner such that the chunks are only cleared when the limit for chunk_total_size has crossed?

That should be how it is working. Are you seeing something different?

chunk_size = 32M
chunk_total_size = 10G
info_age = 1d
chunk_clean_interval = 5m0s
chunk_path = /home/pi/rclone_temp

Well, I started Analyze in Plex for one particular TV Show, and it ended up storing over 40GB of chunks, averaging about 190MB for each episode (crazy, I know but it's necessary).

The main issue I had before was scrubbing backwards in the app.plex.tv video player for (transcoded) content would not play; playback session had to be restarted. With cache, I still faced the same issue, so I reverted back.

I'd start a new post and use the question template and we can help out as that should not be the case.

What should not be the case?

It should not go above your 10G you configured.

That was a really a non-issue because I have plenty of unused disk space. Right now, I'll stick to the current setup :slight_smile:

you reverted to vfs because you couldnt seek backwards with cache so you're resigning to 'seeking backwards just won't work' and going back to vfs?

More or less, yes.

I use the mount solely read-only with Plex. Most of the time, I tend to watch content inside Safari, where Plex almost always transcodes.

With cache, I did not notice any improvements, at all. I did however, notice a lot of downsides. RAM and swap were full, and I had well over 160% CPU usage across 4 cores, about 10 threads of rclone running (I’m assuming it’s the workers because I was running Analyze inside Plex). Then the size of chunks exceeded its defined limits.

For Kodi use in Windows I could not use cache because playback would not start until the whole file was downloaded. Has that changed somehow? Otherwise I cannot see how it could be considered faster.

sounds like VFS Mode Full. You sure using Cache Remote?

that isnt the way full mode works yet

Yes you are right, I was referring to --vfs-cache-mode full

You actually made me realize the existence of the Cache storage system. VFS is working fine for my usecase, anyway, and the fact that I read that Cache is not in development right now sorts of discourages me from trying it.

Edit: maybe I had investigated it when I started using rclone but seeing as there were caveats about Windows use I discarded it.

1 Like

i just switched back to the cache after High API usage.