testdasi

You untick that partial scan option. On the main library page, hover your mouse over Libraries, there should be a button that when you click shows the various options, among which is rescan plex library (or something like that). Click on that to manually rescan. It is good practice to have each movie in its own folder under a main Movies folder e.g. Movies\Movie 1 Movies\Movie 2 etc. I don't use Radarr but I think it does all the organisation for you so that's a faster option if you know how to use it. I organise things manually but have always done that for years.

I think it's a perfect storm kind of situation. My French is terrible but I'm guessing you set it up to scan on partial change? When you are uploading files to gdrive, every little change will cause a scan of the folder. You have all the movies in the same folder, that probably means Plex will rescan the entire folder, including files that were not changed (it doesn't know what has been changed, just that something was changed so it has to scan to know). You might want to disable automatic scanning and do it manually while you reorganise your library.

Something is making too many API calls to cause yours to be blocked. You need to check what your various dockers are doing. From previous posts, it looks like Bazarr and Emby / Plex subtitle searches may be the main contributor. I run Plex and Sonarr refreshes a few times today already + calculate how much space I'm using (a lot of API calls to count things) and I'm nowhere close to the limit. Even the per 100s limit of 1000, I only get to 20% on the worst day. So your dockers must be doing something very drastic to cause API ban. You might want to separate that docker on its own client_id. Once banned, there's nothing you can do but to wait till your quota is reset. Usually reset time is midnight US Pacific (where Google HQ is). (You can see when it's reset and how many API calls you have done from your API dashboard - https://console.developers.google.com/apis/dashboard then click on quota) That is assuming you have set up your own API + OAUTH client_id + share the team drive with the appropriate account.

If I change the rclone conf (e.g. point account to a different Team Drive), how do I make rclone remount? I tried the unmount script, which unmounts the tdrive but I can still see the rclone process running (i.e. it only unmounts, it doesn't actually kill the rclone processes with the old config). I have been restarting just to be safe but just thought to ask if maybe there's something I have done wrong.

I have an autoboot script that automatically starts my VM and dockers in the right sequence (for better NUMA memory allocation and docker dependencies etc.). The funny thing is if I set it as run at array start, it gives me error that it can't communicate with virsh and docker (i.e. the services haven't started yet). However, if I set it to run at FIRST array start, it runs perfectly fine. I even tried to make the script wait x amount of seconds and went as far as 5 minutes and it still had the same can't comm with virsh and docker error. Maybe the script blocks the docker and virsh services or something? It doesn't affect me much (I typically don't restart an array without reboot) but just thought to report it.

It's admin / password. I just tried. To be honest, prefer jdownloader2 as I can use multiple proxies.

Thank you. It has gone 800+ GB already without any error so looks like the step 2 was indeed the step I missed. I'm running a script to sequentially go through 4 subfolders of 700GB each. My current connection means I can only go through about 3 folders/day so I should not be reaching the limit on any of the account. Your control file logic gate was quite elegant so I repurpose it to make my script run perpetually unless I delete the control file. I just need to "refill" daily and forget about it.

Stupid question: does it work cross platform? e.g. Linux docker detecting Windows / MacOS viruses?

Hey! I think I figured out what's wrong! When I do rclone config with the authorise link, when the sign in screen comes up on the browser, I clicked the main account because I can't see the team drive if I click on the account corresponding to the client_id. So your step 2 looks to be the step I missed. When I add the other accounts as content manager, I can now see the team drive if I click on the account corresponding to the client_id. Just did a test transfer for all the accounts and the activity page shows the actions on the corresponding accounts. I just kicked off the upload script and we'll probably know if it works by dinner time! Don't use Krusader to check. It somehow also doesn't show unionfs correctly for me too. MC works, sonarr works, Plex works, Krusader doesn't. Use mc from console is the most reliable way to check the mount itself. Cut out the docker-specific problem.

1. Yes. 2. You split this point 2 and point 3 so perhaps I have missed something here. By "shared" do you mean also adding those emails to the Member Access on the Gdrive website e.g. making those email Content Manager? Or maybe something else? 3. Yes. What I did was having each unique email + create a project for each (unique project names too) + adding Google Drive API to project + creating unique OAUTH client_id and secrets for each project API and use those for unique remote. 4. Yes (see below for section of conf) 5. Yes. I noticed you have --user-agent="unRAID" which I didn't have so will try that this morning when my limit is reset. A question: when your unique client_id move things to gdrive, does the gdrive website shows your activity (click on the (i) icon, upper right corner under the G Suite logo and then click Activity to show activity) as "[name of account] created an item" or does it shows as "You created an item"? (as in literally it says "You", not the email address or your name). For me it shows as "You" regardless of upload account so maybe that's an indication of something being wrong? .rclone.conf [gdrive] type = drive client_id = 829[random stuff].apps.googleusercontent.com client_secret = [random stuff] scope = drive token = {"access_token":"[random stuff]","token_type":"Bearer","refresh_token":"[random stuff]","expiry":"2019-06-16T01:51:02"} [gdrive_media_vfs] type = crypt remote = gdrive:crypt filename_encryption = standard directory_name_encryption = true password = abcdzyz password2 = 1234987 [tdrive] type = drive client_id = 401[random stuff].apps.googleusercontent.com client_secret = [random stuff] scope = drive token = {"access_token":"[random stuff]","token_type":"Bearer","refresh_token":"[random stuff]","expiry":"2019-06-16T01:51:02"} team_drive = [team_drive ID] [tdrive_vfs] type = crypt remote = tdrive:crypt filename_encryption = standard directory_name_encryption = true password = abcdzyz password2 = 1234987 [tdrive_01] type = drive client_id = 345[random stuff].apps.googleusercontent.com client_secret = [random stuff] scope = drive token = token = {"access_token":"[random stuff]","token_type":"Bearer","refresh_token":"[random stuff]","expiry":"2019-06-16T01:51:02"} team_drive = [team_drive ID] [tdrive_01_vfs] type = crypt remote = tdrive_01:crypt filename_encryption = standard directory_name_encryption = true password = abcdzyz password2 = 1234987 etc... rclone move command I have a command for each of 01, 02, 03, 04 and a folder for each. I ensure that each 0x folder has less than 750GB (about 700GB). rclone move /mnt/user/rclone_upload/tdrive_01_vfs/ tdrive_01_vfs: -vv --drive-chunk-size 512M --checkers 3 --fast-list --transfers 2 --exclude .unionfs/** --exclude *fuse_hidden* --exclude *_HIDDEN --exclude .recycle** --exclude *.backup~* --exclude *.partial~* --delete-empty-src-dirs --fast-list --bwlimit 110000k --tpslimit 3 --min-age 30m

Everything works, except for some reasons I am limited to 750GB / day total. Once 1 teamdrive hits limit, everything else (main gdrive + the other tdrive) is errorred out too. Same situation, once 1 client ID hits limit, the rest (6 IDs) are blocked. @DZMM: Looks like my daily limit is enforced even more rigorously than when you reported back in December 19 last year. But then it seemed to have been lifted for you out of a sudden based on the December 23 post and our recent PMs. Do you remember making any particular changes? My setup is pretty similar to yours except for having fewer client_IDs and I have only been using tdrive basically exclusively (gdrive only for testing purposes).

Oh wow, that's great! Just to double check, that's their Business GSuite right? What about the domain name requirement mentioned by DZMM?

Does this only work with vdisk image? Would it work with a passed-through sata ssd (via device-id)?

How did you get "unlimited cloud space"? I thought it's only 2TB.

Best ports, in decreasing order of "best-ness": Internal USB 2.0 ports. You can buy a cheapo USB2.0 internal to external adapter (basically a small little cable with internal USB 2.0 plug on one end and external USB2.0 socket on the other) and plug the Unraid USB stick on there. Alternatively, you can use your case USB2.0 header or some all-in-one USB2.0 internal hub. Reason for "best-ness": (1) USB2.0 has the least compatibility issues when booting (almost none); (2) few people have any other use for internal USB2.0 headers and (3) the USB2.0 motherboard controller can't be passed through to a VM even with ACS multifunction (many have tried and many have failed). Internal USB 3.0 ports. Similar to USB2.0 above, just that USB3.0 ports sometimes have boot issues. External USB 3.1 port (the red one at the back). This port can't be passed through to a VM similar to the internal USB2.0 port but give it's externally available, you might want to use it for some other purposes instead of booting Unraid (about 10s saving in boot time and that's it). External USB 3.0 ports (the 8 blue ones at the back). These are on their own controllers (2 controllers, 4 ports each) and in their own IOMMU group so they can be passed through to your VM with ease (need vfio stubbing). Note that they have identical IDs so if you stub 1 controller, you will end up stubbing both (I vaguely remember there's a way around that so you might want to google if required). USB 3.1 type C - because why would want to do that? Highly NOT recommended to overclock Unraid. Instability on a server is at best a nuisance (e.g. needing to run Parity check whenever things crash) and at worst causing crippling issues (e.g. data corruption). You are better off to use AMD Precision Boost. It's an effort-free per-core on-demand overclock. Sure all-core boost can only reach 3.8GHz but that's only 5% lower than your best-effort overclock that more likely than not is less stable and definitely uses a lot more power. On a side note, don't use the latest BIOS (AGESA 1.1.0.2), use the one right before that (AGESA 1.1.0.1a). The current BIOS has AMD PB cut down a little bit on the voltage which runs 1-2 degrees cooler but has caused me some unexpected stability issue with certain workloads.

You misunderstood my point. It doesn't matter if Plex is accessing the idle drive or an active drive, the fact that the CPU is waiting for the drive to respond will exclude other activities. Think of it like this: Mover tells CPU: write file 1 to disk A CPU: ok, writing Plex tells CPU: read file 2 from disk B CPU: nope, writing Plex: are you done yet? CPU: nope, still writing Plex: are you done yet? CPU: nope, still writing Plex: are you done yet? CPU: nope, still writing Plex: are you done yet? CPU: nope, still writing Plex: are you done yet? CPU tells Mover: ok, file 1 written to disk A CPU tells Plex: ok, here is file 2 from disk B The entire time from step 4 to step 13, CPU will report 100% usage because it is fully occupied with writing. Yes, we can talk all days about how it is supposed to be multi-tasking in 2019 but the truth is some action requires the CPU (core) full attention and until it's done, it won't be able to do anything else. This is the same reason that if you plug a failing drive or SD card to Windows, it will hang the entire system while trying in vain to read the data.

Wrong place to ask, mate. You are asking about VM stuff and this topic is about the plugin.

ALL containers becoming unresponsive is a different problem. As I mentioned, when the CPU is waiting for the drive to respond, it will report 100% usage, regardless of how powerful your CPU is. A slow-responding drive will cause what you are seeing. In terms of why a drive responds slowly, it may be due to high IO (e.g. repairing + extracting + copying strain a HDD a lot due to repeated seek) or even a failing drive (that was what happened when my old Hitachi 3TB was about to kick the dust).

What is your core pinning for Plex? Try not using core 0. I noticed Unraid mover tends to use core 0 almost exclusively so if Plex (or any other CPU-intensive docker) uses it (e.g. streaming), it would lag both regardless of CPU. It has nothing to do with how powerful your CPU is. When it's stuck waiting for a response from a drive (which is slow) due to the mover, it will not be doing anything else and report 100% usage.

I think the summary of this plugin is, unless you are a spy, use it. (based on Unraid functionalities, I doubt there's any financial institution or cloud / VM provider using it)

Just a small suggestion. The "Enable Intel Turbo Boost?" affects AMD CPUs too e.g. my 2990WX will only turbo up i.e. Precision Boost with that flag = Yes. So I guess maybe change that to "Enable Intel Turbo Boost / AMD Precision Boost?" may help some folks out there.

2 thumbs up from me Maester Squid. Just installed and will reboot as soon as this render is done.

Updated from... wait for it... 6.5.3 with no issue! Glad to see the GUI whiners are still whining while I resolved my previously inexplicable lag problem with 6.6.0+ on my own and now get to quietly enjoy the new GUI. #smugface

According to ASRock spec, the bluetooth module is part of the Intel Wifi card so you will need to pass through the Wifi Card (it's a PCIe device) and see how it goes from there. It's probably in the same IOMMU group as the Intel Wired LAN so I'm pretty sure ACS Overide is needed.

I would hypothesize that your motherboard reports the core incorrectly as a "display problem". i.e. underlying it's still 0 + 1 = 1 pair. Hence when you assign all the odd cores, you effectively running your VM in non-SMT mode (e.g. 16 non-SMT = 16 physical cores > 16 SMT = 8 physical cores). I made the above educated guess based on the fact that I see the exact same result i.e. assigning odd cores to VM gives me better performance. I think we'll need to have the right expectation. This is not a magical cure. Assigning all cores in the same die would only improve latency (assuming memory allocation is also to the same numa node). The processing power of a core (+ its SMT sister) doesn't change. If your workload scales well with multiple cores (e.g. transcoding), having more cores spread across multiple dies will almost always help more than having fewer (physical) cores trying to ring-fence the process within the same node. If your workload doesn't scale well and/or is bottle-necked by a pass-through device (e.g. gaming) then you will benefit from better consistency of performance (e.g. less stuttering i.e. more consistency fps) by ring-fencing the node with the connected device. What we lacked previously is the ability to make educated tuning for the 2nd use case.