- Fixed an issue that broke IE, thanks @mikaelmello
Does this release supersede the 188.8.131.52 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?
You can translate per transifex,
when i want to set the log level, there is only the option to disable. The other options are missing
184.108.40.206, I forgot to
git pull so it is identical to
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 Passive event listeners - 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 220.127.116.11 and 18.104.22.168 and for both the update checks instantly started working again, so the issue appears tied to something in the 22.214.171.124 release, not some change on the updates server or DNS.
alt.updates.duplicati.com indeed doesn’t resolve. updates.duplicati.com resolves to 126.96.36.199.
Did Duplicati 188.8.131.52 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 184.108.40.206.
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 220.127.116.11 for alt.updates…
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://18.104.22.168/? (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 22.214.171.124 upgrade to 126.96.36.199 ?
Otherwise, I will try to install 188.8.131.52 on a clean system and debug the update problem.
From the error message, it sounds like 184.108.40.206 is using the wrong key to validate the signature in the update package.
For me, yes - and I think my previous comment about 220.127.116.11 and 18.104.22.168 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 22.214.171.124 exp (my base install).
Based on my 126.96.36.199 exp Docker base install (set for the canary update channel):
- 188.8.131.52 exp generated Signature and NameResolution errors
- 184.108.40.206 can generated Signature and NameResolution errors
- 220.127.116.11 can generated Signature and NameResolution errors
- 18.104.22.168 bet generated Signature and NameResolution errors
- 22.214.171.124 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)
- 126.96.36.199 can (skipped invalid release)
- 188.8.131.52 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 184.108.40.206 canary to the latest version just worked.