Rclone mount with Plex takes 8-10 seconds or more to start playback

Help and Support
1

What is the problem you are having with rclone?

I am using the rclone mount command with Plex, and it takes on average 8-10 seconds for playback to start. I am not transcoding, only direct playing. The server is a Hetzner dedicated server with a 1Gbps line, and I have tried multiple clients, all on a 1Gbps line. So bandwidth should not be an issue.

What is your rclone version (output from rclone version)

rclone v1.57.0-beta.5786.f589dbc07

Which cloud storage system are you using? (eg Google Drive)

Google Drive

The command you were trying to run (eg rclone copy /tmp remote:tmp)

[Unit]
Description=RClone VFS Service
Wants=network-online.target
After=network-online.target

[Service]
Type=notify
KillMode=none
User=1000
Group=1000

ExecStart=/usr/bin/rclone mount gdrive-mount: /home/bink/Stuff/Mount \
  --user-agent plexymcplexface \
  --config /home/bink/.config/rclone/rclone.conf \
  --allow-other \
  --timeout 1h \
  --dir-cache-time 1000h \
  --log-file /home/bink/logs/gdrive.log \
  --log-level DEBUG \
  --poll-interval 10s \
  --umask 002 \
  --cache-dir=/cache \
  --drive-pacer-min-sleep 10ms \
  --drive-pacer-burst 200 \
  --tpslimit 10 \
  --tpslimit-burst 10 \
  --vfs-read-chunk-size 128M \
  --vfs-cache-mode full \
  --vfs-cache-max-size 500G \
  --vfs-cache-max-age 168h \
  --vfs-cache-poll-interval 5m \
  --vfs-read-ahead 2G \
  --bwlimit-file 15M \

ExecStop=/usr/bin/fusermount -uz /home/bink/Stuff/Mount
Restart=on-failure

[Install]
WantedBy=multi-user.target

The rclone config contents with secrets removed.

[gdrive-mount]
type = drive
client_id = **REDACTED**
client_secret = **REDACTED**
scope = drive
token = {"access_token":"**REDACTED**","token_type":"Bearer","refresh_token":**REDACTED**
team_drive = **REDACTED**
root_folder_id =

A log from the command with the -vv flag

2

Note, I changed the log to DEBUG only for this test... I usually have it set to INFO.

Also, in this test, I was trying to play Dune, which you can see near the end of the log file. I do see entries for "present = true" which I understand means that it should be reading from the local cache. But even still, it took over 10 seconds to start playback.

3

@Animosity022 I hope it's ok to ping you here, I just wanted to make sure you saw that I posted this with logs... thanks!

4

hi,

  • the server has 1Gbps line, but what about the client, what is the up/down speeds?
  • as a test, remove --bwlimit-file 15M and see what happens.
    if that does not help then post a full debug log for animosity022.
  • fwiw, when, i and other rcloners, use a rclone mount for streaming, we do not use a vfs cache, in effect --vfs-cache-mode=off
5

Hi @asdffdsa, thanks for your reply. In my initial message I did say that the client is also on a 1Gbps line. Sorry if that was not clear.

I only recently added the --bwlimit-file 15M to see if I could track down the problem. Previously that line wasn't there, and it makes no difference with my problem whether the line is present or not.

As for the debug log, I thought that's what I posted in the initial post, the gist link. Is that not the debug log that is required? If I need to post some other log, please let me know how to retrieve that, so I can provide it. Thanks!

6

sorry, still on my first coffee.

do you have any low-res media, 480p/720p or an audio file?

7

Probably doesn't matter much, but why are you using the beta?

Are you direct playing or transcoding?

8

Direct play only... and it doesn't seem to matter what resolution or file size it is, it always takes the same amount of time (at least 10 seconds) to start playing.

I only switched to the beta last night to see if that would help the situation... I was speaking to someone else that has a similar setup to me, and he said his playback starts almost instantly, and he mentioned he was using the beta, so I thought I would give it a try. But before then, I was using the stable version and the results were the same.

I also just asked some other users who also use my server, and they all said they see a 10-15 second delay before playback starts.

9

I just tried playing a 480p file, and it took 14 seconds to start playback.

10

There's really nothing rclone related as the rclone log is clean.

You are either not direct playing and it's transcoding or you are having an internet latency issue.

11

Interesting ... I'm definitely not transcoding (both Tautulli and Plex show direct play). As far as internet latency, that's very unlikely because like I said, my home internet has 1Gbps down. A quick speediest shows 9ms ping and 937 Mbps download speeds, which is the speed I get consistently, every time I do a speed test.

I'm not quite sure where to turn here, any ideas?

12

Where is the server located? Where is the client located? What client are you using?

13

The server is a Hetzner server, based in their Finland datacenter. The client is in Florida. I've tried multiple clients: Apple TV (both native Plex app and Infuse). Also tried iOS Plex app, and iOS Infuse app, as well as a Shield. All with the same results.

Also, I've had other users report the same thing, I'm not sure of all their locations or clients used... but it seems pretty consistent for everyone on the server. So it seems likely to be a server issue.

14

Oof. Yeah, that's pretty far away which is why I asked about latency as you can fix how fast a packet takes to get from FL to Finland as it only travels so fast.

My example ping to Finland Hetzner.

PING hel.icmp.hetzner.com (95.217.255.81) 56(84) bytes of data.
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=1 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=2 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=3 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=4 ttl=50 time=108 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=5 ttl=50 time=108 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=6 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=7 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=8 ttl=50 time=110 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=9 ttl=50 time=110 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=10 ttl=50 time=108 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=11 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=12 ttl=50 time=109 ms
64 bytes from hel1-speed.hetzner.com (95.217.255.81): icmp_seq=13 ttl=50 time=109 ms

The lag is most likely caused by that if I had to guess and you can't tune around latency. You might want to try something in the US.

1 Like
15

100% latency. My server with OVH is located near Montreal, Canada, and I'm in Los Angeles. I'm on a 500/500 fiber connection with highly consistent speeds, but my ISP's peering isn't the best and can change from one day to the next. Most days, latency between my house and the datacenter is in the high 70s to low 80s. Playback takes about 3 to 5 seconds, so your 8 to 10 with a latency that's likely higher than mine is perfectly normal. I'm surprised that you don't have more issues, because whenever my latency spikes into the 100s, I can't direct play anything anymore. Thankfully, that doesn't happen very often.

EDIT: Since you're in Florida, your ISP is likely Frontier, no? That would explain a lot, as I'm with them as well :wink:

16

You have a lot of parameters on your mount and some of them seems contradicting. E.g. --drive-pacer-min-sleep 10ms and --tpslimit 10

I therefore suggest you try with less parameters and only add parameters you have tested and verified the effect of (for your usage).

17

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.