Dropped my cache remote and now seeing visual artifacts

What is the problem you are having with rclone?

For the past two years I have been running three remotes: drive, cache, and crypt. Today, I dropped the cache remote to go full vfs. After the switch, I direct streamed a video file with 12.7 MB bitrate and experienced visual blockiness in moving areas. When I streamed this file last night before the switch there was no blocking, and I'm wondering if I need to purge the cache. Also, when I transcode the video to the same bitrate (not direct stream), there is no blockiness, so I do not believe it is speed or bandwidth related.

The settings on my cache remote were:

chunk_size = 16M
info_age = 2d
chunk_total_size = 40G

The old service I am no longer using included:

  --allow-other \
  --user-agent='Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.92 Safari/537.36' \
  --use-mmap \
  --fast-list \
  --buffer-size 0M \
  --drive-chunk-size 128M \
  --timeout 1h \
  --umask 002 \
  --poll-interval=15s \
  --log-level DEBUG --log-file ..\rclone-debug.log \
  --vfs-cache-mode writes

My new vfs service file includes:

  --use-mmap \
  --dir-cache-time 1000h \
  --poll-interval=15s \
  --vfs-cache-mode writes \
  --tpslimit 10 \
  --log-level DEBUG

What is your rclone version (output from rclone version)

rclone v1.56.0

Which OS you are using and how many bits (eg Windows 7, 64 bit)

linux debian 10.10 (64 bit)

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

Google Drive

The rclone config contents with secrets removed.

type = drive
client_id = [redacted]
client_secret = [redacted]
scope = drive
root_folder_id = [redacted]
token = [redacted]
team_drive = 

type = crypt
remote = gdrive:/gdrive/crypt
filename_encryption = standard
directory_name_encryption = true
password = [redacted]
password2 = [redacted]


for that, need to use --vfs-cache-mode full, which is different from --vfs-cache-mode writes, when it comes to using sparse files and the way it downloads just the chunks needed to stream a media file.

--fast-list does nothing on a mount.

for what it is worth, for streaming media from cloud using a rclone mount, myself and other rcloners do not use --vfs-cache-mode

--fast-list does nothing on a mount.

Yep, I dropped that. It was in my old service file, not the new one.

I may consider dropping --vfs-cache-mode as well.

What is the best way to purge my cache, while rclone is running?

Thank you for your reply.

can you post the actual rclone mount command / service file you are running now.

The entire current service file:

Description=RClone VFS Service


ExecStart=/path/to/rclone mount gcrypt: /path/to/mount \
  --config /path/to/rclone.conf \
  --use-mmap \
  --dir-cache-time 1000h \
  --poll-interval=15s \
  --vfs-cache-mode writes \
  --tpslimit 10 \
  --log-level DEBUG

ExecStop=/path/to/fusermount -uz /path/to/mount


You can compare this to the old service file in my top post, if needed. They are both there.

My concern is with any items that may still be cached after I removed the deprecated cache remote from the config. Could this be causing bad data to stream?

Edit: My mount command: systemctl --user enable --now rclone-vfs

if your rclone mount command no longer uses the old cache remote, then rclone no longer using the cache remote.
so just delete those files from your local storage and be done with it.

and here in the forum, this is the service file, most rcloners use

Oh, I'm familiar, thanks :slight_smile: I learned quite a bit from looking at Animosity's scripts when I set this up a couple years ago. My problem is that my carrier restricts the use of certain service files, since I have a slot in a shared environment.

Glad to hear the old cache remote files aren't being accessed at all anymore, thank you.

Still troubleshooting why direct streaming the same video file worked better with the cache remote than without.

well, as i suggested, try testing:

  • --vfs-cache-mode full which is what most rcloners do.
  • not using --vfs-cache-mode at all, which i learned from the lurker known as @VBB
1 Like

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