Which rclone parameter responsible for increase in call to drive.files.update?

I’m using latest beta with vfs cache writes. Everything works great except for the number of 403 errors for drive.files.update api calls. Which of rclone settings most likely responsible for this? Is it something something max age?

Next question, when we seek forward in a file for example seek forward a movie we watch on plex, it works great because the location is already buffered or vfs cache chunk size setting makes an efficient api call, but when we seek backward, like when we rewind or seek backward why this is so completely behavior in rclone? Instead of reading from buffer because we just did download that part few seconds or minutes ago, rclone seem to do the following logic regardless you use rclone cache or vfs.

Rclone would ignore past downloaded parts or buffer at the time of seek backward call. Do something that blocks the start of fetching file from that seek backward position to whatever value you set in cache or vfs chunk size. This results in two very different result, seek forward feels instantaneous just as if the file is read from local file. Seek backward would result in 3-10 seconds hangs or even more. In plex this means when you seek backward, even if you playedthat part literally one minute ago, the playback would hang up, after 10 seconds of so it would resume… Or not. So it is much faster to just seek backward, close playback, press playback again and choose to resume from that position…

Quite a few things use Files.Update

  • overwriting an existing file
  • dedupe
  • rmdir
  • move
  • dirmove
  • setmodtime
  • remove

All of these are modifying operations though.

As for the seeking - how it works depends a lot on how you have rclone set up. Without using cache whether you seek forwards or backwards, rclone will close the current connection to drive and re-open a new one so I’m not sure why seeking forwards vs seeking backwards would have that much effect. However I’m not a plex user so I hope someone else can help you with that bit of your query!

Hmm interesting, I deleted 500 files from Plex web which then deleted the files via rclone vfs writes, and although the files successfully deleted at the same timing the 403 errors increased by the drive.files.update API calls.

It seems that Plex DASH media streaming doesn’t play well with rclone vfs chunk size… we seem better off playing directly the file via rclone->samba or DLNA.