steffenmand

I'm a happy man today and you know why :-D However I would like to request the return of 100 mb chunks when you use a minimal download above X! I'm seeing a lot of throttling because the chunks are too small, so I hope you will allow the larger chunks of your minimal download is larger as well :-) Happy to get 700 mbit now, but still room for improvement if throttling disappears :-D

You're sure that the application didnt just make new files on the drive to replace old ones?

Version .504 - Windows 10 I'm seeing a lot of reads with the same offset, so it seems like it is downloading it multiple times: Seems weird that it would download the file at the same offset, especially when it is not marked as a retry? And as usual, i would like to push for the feature request: https://stablebit.com/Admin/IssueAnalysis/23906 It is marked as "Normal" but is a feature which makes the drive unusable for me, due to the severe speed limitations and the fact that i will have to reupload everything once it is in Shouldn't this have a higher priority than "Normal"? There is a lot more people than just me with high speed connections, so it might be me nagging, but a lot more is waiting for it, as seen in the Google Drive For Work thread!

Just for my own curiosity i was wondering if yoy have a timeframe for the increase of partial reads? for bow the drive is not usable for me because i will have to reupload everything again because it will require a new drive. So for now i am just sitting in a waiting position to use Stablebit! So just to have a timeframe would make me able to not check update logs 4 times a day every day

I hope that the chunk size will be increased when partial reads are larger. Could be forced to minimum partial read sizes on sizes > 20 MB. something like 50 MB would be ok for 1 gbit, lower just decreases the speeds due to the fast time an upload takes, which means the http overhead will slow down the speed.

I just upgrade, never had an issue afterwards. New features often just require you to make a new drive to be activated, but the old ones still work

Got a server running as well so is no issue for me. Only issue left for me is the speed limitation due to the small partial read size, but they are gonna make a solution for that soon and then everything is perfect for me with my 1 gbit as well :-)

Or you could do it so that if the main is writing, then the reads becomes unavailable until the write mount tells that it is complete :-) But yea I know it's a huge task, but nice to know that you are thinking about it

I'm still pushing for the update that gives increased partial reads! - Hopefully you will get it running before you go out of beta - As it will require a new drive, i can't really upload stuff before then! A lot of great fixes these days though, so props for that!

Wouldn't it be possible to "mark" data as "pending upload" and this make it invisible to "read" clients? would of course take some bytes on the chunk, but avoid "read" drives being able to cache content which is not uploaded yet. Just the option of having a read only drive is great though, then you could just work on a new drive meanwhile.

They mentioned earlier that this was not possible as it could lead to corruption. That is why we asked about the read only option, however that was, as I understand, not possible either unfortunately!

Of course, i was only joking ;-)

Tell him i'll give cake to the office if he picks it up fast Then he will be the most popular guy that day haha

Reauthorizing does not work He must have hit the golden time window! Any news if the increased partial reads might be coming soon ? Not able to use the drive properly before then, as you have stated it would require a drive to be made again Stuff is getting pretty good, rarely see any issues anymore! Oh one question, what happens if all the drive letters have been used ? Are we able to format it to a folder instead ?

Thanks for the new update yesterday ! Speed now goes to 60-120 mbit making it a bit more usable! Also seeing almost always all threads in use, where i only had 2-4 before! Don't know what your response times are to google in the US, but i get 400ms -> 1850ms so there is a wait time between each thread up to almost three-four times the time it takes to download a chunk Look forward to the partial read increase, but untill then this has made me more happy for now Oh and btw, .452 isn't available for download, however it is in the changes.txt - just if you forgot it *EDIT* I see you got it up as well with a new fix

I was unaware that the drive initial settings sets the read size, thought you would be able to change it as a setting in stablebit, this of course makes it more challenging for you :-) Hopefully a warning or "hih bandwidth required" info would be enough then :-)

Thanks for the great reply! Regarding people with lower bandwidth, it could be an option with recommend speeds and make the partial read size completely defineable by the user. This being read operations, i guess this could easily be changed to a lower size if a user figures out it doesnt work properly for them and would not require a drive update :-) Or are the partial read size somehow dependent on the drive?

Oh and finally i wanted to know if you wanted a ticket? thought it was the same as posting here, can do a ticket if desired

i sent in some logs, but rarely do a ticket on the side - the description usually tells the issue :-) First of all i have to compliment you guys for reacting so well to issues and requests from the community, other companies could learn a lot :-) I did use 20 threads as all threads finished in 00:00:00:25-40 so with them finishing in under half a second i thought more could help it speed up! of course when i can utilize the speed on less threads i will ( read larger reads ;-) hehe ) currently the threads just finish so fast that speed doesn't matter its the http delay which determines the speed currently because you have to wait some time between each thread. a 1 mb chunk will most likely not finish faster on 1 gbit than on a 50 mbit because of the http request being the main delay, thus we can never get the speed utilized! Also I only use 10 upload threads now because they use my speed just fine as well :-) I really look forward to that feature fequest to get implemented, and will make some drives ready with 100 mb chunks before updating! Hope that the feature request will result in the return of 100 MB chunks with a higher minimum partial reads( 10 mb? ) and just inform that it is for high speed connections! Again thanks for being so cool with our constant complaining ;-) your product is awesome and your constant tweaking due to our complaints just makes it even better, so thanks :-) oh and btw, 35 mbit is considered slow in my world with a 1 gbit line :-D thats what happens, you are never content with what you have, you always want the best tou can get ;-)

Seems like a bad fix for me :-( its clearly the huge amount of partial reads resulting in this error and therefore the larger partial reads would fix it as well. smaller chunks just mean less upload speed for us with high bandwidth... 100 mb currently takes around 1-3 seconds and i can build my upload speed up to the max. Unfortunately this just seems like a hotfix :-( 100 mb chunks could just have had a higher minimum partial read set! (in my case i would have loved to disable partial reads completely as my bandwidth can download chunks fast enough) Currently i can only get maximum 60-70 mbit on 20 threads due to the overhead on the http connections.. Threads usually finish in 1/4th of a second which of course means that speed can never build up, thus the low speeds, I really urge you to reconsider this fix and instead look into increasing the partial read size, as mentioned you could restrict 100 mb chunks to larger partial reads and have it as a high bandwidth option (outside the US a lot of countries, do have 1 gbit symmetrical lines, one even mentioned they were getting 10 gbit in singapore :-) ) Just add a warnibg to the user which explains this is high bandwidth only

The partial reads are often giving me download quota of this file has been exceeded. It must be due to the 50-100 partial reads of the same file. If something fails and it has to read it again, it takes yet another 50-100 reads. This makes the increase of partial read more important, as a drive can become unusable for 24 hours untill the quota resets. Because the drive keep trying to download that part forever untill the download completes after quota resets.

10 gbit for consumers heh :-P

Hi, I was wondering how cloud drive priorities threads if you open multiple files at the same time. are the threads equally divided among the files or will one be able to suck all threads leaving the others to wait or download extremely slow? In my case i could see my need to access several files at a time and 5 threads could for me be enough to download faily quick so in a scenario where i had 20 threads i would hope to see 3 files getting 6-7 threads each? And just a quick follow up on a former request: Are bigger or no partial read sizes on the schedule for a release coming soon or should we expect that in weeks or months to come? :-) Just looking forward to seeing my bandwith in action on the download

I'm using 100 MB chunks, so this might be the case - and data might have changed! Maybe the fix with larger or no partial(full download) reads will fix this as well for large chunks. Of course it should update the data, but yeah it should not work on the same chunk tons of times!

I'm seeing this on a completely new drive as well as soon as i started transferring to a drive. I don't have upload verification on After those writes finish, most likely a new read will happen perhaps followed by a new write of the chunk. Sometimes they move up an id. What's the point with all these constant read/writes of the same chunks? They must use a ton of api calls, which results in these "The download quota of this file has been exceeded" leaving the drive useless untill the next day