Did your rclone log file show the daily limit being reached? What API methods failed? Was it drive.files.create? With your config and a few tweaks, Rclone has been great with the new VFS feature with writes enabled.
Except for the occasional drive.files.get and drive.files.list error, but it’s only 2 of those in the span of a few days.
Definitely not any daily limit as I am pretty light on API hits
I produced the errors when I dumped 4-5 files on the write cache and it uploaded them I suppose. I’d expect to see some errors in my rclone log but they are none. I only run at INFO though as debug is a bit much usually.
That seems odd that you’d get 500 errors. I haven’t gotten those before. I do have in the past 4 days of using the config (although only 2 are with writes), only having 2 of each get and list errors for 403. Could it be a coincidence possibly with maybe the DC that your rclone instance was trying to use? Writes seems to offer better reliability since without it, I don’t believe resumable uploads are possible since I burned through 3TB in less than a day of reuploads and at the end of the day, the API upload BW limit without the writes function.
I finally just gave up as I couldn’t get it to do what I wanted.
My use case is I wanted to remux some files from mkv to mp4 to alleviate any playback. I was working through scripting that into my process and was going to do some batch converts over night.
If I configured vfs-cache-mode writes, it would throw 403 errors on copies and just be painful.
If I used cache for temporary storage, I’d have to turn on vfs-cache writes anyway and that doubled up the storage.
I just tossed my mergerfs back into the mix and turned on my upload script.
That allows me to not use the cache and keep my vfs-chunk-size on for quick playback and I’ll just let my rclone move upload at night like I used to.
Not the best, but I’ll take working over being annoying.
If you write directly to the mount while remuxing then yes you could get errors, but if you remux the file into tmp and then screen it and copy it to the mount you will do just ok, I have been doing that. But I don’t understand why people want to change from mkv to mp4, it’s only a container, what matter is the codec used inside if you care about Direct Play compatibility. My 12 years old tv can read mkv just fine.
Check which api call produce the 403 and eork from there. I’ve been lazy enough to even directly write to mount from my http download as i set my download folder in my mount, my unrar, and my torrent download and this all works. The 403 errors i got are most likely not related to this operation.
I’m changing containers as part of my process to remove audio that isn’t supported on my devices as I’m aware that MKV and MP4 are containers.
I’m changing the audio codec from TrueHD to EAC3/5.1 in my case so nothing in transcoded along with removing any subtitles as I use external forced SRTs if needed.
MP4 is just a cleaner container for my Apple household.