DZMM

I think the script doesn't like it it when you have only one folder specified in: MountFolders=\{"tv"\} Try adding a second folder e.g movies MountFolders=\{"movies,tv"\}

Nope - I was having different problems (I can't remember what right now) so I'm sticking with mergerfs.

yes it works fine. I just did a reboot and the plugin disappeared - I don't know if it was because of my failed upgrade to 1.53.1

@Waseh I've just updated and spotted a few things. - I'm currently on 1.53.0 and when I tried to update to 1.53.1 it didn't work and asked if rclone was running - The config editor seems better as before I couldn't use it as it wouldn't show my whole file. However, even though it shows my file I can't apply any edits as it says please shorten this text to 4096 characters or less (you are currently using 5648 characters)

I've come to the same conclusion i.e. the defaults are fine and tinkering is only needed if experiencing problems. I'll try and update the scripts this week - I tried last week, but I had a few problems including a pull from @watchmeexplode5

That's the bit I'm not sure about - if it's kept once playback stops. Update:

I think I'm going to try raising my --buffer-size to 256MB or 512MB, rather than using --vfs-read-ahead as I'm nervous about multiple disk writes wiping out any potential benefit.

@Spladge my ff seek experience with the new settings is so good, I can't really see what improvement vfs-read--ahead could make. It feels like local playback as the restart times are so fast - in normal usage I wouldn't be able to tell the difference as I wouldn't be monitoring so closely. I think I'm just going to leave it all alone so as not to rock the boat.

Update: even with the shares on other pools set to 'Only' the plugin sadly doesn't work for the cache pool: highlander-diagnostics-20200909-2200.zip

Thanks. Can you help me play around with --buffer-size and --vfs-read-ahead please. From the rclone docs: Previously I had --buffer-size at 256MB, but based on the above I've gone with the smaller default of 16MB - I'm not sure what --vfs-read-ahead defaults to. Whatever the defaults are, my first play times seem about 50% faster (1-2 seconds rather than 2-3 seconds) with the settings above - I want to see if setting a higher --vfs-read-ahead makes skipping forward even smoother. I'm a bit worried though that setting it too high will reduce the hit-rate on the cache if it's filled up with content that isn't used. It only caches 16MB to the memory buffer (--buffer-size) and to disk whatever the --vfs-read-ahead is set to - as above I don't know what the default is. so it's the former. I'm curious to see if setting --vfs-read-ahead to say 128MB is enough to buffer the next xx seconds so skipping is a bit smoother. I think this might leave you with a lot of unnecessary transfer as you only need the first say 5-10 seconds of each file to get virtually instant playback. I think using --vfs-read-ahead will give you a better result. Looking at my caches, my adult TV cache has already hit 500GB in just over 12 hours - although this might be because I'm building a new test Plex server which is currently scanning that folder. root@Highlander:/mnt/cache/downloads/rclone# du -h --max-depth=1 | sort -hr 756G . 499G ./tdrive_t_adults_vfs 219G ./tdrive_vfs 39G ./tdrive_uhd_vfs 0 ./registry_vfs 0 ./gdrive_media_vfs I've bumped up tdrive_t_adults_vfs to 1TB anyway to see what happens and I'm going to break my kids tv out of tdrive_vfs into tdrive_t_kids_vfs, so I can see how many of their shows I can cache e.g. my son tends to watch the same bits of Adventures of Gumball over and over again.

Can I get some help testing please. V1.5.3 of rclone (remember you have to remove and reinstall the plugin to update it) now supports better caching where files can be cached locally. I'll add a variable in for setting the cache location once it's all working, but for now can a few people try these settings in the mount script: # create rclone mount rclone mount \ --allow-other \ --dir-cache-time 720h \ --log-level INFO \ --poll-interval 15s \ --cache-dir=/mnt/user/downloads/rclone/tdrive_vfs/cache \ --vfs-cache-mode full \ --vfs-cache-max-size 500G \ --vfs-cache-max-age 336h \ --bind=$RCloneMountIP \ $RcloneRemoteName: $RcloneMountLocation & set the cache-dir to wherever is convenient. The settings above will keep up to 500GB of files downloaded from gdrive for up to 2 weeks, with the oldest removed first when full. I think this will work well with my kids who keep stopping and starting the same file, or when plex is indexing or doing other operations. However, I don't think it will help majorly with playback for my setup, unless a user tries to open the same file within a few hours. Dunno. There's another new setting --vfs-read-ahead that could potentially help with forward skipping/smoother playback by downloading more data ahead of the current stream position, that we can play with as well. Edit: poll-interval shortens the default 1m, so should hopefully add a bit more butter to updates. Edit 2:. Initial launch times are much faster even before the cache kicks in!!

you don't have a gdrive_vfs remote in your rclone config

logs

Just to be clear, is it creating /mount_mergerfs/gdrive_vfs/music,tv,movies or 3 folders - /mount_mergerfs/gdrive_vfs/music, /mount_mergerfs/gdrive_vfs/tv and /mount_mergerfs/gdrive_vfs/movies? I'm suspecting that you have a /gdrive_vfs folder in your gdrive when you 'shouldn't' which is creating the other folder. Can you post your rclone config, without any keys/passwords please.

Deleting a folder shouldn't make the script fail as it's designed to create all the folders it needs. What I would do is stop the relevant dockers, stop the script and manually unmount everything (fusermount /mnt/user/mount_rclone/gdrive_vfs and fusermount /mnt/user/mount_mergerfs/gdrive_vfs) and eyeball each folder to make sure they are empty. I would then manually run just the rclone mount command as I think when you were trying to get up and running, you created another gdrive_vfs folder by mistake that you don't need - the script isn't doing it. If so, delete it. rclone mount gdrive_vfs: \mnt\user\mount_rclone

We can't really help you if you don't post your scripts or your logs

Yes, files older than 90 days. Mergerfs handles all the upgrades. If it's a local file it just replaces, if it's in the cloud it deletes the cloud version and puts the new copy in the local folder for upload.

sorry, no idea what's going on there and I've no experience of Debian. Somebody else might help you though!

Thanks - that fits my scenario perfectly as my other non-cache pools contain pool only shares.

I'm not sure if gdrive based mounts have the same performance issues, but once a certain number of files are stored the IO performance of tdrives starts to degrade - there's a post in here somewhere from @watchmeexplode5 where he did some testing. One of the advantages of moving to a tdrive, is once you've setup your first one it's easy to create multiple tdrives so that you can spread out your files.

If only the cache pool has shares that are set to yes or prefer, and the other pools are set to Only, will it work?

Nothing jumps out to me as looking wrong. @Kaizac @watchmeexplode5 ????

I haven't come across this problem before - I think because I was moving my music mtdrive-->gdrive. You're welcome. I'm happy to share as I'm sure it's saving people $$$ in drives etc.

I think it's because you are using the remotes that decrypt the files - you need to use the 'raw' remotes that process the encrypted files i.e. rclone move tdrive_upload:crypt/**************************fk40rft2t0t7neqvb9hi7psvm8cg" "tdrive_movies_bio:crypt/*********************7neqvb9hi7psvm8cg" because you are moving the files server-side i.e. encrypted.

I mount them all in separate folders - sorry if I put them all in the same folder in my write-up - that's a mistake. Re navigation, it shouldn't matter as you should never ever need to use or visit the rclone mounts unless you are troubleshooting - the mergerfs folder is the only one you use day-2-day. Sounds like you got it working then?