Hi guys, I've had a problem for a while, but only now did I decide to write here.
At some random moments of the day, rclone goes to 100% of the CPU and any content becomes unreachable.
The only way to resume the correct functionality of the operations is to force the task manager to close and it will work again.
I have shared with you here the debug log of the exact moment something happened and it became impossible to continue watching the content with plex.
You can also see the moment when I restarted and correct functioning resumed.
I hope someone can help me.
The mount command has been modified in all sorts of ways. I also tried deleting everything and leaving only the basic things, like vfs-cache full, and log.
It doesn't solve the problem.
Run the command 'rclone version' and share the full output of the command.
C:\rclone>rclone version
rclone v1.68.1
- os/version: Microsoft Windows Server 2019 Standard Evaluation 1809 (64 bit)
- os/kernel: 10.0.17763.5458 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.23.1
- go/linking: static
- go/tags: cmount
Which cloud storage system are you using? (eg Google Drive)
OneDrive
The command you were trying to run (eg rclone copy /tmp remote:tmp)
pacer: Rate limited, increasing sleep to 2s
rclone is getting throttled by onedrive. which is a common issue with onedrive and much discussed in the forum.
Depending on what are you using it for slightly different values might be better - try.
In general OneDrive has limits - if you are heavy user then consider something more appropriate for your workflow. From Microsoft you can get Azure Storage - very different performance level than OneDrive. But of course you have to pay for it accordingly.
I would add trying this beta release that has some fix for 503 errors pacing:
Been working great on my setup. @kapitainsky recommendations are pretty solid as well, if you still see the pacer errors popping up lower the tpslimit down. I've found that 3 is the sweet number that makes Microsoft stop complaining for the most part.
Thanks for the suggestion.
I updated to beta version 1.69, hopefully that fixes the issues.
I activate the notice log in the command, unfortunately debugging in recent days has created over 500mb of text files for me and it becomes difficult to open it.
However, if I notice any anomaly in the base log, it will be an alarm bell to switch to debug and return here for further support.
It is directories structure and files listing only - if all in cache than browsing such mount is a breeze. --vfs-refresh makes sure that all is refreshed after mount starts.
It resides in memory anyway so only lives as long as your mount. There is no point to invalidate this cache for polling remote ever - so 9999h means pretty much keep it "forever".
You can use RC and enable debug logging when you are facing the issue. I rely on that when troubleshooting issues that are not easily to replicate and take some setup or have not figured out what triggers a problem.
I've been trying for two days.
It doesn't seem to crash during the day. But I can't test well, because now I'm encountering another problem.
Streaming is very slow, it's slow to start, sometimes I have to try multiple times to get it to start.
i suggested that you create your own client id, and then test without --tpslimit 10 --tpslimit-burst 0
did you ever try that?
the goal is to have a small log to document the issue.
so, for testing, i suggest the following script or do the same manually on the command line.
:: kill the mount
taskkill /f /t /im rclone.exe
:: delete the log
del c:\rclone\log\cloud.log
:: delete the cache
del c:\rclone\temp /q /s
:: start your mount command, must use `--log-level DEBUG`, not `--log-level NOTICE`
rclone mount ...
start to play a file, make sure it is direct play, no transcoding.
as soon as the video starts to play, kill the mount
now, you have a small log that will document the issue.
I'm sorry, I don't know where to upload the log.
Let's hope they publish it soon.
I tested it on a very high-performance device, so I had no problems starting up.
it went "quite" fast, there is still a lot of improvement to be done in starting playback.
so I think that during the day I will continue to try without tpslimit.
Even though I was advised to add it...