I never experienced bans in a long time since I added the warmup switching. Even full blown scans from scratch never resulted in them. That’s not saying that it’s not possible.
A couple of questions:
have you repeated the same test multiple times?
was there any other mount active on gdrive at the same time? even other software
That’s sounds really bad. Never managed to achieve that performance. Same questions as before:
have you repeated the same test multiple times?
was there any other mount active on gdrive at the same time? even other software
what did you do? Plex scan?
Personally, I think it should actually be CLOUD -> CRYPT -> CACHE.
Cached data shouldn’t be encrypted because it’s local and in your property and you will save your hardware and rclone the hassle to decrypt the data every time it’s read from cache. I’ll try to tackle this problem soon
Sorry I’m confused. In what rclone command? If i’m mounting the Crypt remote pointing to Cache remote, the only command I run is rclone mount Crypt: Should I put the flags there?
I thought it was CLOUD -> CACHE -> CRYPT because ncw said
There is an issue with wrapping the remotes in this order: cloud remote -> crypt -> cache
During testing, I experienced a lot of bans with the remotes in this order. I suspect it might be related to how crypt opens files on the cloud provider which makes it think we’re downloading the full file instead of small chunks. Organizing the remotes in this order yelds better results: cloud remote -> cache -> crypt
Yes. That’s how it works best now to take full advantage of caching. What I said earlier was what would be ideal in the future but again, doesn’t work now.
The cache remote would still get the flags even if you mount a crypt remote over it.
Did anyone tested some 4K streams, this is how its working with plexdrive.
( 71GB movie with high bitrate eg you need at least 80Mbit+ for direct play, will load within 2 seconds )
p.s. Note: Iam using plex media player since chrome wont direct play it and with transcoding it will take 5 seconds + to load.
@Ajki
could you explain to me your configuration?
I use Emby with google-drive-ocamlfuse for the moment I would like to be able to switch to the cache option …
Thanks
No but that’s a good test to do. Thanks for the suggestion. If you try it too, let me know how it works. It’s not clear from your recording: does that work in your current setup or it’s too much?
It usually expires but you shouldn’t be getting one in any case. Can you paste me your configs and some logs?
I do not understand the principle of cache well.
I use emby, and my movies are on google drive encrypted with rclone.
I mount a folder with plexdrive (or google-drive-ocamlfuse), it works well by 403 error.
then I mount a folder with rclone crypt that points to the google folder:
there’s now a Plex integration and warm up is gone. It wasn’t really working that well for that use case and by integrating cache with Plex, it will be able to handle scans much more efficient while providing playback times a smooth transition (what warm up tried to do by guessing really)
chunks are no longer expiring based on time. You will need to only give it a max cache size and it will clear the oldest chunks
all these meant a lot of removing stuff that might have bottlenecked and degraded performance. There was also a nasty bug that caused a lot of read errors which meant degraded performance too. Overall, the latest beta should give out a better experience
403s should not be encountered anymore either. If you still do, let me know please through an issue. Would be glad to help you out. I just reran a scan of my entire library and playing at the same time and I got no 403. I hope everyone else can have a similar experience
I really recommend to run rclone config and point rclone at your Plex installation if you’re using it for that. I’m also feeling the need to slow down Plex’s scan and with this integration I should be able to in the future.
I just started testing this with the latest beta and I’ve been running some benchmarks (too early to publish as there’s nothing scientific yet but it seems to be outperforming PlexDrive significantly).
Two issues: I have files “disappearing” from my directory. Not on the actual Google Drive itself but I’ll “ls” a directory from my cached-Google mount and see maybe 10 files and 1 sub directory. I can read/copy the files no problem. Don’t do anything but wait 30 minutes and come back and the directory is empty except for the sub. Killing the mount and starting it up again with the dump cache option brings everything back from the dead. However, it does mean that a full scan of a new Plex server, for example never completes because files keep disappearing.
In the logs, I’m seeing this (not sure if related):
Yep, for the panic issue I already added a commit to catch it. I can’t pinpoint where it’s coming from. Simple math there that shouldn’t ever let that happen. Furthermore, I have never really seen this happening before during my scans and that type of issue should happen more frequent.
Anyway, the commit catches the panic, errors out the read cause I don’t understand when it happens and what should be that read about but I have added all the details I need to find out in the error log: unexpected conditions during reading. current position: ... I will need those errors in that issue @Shacuih and @kelinger . They would really help me out.
@kelinger can you post your config to see if I can figure out the disappearance issue? And just to confirm: cache is reading, 30 mins later, some directory is now empty on the mount but not on drive?