There doesn’t seem to be a single location to discuss the relative merits of Plexdrive, on the one hand, and rclone’s new (as of 1.39) cache mount feature. Both are meant to solve the problem of Google Drive bans. Is there a consensus emerging about which of these is the better solution? Or is it a matter of different strokes for different folks?
1 Like
Been trying to figure out how to test but my first test resulted in a ban and asked a few questions and not sure how to configure it properly so I can’t comment.
plexdrive has worked flawlessly for me for months.
The only problem a faced with plexdrive is that it is read only, that’s why at the moment i’m using rclone cache.
No problem for now except for updates. That i didn’t exactly understand how to set it automatically.
plexdrive isn’t read-only. You can delete from it. There is a bug that you can’t delete quickly from it as it generates 403s, but I delete from it all the time.
version 5 is not read only
(I’m still on plexdrive4, and deleting manually over rclone mount :-))
From what i know you can delete but you cannot write anything on it.
the new rclone cache remote does not use the google drive update protocol as for now => external updates to the drive will not be picked up, unless the directory cache time expires or you send a SIGHUP manually. In both cases, you will most likely get a ban if you do it several times (combined with a full scan).
there is already an issue for this:
I use a script with rclone copy/move to write anything to my GD.
1 Like
I am currently switching from ACD to GSuite and have to look into the rclone cache feature or plexdrive.
Tbh, I would like to stick with rclone only if possible.
I have been following the posts over here and from my understanding the rclone cache works great with a Gdrive that doesn’t have uploads to it.
If you upload anything to your Gdrive you will have go rebuild your cache.
Is that right?
Is this the same way PlexDrive works?
I assume a cache rebuild once a day wouldn’t do any harm by hitting the rate limits, right? So, why don’t we let the cache expire at a clock you are not using the Gdrive? Would that be possible?
Hope this hasn’t been discussed yet!
Thanks!
€dit: Should probably mention that I am using rclone crypt to encrypt the data on GSuite.
Yes that is right at the moment I think
The rclone cache backend will plug into the drive changes mechanism in due course.
1 Like
Nice to hear that and looking forward to that version.
Big thanks once again to you and all supporters! 
1 Like
Thought I would share my recent experience.
I have a VPS running plexdrive on Ubuntu 17.04 with 4 cores and 4GB ram.
speedtest-cli often reports upload and download speeds over 400Mbps.
I recently had 5 concurrent streams and my friends reported buffering.
Today, I started stress testing it and sure enough, once I got to 5, I started noticing frequent buffering.
So I switched over to rclone cache and reran my tests.
I have 10 direct plays going right now and NO buffering. Been running all 10 for over an hour.
CPU usage is about 20 to 40%. RAM is around 2.12GB.
Not using crypt yet. I’ll be testing with that soon.
Just want to say I am very impressed and happy with rclone cache.
Big thanks, @ncw and contributors!!
1 Like
yes - cpu usage is siginificantly lower with rclone cache in comparisoin to plexdrive.
Yeah I have similarly reduced CPU overhead, which is great on a 2 core VPS.
Once API polling to evict stale cache hits the prime time I think it’ll be fit for all the purposes plexdrive currently handles.
But it wasn’t CPU load that was causing the buffering when using plexdrive. Perhaps it was the file/chunk handling. I monitored load while doing my tests.
How does cache handle scanning compared to plexdrive with plex?
@zSeriesGuy
Mind posting your mount settings
This is the contents of my service:
[Unit]
Description=rcloneMountGD
AssertPathIsDirectory=/Plex
[Service]
Type=simple
ExecStart=/usr/bin/rclone mount \
GDcache: /Plex \
--config /root/.config/rclone/rclone.conf \
--read-only \
--allow-non-empty \
--allow-other \
--cache-db-purge \
--cache-info-age=8h \
--cache-workers=10 \
--cache-db-path=/tmp/rclone/cache-backend \
--cache-chunk-size=8M \
--cache-total-chunk-size=25G
ExecStop=/bin/fusermount -uz /Plex
Restart=on-abort
[Install]
WantedBy=multi-user.target
1 Like
@zSeriesGuy I will definetly give these a try but how are your start times compared with plexdrive? For me, starting a random episode on plexdrive it starts like 3x faster than rclone cache. Once it starts playing though, if I restart that same item it will be the same as plexdrive more or less.
@chris243 I would say that it was about the same. I didn’t pay particularly close attention to start time unless it was abnormally long. And I didn’t notice any.
I was more focused on the buffering issue that I had when 5 or more streams played. All I really know is that I got 10 concurrent streams going with rclone and none of them were buffering. I think I would rather have a longer startup time than to have the buffering. I share this plex server with friends and family and I would like them to have a good experience.
OK… so I’ve tried to create a cache and within an hour achieved a ban. I suspect I’ve wrapped the remotes incorrectly (especially as I’m using crypt) so hoping for some guidance so I can lose Plexdrive and start using rclone cache.
What’s the best way of wrapping… I currently have 3 remotes set as below.
- gdrive = this remote is the direct link to the encrypted files on Google Drive
- crypt = this is pointing to the gdrive remote and decrypts the files
- cache = this caches the decrypted files
I suspect this is the issue and i should swap 2 & 3 over so that it becomes:
- gdrive = this remote is the direct link to the encrypted files on Google Drive
- cache = this caches the encrypted files
- crypt = this is points to the cache remote and decrypts the files
Hoping for clarity before getting myself another ban.
Thanks