DZMM

what abuse are you referring to? I don't see where anyone is breaking any of Google's T&Cs. If you're referring to the user agent change, that was temporary and was reverted I'll ignore the point about abuse, but again has this best practice advice come from Google???? How many people store a 'large' amount of media data on Google I don't know and until Google say it's a problem, I'm not going to change my behaviour and stop using the very generous unlimited storage to store my media, backups and personal files. When you consider the billions of people who use Google, I imagine this is a drop in the ocean compared to the total amount of data stored and over time the cost/GB (and remember Google's £/GB isn't the same as ours) will continue to fall and cloud storage will become the norm for all. Can you please start a new thread if you want to continue discussing this, as this is a support thread for sharing ideas on improving plex and rclone support.

But - the checker files are created and removed by a script. Just because they aren't there, doesn't mean rclone isn't running - sleeping for a combined 20s isn't going to fix hangs

Yes. If you're worried, copy a couple of movies or episodes and watch the activity.

Yes.

That wouldn't work for me. It can literally freeze and not shutdown and I need to do a hard shutdown. It's the main reason why I don't reboot often - e.g. last month I got a disk error from a hard shutdown, which was painful to fix. Sometimes it's seamless - I actually think there's something in 6.8.x that causes the problem.

post your rclone config please.

Nothing gets added to mergerfs - it's a virtual share. If it appears to be on disk 3 that because you've set it to disk 3 in your share settings, but nothing actually gets added there. If what you're asking is for your local files to go on disk 1 or 2, then set /mnt/user/local to disk 1 and 2.

Like you I don't restart that often. It seems to go through cycles where it stops ok, and others where it hangs. It seems like we've eliminated upload jobs and stopping the mount - maybe it's mergerfs and we need to stop the docker (and probably the dockers trying to access the mount) first?

Remove --RC from one of the mounts - you can only do this once, which is why you can only mount whichever one runs first.

post your mount script settings for each remote.

All your problems are because your mount script should have: LocalFilesShare="/mnt/user/local" not: LocalFilesShare="ignore" ignore is saying you don't want a mergerfs mount. So, what's happening is nzbget is writing direct to the rclone mount i.e. direct to gdrive, so I imagine it will be very slow and cause problems! LocalFilesShare2, LocalFilesShare3 and LocalFilesShare4 are the ones you want 'ignore' for if you don't want to add extra paths to your mergerfs mount. Edit: Your docker mappings are correct i.e. to /mnt/user and then within the docker to mount_mergerfs. You just need to fix the mount script. Easiest way is to correct the settings, stop all the dockers that are trying to add new or move files or are accessing the mount e.g. plex, then re-run the script and then start the dockers.

--buffer-size in the mount script. What client are you using and is it the same for all? I've read in the past that iOS keeps opening and closing files which can cause problems. Yes, so I don't think mergers was the culprit. Browsing the mounts is perceptively faster so I think the fault was Google's or rclone's.

oh and also make sure that dockers' paths are all pointing to paths inside the mergerfs mount, not the local path. You should only ever have to use the local path in special circumstances

The trick is to ensure that sab/nzb/deluge etc are all in alignment with radarr/sonarr etc to get hardlinks support. So you need wherever your download clients are downloading to, to appear to be on the same drive when radarr etc look at it i.e. it's the docker mappings that count. To make this as easy and foolproof as possible, ALL of my dockers have the same mappings: - /user ---> /mnt/user - /disks --> /mnt/disks Just these - nothing else. So, that no matter what paths I use within dockers, they will always appear as being on the same 'drive' for inter-docker moves, and I get the maximum file transfer benefit. I.e. for you within Sab, you would download to /user/downloads/sabnzb via Sab's settings. Radarr would look at /user/downloads/sabnzb (same /user mapping) and then move the files to /user/media/movies/whatever i.e. everything 'stays' in the 'user' drive.

The mount script is supposed to create the file - hopefully you won't have this problem again.

Is initial playback faster? You could try increasing the buffer size

The script is looking for the mountcheck file and failing. Can you post your mount and upload settings please

Ok, I've finished splitting my movie & tv teamdrive into 3 and I can testify that performance is better with launch times back to around 3-4 seconds, whereas before they were at times 10+ seconds. I don't know when the tipping point is for creating extra team drives - I'm sharing my teamdrives to see if we can figure it out. I've got 3 now: - Main: rclone size tdrive_vfs: --fast-list Total objects: 66914 Total size: 258.232 TBytes (283928878628609 Bytes) - Adult TV: rclone size tdrive_t_adults: --fast-list Total objects: 55550 Total size: 118.501 TBytes (130292861122569 Bytes) - UHD (TV & Movies): rclone size tdrive_uhd: --fast-list Total objects: 4706 Total size: 69.986 TBytes (76950733274565 Bytes) and an extra rclone mount for music that isn't in a teamdrive: rclone size gdrive: --fast-list Total objects: 95393 Total size: 4.418 TBytes (4857512752388 Bytes) I've only got a total of 223K objects (451TB) but I think my experience proves it's not worth adding anywhere near the 400k limit if you want good performance. I might create a 4th teamdrive and move my kids movies and tv shows to a new teamdrive to see if that knocks another second or two off launch times.

gdrive has no 400k limit so I'm using for my music. I've just setup 2 extra teamdrives - one for UHD content and one for my grown-up TV (not kids). The UHD server side switch went ok although the larger tv one is a bit worrying - I can't see the files on google, but the move has happened on the mount and plex is still playing everything (although appearing in both the source and destination)! It's a fair few TBs so I assume google will catchup soon....

Ok, I'm going to split out my 4K content to start with (easiest) and then some of movies to see if that helps.

@Bjur I recommend you have just one mergerfs mount and add the second rclone remote as an additional local folder - I think I proposed this earlier (can't remember). I do however take a slightly different approach for my music which would push my tdrive over 400K because of all the tracks and folders - I add them to my main tdrive, but then do an overnight rclone move to gdrive where there's no object limit. Now that is interesting! I've noticed that navigating plex and launching files has been slow of late and I'm wondering if this is the cause. At the moment I have all my movies and tv shows in one tdrive - I think the time has come to create a couple more. Do you still aggregate your remotes into one mergerfs mount or do you have multiple mergerfs mounts?

My suspicion is it's a pending upload, but again I've never bothered to investigate.

@Bjur if you want to upload to different locations you need multiple instances of the script.

The latest version of the script supports move, copy and sync. I'm not really understanding what you want to do. If you to point an encrypted remote the to same folder on gdrive, just do that in rclone config i.e. [remote1] type = crypt remote = gdrive:crypt [remote2] type = crypt remote = gdrive:crypt

RcloneCommand="sync" (better) or RcloneCommand="copy" Another script You could get API bans for other reasons, so a good idea to isolate your remotes