How to optimize for playback scrubbing on an rclone mount?

I am using rclone to mount data, which I then watch through Plex/JF. The problem is the timeline scrubbing. This is all done using vfs.

If I skip forward (and it has buffered): It is pretty much instant
If I skip backward at all (even a small amount like 5 seconds): 5-10 seconds load to rebuffer and play

Is there anything I can do to improve this aspect of my rclone mount? It seems the cache is flushed instantly once that part of the video file is played. Is there a setting where I can tweak this so that data is only flushed once it reaches X amount?

From reading the mount documentation, it seems like maybe combining these options might accomplish what I want:

--vfs-read-chunk-size
--vfs-cache-max-age
--vfs-cache-max-size

But according to this documentation -vfs-cache-max-age is only compative when using cache-mode full, which doesn't sound ideal.

Any othersuggestions as to how I can improve scrubbing performance?

I don't think there is much you can do unless you want to try out the cache backend as that would keep chunks local storage and that might help if you use case is constantly moving forward/backward.

When you go back, I'm pretty sure it closes the file, which dumps the buffer and it has to open the file again and that takes some cycles.

It also depends if you are transcoding or direct playing as that adds more over head.

cache-mode full would fix the issue as well but that would make you download the whole file before anything starts so that's not ideal either.

I wonder if something could be done, on the development side, to have an option to start playback while the is being downloaded and put in cache, in background.

Coming from Google Drive File Stream, I remember finding the behaviour of cache-mode full quite counterintuitive.

I'd like to do that, but I haven't got around to it! Unfortunately it is harder than it sounds as there are a lot of edge cases.

Well, thanks for at least entertaining the idea.
It's something to look forward to. If it'll ever happen, I'm gonna be very happy.
If not, thanks anyway. :slight_smile:

The problem is seeking of the file....

If rclone could download the file sequentially and delay seeks until that bit of the file had been downloaded then it wouldn't be too hard.

Maybe that would be good enough for most use cases?

I think so, that could be very useful. I have always wished that there was an option to activate the sequential download, that is, when I start playing a file it will be downloaded sequentially until it is completely downloaded.

If you try to advance to a point that has not yet been downloaded, rclone could delay it and not allow you to do so, or rclone could cancel the previous sequential download and start downloading sequentially again from the new point to the end.

This is relatively easy to implement, so I might have a go at that for --vfs-cache-mode full. It would certainly improve performance over how it is now even if it doesn't catch everything.

1 Like

This would be the way to go, in my humble opinion. With the way rclone handles chunks, seeking would not be too "costly", as far as API limits are concerned. Also, the above would be needed anyway, as one might need to start viewing a file not at the beginning (Plex, Kodi, MPC-HC... pretty much all players allow to resume).

I think that might be best in version 2! The rclone cache is very simple at the moment which is good because I can reason about it easily, but bad because there isn't anywhere to store the fact that only the second half of a file has been downloaded.

I think I'd suggest thinking of a simple approach to get most cases using the cache backend and you can use a read ahead type setting.

I was thinking about testing it using a larger buffer size maybe so grab more of the file and it store the chunks and that would help with scrubbing around.

The use of starting a file in the middle already works as it opens and just seeks to the spot.

Yes, even a configurable "read ahead" function, storing temporarily in the cache, would be good.

1 Like