Description: Manually checking for an update takes about 10 seconds, whereas the server update.libreoffice.org itself responds without noticeable delay. This can be tested for example with curl -A "LibreOffice 6.3.3.2 (a64200df03143b798afd1ec74a12ab50359878ed; Windows; X86_64;)" "http://update.libreoffice.org/check.php?pkgfmt=" So the problem lies in LibreOffice itself. There may be a set time before the server result is checked and shown. Steps to Reproduce: 1. Start any LibreOffice application, e.g. Writer 2. Click "Help" 3. Click "Check for updates" 4. Wait for the update checking window to open Actual Results: "Checking..." is shown for about 10 seconds Expected Results: The check result should be shown almost immediately Reproducible: Always User Profile Reset: No Additional Info:
The first update check (after starting the program) actually takes about 20 seconds. The following ones take about 10 seconds. Extensions update check follows the same behavior. This 10 seconds delay may be used on each update check, not only the automatic one when starting the program: https://github.com/LibreOffice/core/blob/35b0a64c3c8f11e15d689ecb5598b09c4459e5cd/extensions/source/update/check/updatecheck.cxx#L439 > osl::Condition::Result aResult = osl::Condition::result_timeout; > TimeValue tv = { 10, 0 }; > // Initial wait to avoid doing further time consuming tasks during start-up > aResult = m_aCondition.wait(&tv);
This 10 seconds delay actually seems redundant since there's already a 25 seconds delay only triggered when the update check isn't started from the dialog box: https://github.com/LibreOffice/core/blob/889dc7bffa02236bf2ad56b382997771f0fcf3c6/extensions/source/update/check/updatecheckjob.cxx#L124 > if (!m_bShowDialog) { > TimeValue tv = { 25, 0 }; > m_aCondition.wait( &tv ); See also https://github.com/LibreOffice/core/blob/330df37c7e2af0564bcd2de1f171bed4befcc074/extensions/README == Application online update checking == When we start LO, first InitUpdateCheckJobThread is created, via UpdateCheckJob::execute() (from extensions/source/update/check/updatecheckjob.cxx), as a reaction to a "onFirstVisibleTask" event. It waits 25 seconds (so that it does not interfere with the startup itself), and then calls UpdateCheck::initialize() (from extensions/source/update/check/updatecheck.cxx). This creates one more thread, UpdateCheckThread, that regularly checks whether we have reached the time when we should ask for the update. If yes, asks for that, and shows the download button in the menu (if the new update is available).
(In reply to Thomas Bertels from comment #2) > This 10 seconds delay actually seems redundant since there's already a 25 > seconds delay only triggered when the update check isn't started from the > dialog box: > https://github.com/LibreOffice/core/blob/ > 889dc7bffa02236bf2ad56b382997771f0fcf3c6/extensions/source/update/check/ > updatecheckjob.cxx#L124 > > > if (!m_bShowDialog) { > > TimeValue tv = { 25, 0 }; > > m_aCondition.wait( &tv ); > > See also > https://github.com/LibreOffice/core/blob/ > 330df37c7e2af0564bcd2de1f171bed4befcc074/extensions/README @Caolán, @Stephan, I thought you might be interested in this issue
I can not reproduce this. "Help - Check for Updates..." quickly brings up the "Check for Updates" dialog and quickly checks and presents the findings in that dialog, for a local Linux (--enable-online-update) master build, a local Windows (--enable-online-update) master build, and a Windows TDF 6.2.2 (which I happened to have handy). And while it might be true that the > TimeValue tv = { 10, 0 }; > > // Initial wait to avoid doing further time consuming tasks during start-up > aResult = m_aCondition.wait(&tv); in UpdateCheckThread::run (extensions/source/update/check/updatecheck.cxx) is redundant, it should not hurt, as UpdateCheck::showDialog (extensions/source/update/check/updatecheck.cxx) contains > m_aCondition.set(); to quit waiting as soon as a manual check is initiated.
(In reply to Stephan Bergmann from comment #4) > I can not reproduce this. "Help - Check for Updates..." quickly brings up > the "Check for Updates" dialog and quickly checks and presents the findings > in that dialog, for a local Linux (--enable-online-update) master build, a > local Windows (--enable-online-update) master build, and a Windows TDF 6.2.2 > (which I happened to have handy). By "quickly checks and presents the findings in that dialog", do you mean less than a second? I can still reproduce it with the version on https://downloadarchive.documentfoundation.org/libreoffice/old/7.0.0.0.alpha1/win/ Exactly 20 seconds for the first check results, 10 seconds after that.
(In reply to Thomas Bertels from comment #5) > (In reply to Stephan Bergmann from comment #4) > > I can not reproduce this. "Help - Check for Updates..." quickly brings up > > the "Check for Updates" dialog and quickly checks and presents the findings > > in that dialog, for a local Linux (--enable-online-update) master build, a > > local Windows (--enable-online-update) master build, and a Windows TDF 6.2.2 > > (which I happened to have handy). > > By "quickly checks and presents the findings in that dialog", do you mean > less than a second? > I can still reproduce it with the version on > https://downloadarchive.documentfoundation.org/libreoffice/old/7.0.0.0. > alpha1/win/ > Exactly 20 seconds for the first check results, 10 seconds after that. With my local Windows (--enable-online-update) master build: Not exactly less than a second, but definitely faster than 20 seconds. Like two seconds each to open the dialog and to finish the update check. (Where the time it takes to open the dialog is comparable to the time it takes to open other dialogs for the first time after start-up of LibreOffice, like the "Help - About LibreOffice" dialog.) And similarly quick turnaround here with <https://downloadarchive.documentfoundation.org/libreoffice/old/7.0.0.0.alpha1/win/x86_64/LibreOfficeDev_7.0.0.0.alpha1_Win_x64.msi> as downloaded via <https://downloadarchive.documentfoundation.org/libreoffice/old/7.0.0.0.alpha1/win/>. (Which is even a bit quicker, presumably because it is not an --enable-dbgutil build like my local one.)
I found out how to reproduce on a different computer: Install VirtualBox (https://www.virtualbox.org/wiki/Downloads) It creates a "VirtualBox Host-Only Ethernet Adapter" which, when enabled, delays the update check. Disabling it during the update makes the update check finish immediately. I'd be curious to test without the 10 seconds delay at https://github.com/LibreOffice/core/blob/35b0a64c3c8f11e15d689ecb5598b09c4459e5cd/extensions/source/update/check/updatecheck.cxx#L439 to see if it's linked to this bug since it's always 20 seconds on the first check then 10 seconds, but I got an error when trying to build LibreOffice.
Hello Thomas Bertels, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Still reproducible with 7.1.0.3.
no repro in Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ad1b12686da88bea57582df10fa85268ada209b8 CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: en-GB Calc: CL
I just checked it with LibreOffice 7.1 on both Windows 10 and Windows 7 with VirtualBox installed and cannot reproduce it.