DZMM

oh, i see what you mean. Yes i have separate unionfs mounts for say movies/kids and movies/adults - you just need a cleanup for each of your unionfs mounts

Looks like you've got your radarr docker mappings wrong and maybe you're missing a '/' for /Cloud/Movies/. Or, have you not mounted /CloudMovies RW slave? Edit: Just seen in previous post you got it sorted

Yes, it works as normal. Unionfs hides old files in the mount i.e. they still exist on google, but sonarr and radarr can't see them. If you want to actually delete them, which is a good idea because if you change your mount settings or rescan the google folders for whatever reason it will pickup these files, then you need to do this:

Yep. My family are going away next week so I'm going to experiment with mounting unionfs at /mnt/user/rclone_vfs/movies rather than /mnt/disks/rclone_vfs/movies to see if file write speeds improve/hardlinking is supported etc if you just mount gdrive does it work? Try putting a pause in - I've added a 5s delay between mounting gdrive and unionfs as I had similar problems. Not sure what the permission errror are

I've: increased chunk-size-limit and buffer-size to 2G as I'm more confident now that I've got enough memory after running for a few weeks now deleted umask 002 as being honest I don't know what it does removed --bind as I don't think it's needed for my setup removed --cache-dir and --vfs-cache-mode as this is only needed if you write files direct to the vfs mount, which I don't - I use a scheduled rclone move job rclone mount --allow-other --dir-cache-time 48h --vfs-read-chunk-size 32M --vfs-read-chunk-size-limit 2G --buffer-size 2G --log-level INFO gdrive_media_vfs: /mnt/disks/rclone_vfs --stats 1m I'm tempted one day to try --vfs-read-chunk-size 64M as sometimes I have to start a file twice, which I think is because it doesn't have enough info to start playing the first time. The trade-off is my start times might be a little longer

Unionfs merges the upload folder and the Google folder. When sonarr tries to add a new file, it is actually written to the upload folder not the Google folder - when you move it to the Google folder, to sonarr it looks like it hasn't moved as sonarr is looking at the unionfs folder. Radarr/sonarr etc should be pulling files in from sab/nzbget etc, not sab writing directly to your media folders

You point them to your unionfs folders, that merge what's been uploaded with what's local

seems to be working now - I've done a few restarts with no errors. Will monitor

@Squid I had a window to reboot - no joy with docker stop -t 60 deluge. I tried moving docker and the appdata back to my cache from UD. At least moving docker and appdata back to my cache let me edit dockers without losing the whole image. Logs attached - nothing looks wrong in there. deluge.log

I think this is my problem. I've noticed since I moved my appdata to an unassigned drive, I've had problems stopping and editing Dockers e.g. if i don't stop before editing, after editing I could lose the whole image i.e. I can't even go back to CA and just restore, I have to re-create from scratch. Will do the delige stop test when I can, but I think I might have a bigger problem - I'll also try running from my cache to see if that removes the problem. Edit: Just realised I meant docker not appdata - will try moving docker image back to my cache drive as that's easier

Thanks - I'll have to try this maybe tomorrow/Monday. I've just created a fresh docker instance just in case some weird plugin settings etc were causing problems, so I'm re-adding my old torrents by rechecking.

I'm hoping someone has a fix for this. Whenever I restart the docker, several of my torrents will have Errors requiring rechecking. It's very annoying as it can take a day or two if it's a very large torrent. Does anyone else have this problem? Here are my mappings - appdata is set to R/W Slave on an UD. Thanks in advance for any help

It seems to

I'm confused by this one. According to this thread partial scanning doesn't work with unionfs mounts, but it's working fine for me and new files are showing in plex as soon as sonarr/radarr notifies plex https://forum.rclone.org/t/plex-with-rclone-mount-possible-to-auto-update-partial-scan/5525

Thanks - I noticed whilst gather is running it shows the rsync command, so I'll just add those to a script

Won't bore you with the reasons, but limiting a share to a disk doesn't work in this scenario. I could probably figure out how to use rsync, I've just never used it before and I'd rediscovered this plugin this afternoon

hi is there a way to schedule a job? I have seeding torrents I like to group on one disk periodically to reduce the amount of disks spinning. It'd be great if I could I could run the same Gather on a schedule in a script. Thanks

Up to you - depends on how much you are going to write to the mount rather than via a background upload job. I don't currently write direct to the remote mount, so I've just dumped it somewhere for now.

So far I've moved all of my tv shows and a good chunk of my movies. At first I selected the less important ones by moving to a new share that rclone watches and uploads from and is part of the unionfs folder, but now I'm going to focus on the smaller, less important ones so there's less chance of something going wrong. I'm not too worried about uploading more important ones though as I'm sure if Google scupper the setup there'll be time to download my content if I want to.

I'm currently trying: rclone mount --allow-other --dir-cache-time 48h --vfs-read-chunk-size 32M --vfs-read-chunk-size-limit 1G --buffer-size 1G --umask 002 --bind 172.30.12.2 --cache-dir=/mnt/software/rclone/vfs --vfs-cache-mode writes --log-level INFO --stats 1m gdrive_media_vfs: /mnt/disks/rclone_vfs - 32M to try and speedup library updates. Launch times seem unaffected - worked out that --cache-dir is where files go before they are uploaded that are written direct to the remote. Moved away from ram - set buffer and read-chunk-size-limit to 1G, so for my max 4 concurrent streams I'll use a max of 8GB of RAM. Anymore than that and I should have enough ram spare for 1 or 2 more streams. If not, hopefully the swapfile will kick in - think it'll be rare I'll have 6 streams just from my online content

ok, I did a quick test on a 35GB file. - I tried --vfs-read-chunk-size 128M --vfs-read-chunk-size-limit 2G --buffer-size 256M first to test my larger chunk size theory and I had the same problems as you. The device I was using was transcoding the audio but it was running at less the 1x, so I had stutter - I then tried --vfs-read-chunk-size 64M --vfs-read-chunk-size-limit 2G and everything was perfect. Audio transcoding easily over x1 and got throttled in the end - good I'll try my previous --vfs-read-chunk-size 64M --vfs-read-chunk-size-limit 1G later - I can't now as the family are watching the film I was testing. I haven't tried that particular film before on those settings, so it'll be interesting to see if the 2G was the fixer - if all is good even with 1G, I'm going to stick with 2G anyway and also trial 32M. Some of the users over on rclone are using 32M so I'll give it a whirl - I hadn't bothered as 64M was working in all the tests I've done so far.

maybe try --vfs-read-chunk-size 128M at the start as well. My theory is it starts playing once it has the first chunk, so for bigger files maybe the first 64M chunk (and maybe the second at 128MB) is too small? Edit: it might slow your launch down a bit though - dunno

hmm will try a big file myself tonight, but I haven't had any problems after running for a few weeks. Does it start skipping at the start or the beginning? Direct play or transcoding? What's your linespeed? You could try bumping chunk-size-limit up to 2G, which most users on the rclone forum seem to have. I've gone for 1G as I'm being a bit cautious as 2G for each concurrent stream could melt my machine at the moment as it's doing a lot of jobs e.g. 8 x2G = 16GB of ram used. Also maybe try vfs-read-chunk-size of 32M. Other users have this lower amount, but I can't see why as it almost seems like a wasted chunk request to me. I think 128M might be a better size if you're stuttering at the start. BTW the --cache-dir=/tmp/rclone/vfs bit definitely isn't needed - just me being cautious again.

Don't you get errors not mounting at /mnt/disks? Anyone else mounting at /mnt/user? I might give /mnt/user a test again as maybe something else was causing the problems I was having Edit1: I think I was getting errors because I was mounting at the top-level folder rather than a sub-folder i.e I should try /mnt/user/unionfs/fuse_folder_here not /mnt/user/fuse_folder_here Edit2: Yep, mounting to subfolder in share rather than top-level doesn't throw up an error. Hopefully this will mean I can hardlink files now!

It's fine