30 seconds to start playback - 100mbps download speed

It's probably more something Windows related than anything else, which is why I run my server on Linux so other than the settings you have, it's really just a local machine issue I would surmise.

Question would be, what on your machine is messing it up.

Is this seeking of each file standard behaviour? My install is pretty standard.

Latest versions of Windows 10, WinFSP and RClone with standard RClone conditions using a private API.

No 3rd party antivirus or firewalls. Just Windows Defender (or whatever it's called these days)

Yup. When running a Ubuntu VM on the same machine - using the same rclone command - files start playing within 5 seconds or so.

So it's definitely an issue with Rclone, WinFSP and Windows 10

I know there are some people running Windows here and have no issues, so not sure it's the whole but most likely some specific piece of software or combo that is going on.

Personally, I just find the Linux more stable so I stick with that.

I agree. Unfortunately I need Windows for work, and I need to hardware transcode Plex. I can run Linux in a VM but then I'll need to buy an additional GPU to passthrough.

Rclone should work OK in Windows- so would really like to get it working I'd possible.

You could try the docker image too and see if that performs better.

Agreed, when rclone is supported in Windows I think it makes sense to dig into some of these issues to find out how we can work around them. Throwing your hands up and saying "it's probably something in windows, use Linux" isn't really terribly helpful to the practical situation at hand. I'm probably biased as a Windows-primary user though :slight_smile:

Regarding a second GPU, I'm not sure that's necessarily required.
Firstly, you could just rclone on Linux and make the files accessible on a regular Samba network share for Plex to use. (Samba is basically the same fundamental system that Windows share uses and should therefore be highly compatible). Plex itself wouldn't absolutely need to run on Linux if that's a problem for you - and that is the thing that does the transcoding after all, not rclone.

Secondly, VMs have gotten pretty advanced these days. I know that VMware among others can now do GPU acceleration in virtualization. You could play games in a VM now, so I assume that means you could probably also leverage GPU transcode in one as well. GPU acceleration support typically is not available in the free versions of the software though. At least not for VMware. Just thought I'd mention this in case it could be relevant for you.

1 Like

Windows is perfectly viable in this situation. I've been running a Plex server with an Rclone mount in Windows Server 2016 for more than two years now. Sure, there were some issues in the beginning, but it's been rock-solid for me for a long time. My one and only problem is and has always been Plex users and their damn wireless connections :roll_eyes: Then again, that's not really my problem.

Personally, I don't use Plex. Back in early 2018 when @Animosity022 was doing a lot of testing with different buffer settings, etc., I had some very similar issues to the ones described by OP, with long start times, lots of buffering with large files, and so on. At one point I had even given up on streaming any 4K content. But then something changed with Rclone, and all of a sudden I was able to open files very quickly, and I could stream even the largest files. My Internet connection has been the same all these years, at 150/150.

I understand that none of this is helpful, but I just want to emphasize that it can all be done in Windows. In my opinion, the only advantage Linux has here is that it handles large numbers of files and folders much better, resulting in a significantly faster Plex scan.

Might be worth trying without anti-virus if you are running such a thing.

Agreed, but I can rule out that this fixes all issues.
As I said the vast majority of files work for me, but I currently run no antivirus whatsoever - and it still affects a few files.
OP seems like he is more affected than me though based on his description.

FWIW, my setup is as follows and I have no issues with slow startup play times in Windows:

Rclone runs inside a VM on a Proxmox host, with a samba file server. The files are accessed on the VM via rclone mount, which is then symlinked to another folder, which in turn is shared via samba over my local wired network. My Windows 10 HTPC accesses the samba share as a drive mount, which I then browse and open in MPC-HC. Movies start playback within 3-5 seconds consistently, with no stuttering.

This may not be helpful (in that I'm running the actual rclone mount via a linux box), but I can vouch for the fact that MPC-HC has no issues with seamless, low-latency playback of files accessed via a mount, even when passed through samba over a wired network. Hopefully the player variable can be dropped and the OP can focus on the actual mount.

Possibly it a WinFPS thing then? ...

Unlikely, because we all run the same version of WinFsp, and most of us have no issues.

I have the same problem when using nssm to mount rclone as a service, but digging around the forum I found @thestigma has shared a much better way. Using a batch script with

rclone rc vfs/refresh --fast-list recursive=true

cuts the wait down to 10-12 seconds. Disable real time protection and everything opens in 4-5 seconds.

You can find the script here and adjust it to your liking:

Plex is miles better without the need for cache. Life is good. Thank you @thestigma :partying_face:

2 Likes

While this is the best way to prime the mount, it shouldn't make a difference when opening individual files, unless all those files are inside the same folder.

Looks like Bill is about to release a new beta of WinFsp. More testing ahead :slight_smile:

1 Like

Hmm I think the actual trick after all of that was removing the mount from Real Time Monitoring in Windows Security.

I tried both the batch file mentioned above- and the standard mount command, and files now start in 5-10 seconds now - which I'm happy with considering my limited download speed.

The one advantage the script has it is implements --fast-list.

I might load the new batch file via NSSM

Oh? interesting. Do you know when it's planned?

Not sure when exactly, but I noticed on his GitHub the latest commit said "build: bump version to 2019.3 B3".

Is this something you specifically set up, or did Windows Security monitor the mount by default?