If you want to know for certain use -vv on the mount and look at the log.
In my experience it will be the media player seeking around the file reading small bits of data to find out about the video file (eg read the bit rate, load the thumbnail etc) - this is quite time consuming as each seek takes a second or two.
But you aren't using the same media player on Linux presumably... that is what Nick is talking about here.
The network connection really isn't as relevant as long as it' sufficient. 100Mbit is certainly more than enough for anything but the most extreme of extreme (like maybe 8K).
For Windows I've had great results with VLC - which is generally considered the best media player anyway. It was also designed from the start to be meant for network streaming. I have several high bitrate 4K test-cases that can start within roughly 3-4 seconds on my 150Mbit.
But I have seen one or two weird cases of spesific formats or file series that can open much slower than others, but this is pretty rare all in all and is more like the fault of the format not being design very linearly.
I used Plex on both platforms - direct play. I've also used VLC and Media Player Classic on Windows and get 30 seconds starts on all three, so I don't think the client is the issue.
Out of curiosity, what are your rclone settings in Windows, and do you use WinFSP to mount the drive?
Using WinSFP is the only way to mount on Windows, so yes.
I would first of all just give VLC a shot and see if it's better with that.
You aren't using any caching or anything right?
Also - try more than just one file. As I said, a few video-formats can be a little troublesome, but most will play fast.
I've always used whatever latest version available of both Rclone and WinFsp. Haven't had issues in almost two years. I do like to live dangerously, though
Jokes aside, I do currenly use the latest stable Rclone due to a bug.
And this is roughly consistent for all types of media? Same problem on even say - a music file?
Just trying to get an idea of what the problem is.
When you see your network usage going in spikes it means your application (player) is not asking rclone for all the data at once. For some reason it is asking for lots of little bits here and there, and each request will take maybe a second or so to complete due to latency. This typically indicates a file format that is not very linear and maybe not ideal for streaming, but sometimes it can also be the fault of the player because it is not just trying to play the file but also collect various other information from the file (that reside in other areas of the file, making rclone have to jump around a lot).
Using a larger buffer-size isn't really going to solve this sort of problem.
Not really. You could pass special parameters to it via an rclone flag to make it behave differently, but no such thing is required to do what you want and it is very seldomly used outside of spesific debugging and such.
I think you should take his advice and make a -vv log . This will tell us exactly what is going on inside rclone and thus why it is taking so long - then we can stop speculating and "shooting blind".
When I say "us" I mean someone who is better at reading the logs than me probably hehe... I will give it a shot, but I am still only a novice at decoding the debug logs as they are fairly complex.
