Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Thel1988

  • Rank
  1. I get the same issue, where I need to kill of rclone and reconnect the mount points, rerunning the script does nothing to fix that error.
  2. Have you checked which version of rclone you have installed? You need at least 1.51 to support the order by function.
  3. Interresting way of doing it by date actually, if you share a bit more details on how you do it, that would be nice isn't there a limitation on how much you can move between drives?
  4. Yeap I have been cloning and merged it with my settings, and it is like this. But it kind of make sense from my side: This is the output of my find command (before cut) /mnt/user/appdata/other/rclone/Upload_user1_vfs/counter_2 Correct me if i'm wrong, I have been reading into how the CUT command is working: cut -d"_" -f4 the -d"_" will tell it what delimter it should, and after that which field it should output, in my example above. field1: /mnt/user/appdata/other/rclone/Upload field2: user1 field3:vfs/counter and then field4: 2 So in my example it will be -f4
  5. Thanks this works great, I still need to adjust the cut command to 4 as it is my fourth field, but really cool on the simplification of the scripts: find /mnt/user/appdata/other/rclone/upload_user1_vfs/ -name 'counter_*' | cut -d"_" -f3 Give this output: vfs/counter Changing the cut command to use field number 4 it outputs it correctly: find /mnt/user/appdata/other/rclone/upload_user1_vfs/ -name 'counter_*' | cut -d"_" -f4 2
  6. @DZMM Good additions to your scripts Got one question though about the mkdir -p command in line 60, i can't find anywhere else, where the $RcloneUploadRemoteName folder is created in the upload script, is it me who is reading it wrong? As it seems the $RcloneUploadRemoteName subfolder is being Touched.
  7. I just wanna say, Thanks @DZMM for the new versions of the scripts combined with the multiple upload accounts, it is just making my life so much easier Just a little tidbit, if you use the multiple upload feature, and use more than 1 "_" in your remote name, like i did, change the CUT command from field 3 to field 4 from: find /mnt/user/appdata/other/rclone/name_media_vfs/ -name 'counter_*' | cut -d"_" -f3 to: find /mnt/user/appdata/other/rclone/name_media_vfs/ -name 'counter_*' | cut -d"_" -f4 If you don't do the above, it will not rotate the accounts
  8. Okay I got it to work I needed to delete the extra /media/downloads in the path mappings and then it works Anways thanks for your help @DZMM you do a fantastic job on these scripts
  9. Okay good Point. I have changed to this: Radarr: /media/downloads <-> /mnt/user/mount_unionfs/google_vfs/downloads/ /media <-> /mnt/user/mount_unionfs/google_vfs/ for sabnzb: /media/downloads <-> /mnt/user/mount_unionfs/google_vfs/downloads/ It is still awfully slow, does the cache settings on the local share have anything to say on this?
  10. I have migrated from the unionFS to MergerFS, but it seems I have very very slow move speed from like sonarr or radarr to my Media folder. (Taking 3 minutes to move 4 GB file), so i think it is somehow Copying instead of Moving. Also if I do the same thing from within the Sonarr docker it also takes this long to MOVE a file. I'm using the following MergerFS command: mergerfs /mnt/user/local/google_vfs:/mnt/user/mount_rclone/google_vfs=RO:/mnt/user/media=RO /mnt/user/mount_unionfs/google_vfs -o rw,async_read=false,use_ino,allow_other,func.getattr=newest,category.action=all,category.create=ff,cache.files=partial,dropcacheonclose=true It seems sonarr is really taking long time to move from the /data to /media in the Sonarr docker. Path mappings: /data <-> /mnt/user/mount_unionfs/google_vfs/downloads/ /media <-> /mnt/user/mount_unionfs/google_vfs/ I can see that the SSD cache is hard at work when it is moving files.