fazza

Yeah, it would be.  It would mean that there would be no reason to set the threads manually, as the software could manage this.  Increase the threads when there was more data to upload (or download) and back off if it's getting throttled or doesn't need as many threads.
 
The problem is, while this sounds simple and easy .... the simple and easy stuff tends to be some of the most complex code.  That's been a theme for all of our software, and ... kind of a running joke internally ("well, that should be simple! ... six months later", and the like).
 
So... while we do plan on implementing it in the future, we definitely have no ETA, and have no idea how difficult this will be until we start to implement it.
 
 
 
 
As for your system, I see a couple of issues.  I see some bugchecks (crashes) that may indicate memory issue (though may be other issues).
Additionally, I'm seeing some issues related to the Credentials manager, which is part of how we store provider info. As well as some other issues.
 
I'd really recommend running a memory test on the system, and then follow that up with "chkdsk c: /f" and "sfc /scannow" (both from an elevated/administrative command prompt).  
 
If that doesn't help, then let me know.

Well, the first part, I have a solution for that.  I have the same issue on my systems .... so, I found this out a while ago.
 
If you mount the drive to a folder path (eg, C:\Pool\Drive#), you can still manage the drive in BitLocker without assigning a drive letter, and without having see the drive all the time.
 
http://wiki.covecube.com/StableBit_DrivePool_Q4822624
 
You still have to go into the management page for it, but it may help out here.
 
 
 
 
As for the auto-unlock, I do have this enabled on my system.  The system drive is encrypted, and I use a TPM module.  The thing is, even if the drives are automatically unlocked, this ONLY works on the system in question. If you pull the drives and put them into a new system, you need the password or recovery code to unlock the drive.  
 
Additionally, as long as all of the accounts are password protected, there is no way to break into the system (or at least, it becomes incredibly difficult).
And if your motherboard supports a TPM module, you can install and configure this, so you don't need a key or password for the system.
 
In fact, this works well enough that I've joked that if a friend could break into my system, that they could keep it.  And I have a few security admin friends.  I'm still typing on said computer.

I would agree with Chris.  With Clouddrive's ability to only upload changed sectors really makes this a good solution if you want a VeraCrypt container on the cloud.  I've tried this in the past with Google Drive's desktop app and Truecrypt.  I ended up re-uploading the file over and over...or so it seemed way back when I was trying this.  So, I gave up on that for a while (at least until CloudDrive showed up!).
 
Love this piece of software / middleware!  I've off loaded all my most precious files (pictures of the kids, and other unique files that I would never be able to get back if my house were to burn down).  It would be nice to mirror my entire DrivePool...but I can not see dumping THAT much data over my shoe-string internet connection.  Funny thing to me, I used to think I was fast....but then again, I can still recall the tones used on 300baud modems up to 14.4kbaud!  Then the digital bongs of 56K (I skipped 28.8kbaud).

Yeah, definitely simple.  And it works very well.
 
Though, if you really do want an encrypted container (a la truecrypt), then StableBit CloudDrive does still work for that, and well.

Way simpler than I thought. Guess I'll leave clouddrive for the actual cloud stuff.
 
Many thanks for the help.

Hi, just started to use Clouddrive and am trying to get used to what it's capable of. I have a couple of questions to check my usage of the product and it's capabilities. Any insight would be appreciated.
 
First, I have created a 4tb cloud drive spanning multiple (9) providers and pulled together with DrivePool to create a single large volume. On this pooled cloud drive just created, I notice there is over 1gb of data to be uploaded - I presume this is some form of metadata required by Clouddrive, and is expected behaviour? If so that's fine, but I was expecting an empty drive to not need any uploading - it may be worth flagging this behaviour for bandwidth constrained users like myself.
 
Next, I would like to create a local encrypted drive using drivepool and clouddrive together. There will be a dedicated drivepool on which the encrypted volume will go. Once the volume is created by clouddrive (using local storage provider option), can I then remove the drive letter from the pooled drive and use only the clouddrive created drive letter?
 
Thanks in advance.

Yup, NTFS metadata, as well as partitioning information, folder structure and other "hidden assets" on the drives are likely being uploaded. 
 
You mean storing an encrypted "drive"/container on the pool, and using that? 
 
 
If so ... that's a bit redundant, to be blunt.  Each CloudDrive disk supports encryption (enabled at the time of creation).  And that should be more than sufficient.   Additionally, you can then enable bitlocker on each of the drives, as StableBit DrivePool supports that, as well. 
 
 
So, unless I'm missing something, you're essentially trying to add significant complexity to your setup, where it's not strictly needed. 
 
 
 
That said, I'll have to double check, but I'm pretty sure that StableBit CloudDrive does want/need a drive letter for the local disk provider (and cache)

Thanks. The remeasure did not change anything but after a reboot it is now reporting usage correctly.
 
I'm really pleased with the software - does exactly what it says on the tin with absolutely no drama and is usable for a relative novice like myself. And the support gives me a lot of confidence moving forward.
 
Apologies for the stupid questions, and thankyou very much for the help