Release: 2.0.4.16 (canary) 2019-03-28

#1

2.0.4.16-2.0.4.16_canary_2019-03-28

  • Fixed an issue with Sia authentication, thanks @Ajedi32
  • Improved documentation, thanks @kesava-wow
  • Improved code quality, thanks @warwickmm
  • Added custom B2 download url option, thanks @aahung
  • Updated list of Wasabi and S3 storage destinations, thanks @FroggieFrog
  • Fixed a case where temporary files were not removed, thanks @warwickmm
  • Code refactor and quality improvement, thanks @verhoek
  • Added option for parallel uploads, thanks @seantempleton
  • Improved exception messages, thanks @warwickmm
  • Implemented Jottacloud multithreading uploads, thanks @nescafe2002
3 Likes

Verifying Backend Data
Spectacularly slow upload to B2 on good spec PC
#2

GUI update from 2.0.4.15 in Docker container worked as expected.

I see 3 Wasabi options for S3 Compatible - hey, when was Dreamhost added? :slight_smile:

Are parallel uploads set with this?

asynchronous-concurrent-upload-limit
When performing asynchronous uploads, the maximum number of concurrent uploads allowed. Set to zero to disable the limit.
Default value: “4”

0 Likes

#3

Did you persist the update folder so it doesn’t reset on redeploy? :slight_smile:

0 Likes

#4

Yep, thanks!

I know I’m doing things oddly, but it’s for support reasons so I can up/downgrade like a non-Docker user. :slight_smile:

The container itself is against Experimental so I could get the OneDrive V2 fix bet I believe the beta container now has the fix in it so I should probably switch back to that. :thinking:

1 Like

#5

You are correct @JonMikelV. asynchronous-concurrent-upload-limit sets the number of files that can be uploaded at the same time.

1 Like

#6

In case there’s any confusion, I believe the change to Jottacloud involved multithreaded downloads, not uploads.

0 Likes

#7

So Jottacloud specific update is for multithreaded downloads AND the new asynchronous-concurrent-upload-limit parameter should support multithreaded uploads?

0 Likes

#8

This is great news for B2 users (among others I assume) - with this, I’m finally able to max out my ISP upload bandwidth from home (note i have a modest 50 megabit connection).

This makes me realize one big wishlist item of mine: a GUI component to show the upload status/progress of individual chunks (similar to the progress bar for individual files being backed up, but for dblocks currently being uploaded).

1 Like

#9

Yes, that’s correct. :slight_smile:

0 Likes

#10

Any chance this update has addressed the SIA API authentication issue? API Authentication is now enabled in SIA by default, and with the recent update to SIA 1.4.0 i’m not sure how it can be disabled, if at all.

0 Likes

#11

Since the update to 2.0.4.16 I have problems with the local DBs of 3 jobs. It shows differences in the file count.
So I tried to repair the local DB, I tried to create new ones, also with different file names but all fail with “File length is invalid”

Have you got any recommendations?
Thank you in advance.

0 Likes

#12

I have this problem with 1 job after upgrading to .16

Apr 8, 2019 9:12 AM: The operation Backup has failed with error: Unexpected difference in fileset version 1: 3/28/2019 12:18:26 AM (database id: 43), found 25179 entries, but expected 25180

on the good side, existing jobs now take a shorter time to complete when there are no changes, I had one for about 1TB that in .12 toked ±50 mins now takes ±15mins

I made some random test restores and everything seems to be working fine with all other jobs.

0 Likes

#13

Thanks for starting a fresh topic. :slight_smile:

0 Likes