ironhead65

Chris, Thanks! I'll check this out soon. For now, I just removed all the BOX drives and it seems to have made everything happy again. It could have also been causing a LOT of pool inconsistencies (where formatting or just purge and re-add was the only way to "fix" the Drive Pool issues with these cloud drives). I cannot be certain, as I never saw "I did this thing" then Drive pool went wonky. So, I have not posted about it. For now, I have been using ONLY Google Drive and removed ALL other drives. That means my space dropped quite a bit, but I see with only 11 drives (as few SMB as well), my processor use has dropped from being pegged to 100% for DAYS on end, to rarely getting over 10-20%, and when it does, it is for seconds. I think in total, just to push things, I had 44 drives in there. That was unhappy. I am thinking even with the UPLOADS paused, there was something else going on all at the same time? Pinning data maybe? For now, with the 11 drives, I have not had to run my script (which I never uploaded to you as I've found issues when the processor use is HIGH...the script fails in a strange way). Maybe I should post it privately to you just so you can see what I was trying to accomplish (and seemed to help quite a bit)? Thanks!

Hi all, Been experimenting and I think I found a bug, however, I did not want to do anything until I ran it by the community. I have signed up for a Free BOX.com drive. You get 10GB of space. What they did not tell you, is it seems you have less than that. I took a guess that they used hard drive manufacturers 10Gb (not 10gb) and it really was 9.7GB (there abouts). I found this by using this drive in a Drive Pool. The pool got saturated and that drive had over 9.7GB of data. That is, the drive was over 90% full. As Cloud Drive was trying to upload, it seemed to get stuck in a loop. After I noticed that this ONE drive was taking ALL my upload bandwidth, I hit PAUSE though the new PAUSE button. I validated that the settings changed (manage drive -> Performance -> Uploads UNTICKED). I also tried to use the "All drives PAUSE" under the pulldown (upper right Gear). Nothing I did could stop the upload from happening. I was sure this was happening as pulling the ethernet cable from the VM seemed to stop the upload (from the upload speed value being shown). After I plugged the ethernet back in, and a few hours later (I honestly do not know how long it was), I logged back into the machine and looked. I had a message in the message ticker that stated the drive was FULL and the upload attempt failed 260 times. EEEK! I also saw at least 1 other box drive listed in the log. I then tried to STOP and RESTART the Cloud Drive Process. This only seemed to anger other drives (now they had GB of data that was out of sync - this was being addressed in a Cloud Drive thread regarding rebooting and seemingly getting this error, which was brought to a conclusion with a TR/SR being submitted, so I did not bother...well bothering anyone about it). OK, all that aside, this drive was NOT going to stop trying to upload. I then tried a reboot. Still, no change. For a while, I just TURNED it's speed WAY down. That let other drives "catch back up" from the service stop and the reboot. At this point, I now think I discovered the issue. I changed a few settings on Drive Pool to fill to 80% as best it can, instead of 90% (just to be safe). I also mapped my box accounts to drive letters. Then MOVED an appropriate amount of data off to let me use the resize feature and set to 9.7GB. It seems just doing the move has made cloud drive happy and EACH drive that was STUCK like this has STOPPED trying to upload. I have only tested this with box (hence the post here). It might be with all - however there was a pretty long check when I SETUP the Google drives. If I put in a value that was too large, the original drive creation would fail. I would think this is the same with BOX? I am on the latest beta 1.0.2.963 So, has anyone else seen this? Any tips? Is this just BOX? Thanks!

Chris, I just updated to the latest beta...an UPLOAD ALL PAUSE feature! I really slacked and did not send you my script! This is going to make things so nice! I'll add that into my script as the original way, I also validated settings of the performance window. Using the new mechanism will be so much faster! I check for color around the PAUSE button, if grey, paused, if white, not paused. Loop. So much easier than clicking buttons and looking around for a popup! Now, if you have to move things, I only have to adjust 1 thing, VS every button location! Same with color. This might make this easy enough to just check the window size and calculate where the buttons are. This would REALLY make this fancy! This is great!

Chris, I never made the support ticket. I ended up just wiping the drive. Basically what I could determine, the meta files as well as folder structure was different between using SMB and direct drive. That is, you can't just DUMP a drive over a USB connection to say SEED a drive, prior to mailing it to someone else, whom then attaches it to their share network or FTP for your remote use. At least not without hand creating a slew of files and changing the directory structure (the CloudDrive folder on the raw hard drive itself). I could not wait as I needed the drive up and running, so I just wiped it and re-created it...which was a bit painful due to how LONG it took to Bitlock and Encrypt the 1.5TB drive...but it is up and running now. My thoughts are this either should be noted, changed, or an "upgrade" path/conversion tool should be provided. I'm guessing based on what I saw in the meta-data files, the easiest path is to just tell people NOT to do this. For now, I'll seed my drive using a local FTP server. Then I can mail the drive to my remote site and just have them attach over FTP as well (we have a VPN between sites so...ftp is just fine). I'm thinking that the meta data doesn't include THAT much data, where at least moving from one FTP server to another, so long as the folder structure matches, I'll be fine. It is easier to just use SMB, however, I'm thinking because of my shoestring internet, probably better to use something more efficient like FTP. Thanks again for all of your support!

Hi all, It is possible what I did is not valid, so hear me out. I have a local hard drive. It is attached through a DDWRT converted WIFI router. I access this over CIFS (\\<router ip>\share). I tested this out using CloudDrive with drive encryption enabled. Just to check the speeds / performance. Very nice! I was limited by the WIFI link - as expected. Keep in mind, my reason for doing CloudDrives is to get my photos of my kids out of the house in case of fire. I have long wanted to also get the videos of my kids out of the house - but without paying for the service, I cannot allocate that much space. Also, I have a shoestring for internet, so it would take probably until the house DID burn down to get everything uploaded. As I intend to put this 1.5TB drive in my neighbor's house, I thought, why not also toss on Bitlocker? Just playing around - not like this is going to make it ANY more secure. This was taking forever over the WIFI link. My next step was to disconnect the drive and attach it locally to my server. I then re-created the drive and turned on bitlocker. This took a while to finish as the initial encryption of bitlocker usually does. It also means that the ENTIRE CloudDrive was written. So, I have 1.36TB of chunks on that 1.5TB drive. OK great! This morning, I disconnected the "Local" Drive by unplugging the USB (using proper USB eject). Then, plugged the router back in and attached this drive. While I waited for that to boot, I updated the CloudDrive version and reset the server. I got a notification in RED that said it could not reconnect to the local drive. I destroyed the local drive as I do not intend to use it like that again. I tested my DDWRT router connectivity using Explorer. Everything was good. I then added a File Share. CloudDrive was able to connect to the drive. Here is where I am stuck. USUALLY when I reattach existing drives from say Google Drive, or DropBox, if my memory is serving me...I get a menu that allows me to reattach / enter my decrypt key. With the local share, I do not see that. I only get the option to create a new drive. Am I mistaken and I only need to go back through the recreation steps? I do not want to lose what i have (Bitlocker took a REALLY long time!!). What are the steps I need to re-add this back in? I can certainly handle any bitlocker side. I just want to ensure I get the drive attached without wiping it and starting over. If I must, I will recreate it, but again, I'd hate to lose what I did with Bitlocker only because of the time investment. I still do not think it is going to make a difference security wise, and if someone is going to break the AES that CloudDrive puts on there, ok, have fun looking at pictures / video of my kids. Thanks!

Chris, I'll try increasing the minimum Download Size after I resolve another issue (I'll post in a new thread). I've also polished up my script. I'll try to remember to send that over when I get off work later today. Thanks!

Also, I just added 2 more cores to the Virtual Machine. What a piggy...for now, this seems to have REALLY done the most to help any time-outs I was having (above and beyond the LINEAR Upload process). I now rarely see the machine topped out at 100% CPU. When there were only 2 cores assigned to the Virtual Machine, I would see it pegged at 100% most of the time. Now, I get occasional spikes to 100%, but typically sits at 20-30% when uploading...which doesn't make a LOT of sense to me, as with 2 cores I would be pegged at 100%...i.e. 50% of the 4 cores? Maybe I math bad...

Chris, I also believe I just figured out WHY I was hanging before. Apparently if you download a single file too many times, Google Drive FORCES you to back off. Since CloudDrive keeps asking for the same thing, it seems that the file is never let out of contention. So, I do not think it was installing the beta that fixed me. I think it was finally having the CloudDrive turned off long enough to allow it to continue. Now, I am not going to just SAY it wasn't the beta, but I have some Google Drive accounts on here that are experiencing the SAME issue. The message I get is: "the download quota for this file has been exceeded" At any rate, I'm working through things. Made some HUGE improvements to the script and am validating them now. I wouldn't want to push a junky program out to you. It already has enough caveats (no pre-fetching enabled, must be a 1920x1080 resolution).

No problem, it really did not bother me. I just had a face-palm moment as my script ran through clicking the wrong things over and over. It also brought up memories. I did a similar thing macro/script clicking buttons on a program that could not be automated. Used that to program boards in a factory. Just to mess with me, the developer moved the buttons around by a nearly unnoticeable amount each revision of the software...just to mess with me. Eventually when I caught on, he reverted the layout... Anyway, the new version seems to have uploaded all my files without issue. I'll get back to correcting the script and get that over to you once it bubbles back up to the top of my queue. Thanks again!!

Dangit! The new version moved buttons around! Now I have to redo parts of my script. That's OK, I'm slowly working towards the drives that were not uploading. I'll keep you posted if the beta seems to have corrected my issues.

Chris, I was messing around with this to ensure my cleanup didn't bugger anything up and I noticed that I have a drive that has 1.27GB of data to upload, but it never uploads. I tried quite a few combinations of settings (of course enabling upload threads). Is this something you have seen? Or is this something I should start a new thread about? Thanks!

Chris, I worked it out. I believe the SAME issue that is causing my re-attach is causing the drives to disconnect upon reboot. Essentially, they all hammer my internet at the same time (or it seems so based on some bandwidth measurements...not really accurate I'll admit as there are bursts of data...not streaming). As such, certain drives decide they lost connection and drop into a fail-safe mode and require re-authorization. I assume this will get corrected once the global threading is added. I would hope that ALL communication will be able to be able to be controlled this way. TO me, this would correct every issue I've had thus far! However, this I know you already added on my behalf! Also, I'll add that even if it is NOT the everyone hammering to re-connect...it could very well be DrivePool. I'm pretty sure it goes out after a reboot and re-checks all the drives for all the things it needs. This would certainly cause the hammering at reboot as well.

Chris, Thanks, I'll fire that over ASAP. I need to pull a clean copy from my CloudDrive machine. I was editing it a while ago and added a feature that doesn't work at this time. It's also VERY basic at this time, as in if your screen size does not match 1920x1080 the clicks are not in the right place, thus the macro won't work.

Chris, I'm not sure I created a ticket on this. If I did, I am sorry I did not track my status. I do not see anything in G-mail, maybe I have no "search skillz". ;-) I've reset my PC a few times since and have not seen this again. I am assuming it has something to do with my updating versions? I am not sure. If I see this again, I'll create a ticket. IN the mean time, I'm just patiently waiting for the Global upload limitation feature! I really am! My script is mostly working - at least enough that I'm happy with everything enough to wait while the devs. update DrivePool (I think that is what you said they are working on at this time). Thanks again! I'd consider this closed for now.

Just an update, it seems that most of the freezing was due to my slow internet. Now that I use my script mechanism to control my uploads (only 1 drive allowed at a time), I have not had any freezing on my Virtual Machine that has CloudDrive installed.