Still poor performance reading from GD mount

So, after wiping out the nasty 403’s, the next issue is right on my door step, preventing uninterrupted video streaming at all.

At this time i am not sure what info would help anyone out there to look into this and as far as i can tell from reading through other posts here, this issue seems to pop up here and there but is not described exactly similar in each case, so it’s just a guess right now.

In my case, the starting of playback on Plex, starting of file operations as a whole and browsing through directories or the Plex Media Library have become awesome fast. But the bandwidth that can be reached when copying a file from a mount point to a local drive is amazingly slow and goes from under 10 MB/s to 30 MB/s. The interesting thing is, that itt really seems to depend on the file operated. Some files stay consistently at about 30 MB/s when being copied while others can hardly hold a 10 MB/s throughput.

I’ve updated to the latest WinFSP and rclone versions, just in case something could have been fixed, but with no success. As reported from others here, reading through the web interface happens at nearly full line speed.

As always, i’d be more than happy getting your 50 cents about it.

What’s your mount command? Are there any logs? How are you testing the copy?

30MB/s is 240 megabits per second so that would play just about anything.

Mount command is:

rclone mount gdrive_crypt:/ q: --verbose --cache-chunk-clean-interval 10m --cache-chunk-path c:\temp --cache-chunk-size 16M --cache-chunk-total-size 20G --cache-db-path c:\temp --cache-db-purge --cache-dir c:\temp --cache-plex-password XXX --cache-plex-url http://127.0.0.1:32400 --cache-plex-username XXX --cache-workers 5 --config “c:…” --buffer-size 200M

I’ve also tried to set the buffer to “0” as my line should be pretty fast and runs at a 10GB uplink port, but this didn’t affect the transfer speed.

I am testing either by using rclone copy or copying with a file explorer directly from the mount point:

2018/10/27 08:52:51 INFO :
Transferred: 1.289G / 7.840 GBytes, 16%, 10.747 MBytes/s, ETA 10m24s
Errors: 0
Checks: 0 / 0, -
Transferred: 0 / 1, 0%
Elapsed time: 2m2.8s
Transferring:

  •                           Anon (2018).mkv: 16% /7.840G, 10.718M/s, 10m25s
    

Concerning the logs, i don’t know which part would be of any help. Also navigating logs with a screen reader is … painful, sometimes :-). Maybe you can specifically tell me what output is required.

30 MB/s is actually not the standard, on some files rates drop just below 10 MB/s what should also be sufficiant as i am not streaming any 4K content. But the ongoing pausing and interruption of playback seems to proof me wrong here.

The buffer should 0 as it’s not helpful if you are using cache.

The plex integration makes thing takes a little longer to start as it waits for plex to report playback and start up. I don’t use that as I don’t use cache.

What player are you using? Unfortunately, I’m not a Windows guy so I can’t provide much feedback on performance on Windows other than most people seem to be reporting that it isn’t good. I think that more related to fuse on Windows than rclone unfortunately.

I’ve read about issues with the Plex integration in other posts, but these were dated from March so i considered this to be solved right now.

The player which is used most is a NVIDIA Shield Android TV box. I’ve tried to tweak its settings back and forth since we got it but although it looks pretty stable for weeks, it all in a sudden stops delivering reliable results.

Maybe i should invest some time and try to setup a Virtual Box running Ubunto or CentOS. But as i am mostly unexperienced with working under the hood of nearly any distribution it might also be just digging in the dark when issues come up.

There isn’t an issue per se with plex integration. It’s the way it works. It limits the cache workers to 1 until plex informs rclone it has something playing and it than starts up the cache-workers.

You may want to try without using the cache and just use vfs and see if that works better as generally, most people are getting better results with that.

Is the vfs setup based onto a seperate remote like cache or is it just to add the destinct parameters to the crypted remote or the mount command?
I looked into your github documentation to figure this out about two weeks ago but somehow i didn’t get it.

and as a general question: what is the purpose or advantage of using the plex integration?

I use:

  1. configure an encrypted remote GD
  2. use an rclone mount and I have my parameters there

Plex integration is to limit the transactions per second for items not related to play back to 1. So things like scanning/adding new media gets reduced transactions per second and once it detects playback, it bumps it up.

OK, so sometimes i am even blinder than blind … and quite dumb in addition. Didn’t unwrap the encrypted remote from cache in rclone.conf for the first time i tested which of course delivered pretty similar results first.

After fixing that i instantanously measured 108 MB/s peak by transferring a 10 GB file.

Currently the mount is running by using the exact same settings you noted on Github except the --umask flag which won’t make much sense on Windows i guess.

So now i am curious if this will run stable and without any API issues. I’ll keep on reporting.

Correct. The umask would not be applicable on Windows. I’ve run that same config now for months without any issues API related.

Just a quick update after 24 hours of heavy use of my remote PMS:

The overall performance seems to be improved by factor 10 since i gave up on the cached remote in advantage of a vfs-based mount.

However, we experienced lots of trouble with loss of connections which is a destinct issue of Plex as according to my rare understanding of the technical side of things Plex doesn’t establish a permanent open connetion to the media it is streaming.

The good news is, that this seems to have quite easily been solved by investing another 30 minutes in setting up a proxy server (Caddy in my case) to keep the connection to the requested file open as long as it is required. So far, the error messages have disappeared during playback. Anyhow it seems to be a problem even for this configuration if playback has been paused for a couple of minutes as this brought back the errors sometimes.

Awesome. That’s why I dropped in Caddy in the mix as well. Happy it is working for you!

Looks like i was a bit hasty with praising my current setup :unamused:.

i’ve received a couple of lost connection errors after writing my last message here. but i am really not convinced that my caddy setup works the way it is intended to.

My PMS is running on a machine with a static, public IP address but is not registered with a DNS server. I chose a DynDNS service to get one. The caddyfile i am currently using looks like:

myhost.duckdns.org {
gzip
timeouts none
proxy / localhost:32400 {
transparent
}
}

I couldn’t figure out from the verious threads available if i have to mess with Plex’s remote access settings and port to get this to work.

And as far as i would interpret the caddyfile, it would forward any request for myhost.duckdns.org and forward it to localhost:32400. But Plex clients would connect to the PMS in a different manner and therefore bypass the proxy in general.

So i guess i need some more support here.

You can use my Caddy config as a working example. It’s listed on my GitHub:

I disable remote access.
I use a custom URL under the Custom server access URLs settings as https://myhost:443

Thanks, really appreciate that!
Actually i didn’t know about this option exists.

After locking me out from my PMS, i finally managed to build it according to your recommendation / best practice. The Caddy log shows activity on playback and it should now be setup properly.

Let’s see if it turns out to be the holy grail for this time…

I’ll update my directions to be a bit more clear on that as well.

One other item, for local playback on your local network, you do need a small line to add to a file to make the local listening not work as well as Plex is annoying in regards to that:

UFW or other firewall:

Deny port 32400 externally (Plex still pings over 32400, some clients may use 32400 by mistake despite 443 and 80 being set).
Note adding allowLocalhostOnly="1" to your Preferences.xml, will make Plex only listen on the localhost, achieving the same thing as using a firewall.

I had to stop Plex, make that change and start it back up and I can see all my playback (local and remote) via Caddy.

Preferences.XML seems no longer to be available on windows based installations as most settings have been moved to the windows registry as described HERE.. The allowlocalhostonly option, however, is not listed here and i will have to figure out if it is expected to be set at this location and which key type it requires.

It looks like there is no way to set this from within the web GUI.

Sorry as I’m not a Windows guy these days anymore.

You can validate it is working from a command prompt though and do something like:

netstat -an | find “32400”

If you just see that it is listening on:

tcp        0      0 127.0.0.1:32400         0.0.0.0:*               LISTEN

Only and no other interfaces, it is set properly.