2.0.4.8-2.0.4.8_canary_2018-12-13
- Fixed an issue that broke IE, thanks @mikaelmello
Does this release supersede the 2.0.4.7 release posted just before?
Also, any plans to fix the issue with the ācheck for updatesā functionality?
I wanted to translate the new functions on viewing the logs, where can I go to translate into Italian?
thank you
You can translate per transifex,
https://www.transifex.com/duplicati/duplicati/dashboard/
@kenkendk
when i want to set the log level, there is only the option to disable. The other options are missing
Ignore 2.0.4.7, I forgot to git pull so it is identical to 2.0.4.6.
Yes, once I figure out why it fails, I will fix it 
Can you reload the page? The options are loaded from the server, so I think there might be a glitch where the options are empty.
I have reloading the page with STRG+F5, clearing chache, private mode in browser, Browser: vivaldi, firefox edge,ā¦
In the debug console from the browser, is after click on the combobox this entry:
[Violation] Added non-passive event listener to a scroll-blocking āmousewheelā event. Consider marking event handler as āpassiveā to make the page more responsive. See Chrome Platform Status
Another thing, when i go to the protocol view, the saved log entries are only displayed after a change from live to savedā¦
If it helps, every time Iāve tried so far this pair of errors appears in the log:
(highlighted previous times to show how it always puts 2 entries in the log)
Also if it helps I downgraded to 2.0.4.2 and 2.0.4.4 and for both the update checks instantly started working again, so the issue appears tied to something in the 2.0.4.5 release, not some change on the updates server or DNS.
alt.updates.duplicati.com indeed doesnāt resolve. updates.duplicati.com resolves to 139.59.135.67.
Did Duplicati 2.0.4.4 and later change the update server URL to alt.updates.duplicati.com? In that case, the solution could be adding an A record alt.updates.duplicati.com in DNS that points to 139.59.135.67.
Yeah, I assume @kenkendkās comment here that it was ānot a problemā meant that the alt.updates.duplicati.com error was EXPECTED.
Iām going to see if I can figure out how to update my hosts or local DNS for a Docker container and dummy in 139.59.135.67 for alt.updatesā¦
Edit:
Well, either I donāt know what Iām doing in Docker (likely) or thereās something else going on (also likely). Am I supposed to get something other than a 503 error from http://139.59.135.67/? (I assume it just hasnāt been configured to host anything off of IP.)
Yeah, you cannot do that. The server relies on SNI to pick the right certificate. If you send a name that it does not know, you get something like āupstream server errorā as there is no server that handles the name.
Urghā¦ that really sounds annoying, given that it is a beta release and downloaded by a lot of userā¦
Does it also fail with 2.0.4.6 upgrade to 2.0.4.8 ?
Otherwise, I will try to install 2.0.4.5 on a clean system and debug the update problem.
From the error message, it sounds like 2.0.4.5 is using the wrong key to validate the signature in the update package.
For me, yes - and I think my previous comment about 2.0.4.2 and 2.0.4.4 updates working may have been incorrect. I think they were reporting an already detected update after their individual checks failed.
Keeping in mind I do weird things to my installations, I did some tests and it appears I now get the error on ALL versions as far back as at least 2.0.4.2 exp (my base install).
Based on my 2.0.4.2 exp Docker base install (set for the canary update channel):
- 2.0.4.2 exp generated Signature and NameResolution errors
- 2.0.4.3 can generated Signature and NameResolution errors
- 2.0.4.4 can generated Signature and NameResolution errors
- 2.0.4.5 bet generated Signature and NameResolution errors
- 2.0.4.6 can generated NameResolution and Signature errors (yes, errors reversed order)
Note that loading Stored logs got really slow here (toggling to Live than Stored āfixesā this, I think itās a UI issue) - 2.0.4.7 can (skipped invalid release)
- 2.0.4.8 can generated NameResolution and Signature errors (yes, errors reversed order)
Two side notes:
- Sometimes the errors are Signature then NameResolution and other times theyāre reversed (even on the same version) - I assume it has to do with how long it takes things to time out NOT the order in which they are called
- Why arenāt these errors showing up in the GUI alerts?
The NameResolutionFailure may have been resolved - please try your update again.
Indeed, updating from 2.0.4.4 canary to the latest version just worked. 
1 Like