Cosmetic problem: block number not being updated in Windows during start up #5664

1. 
   tl121 commented at 2:53 am on January 15, 2015: none

   v0.10.0rc1 on Windows 7 Node was off line for 5 days. After startup, block loading and verification, downloading of new blocks started. and began normally. Age counted down from 5 to 3 days. At this point, age ceased to count down on the main window and the processed block number on the main window and the Help Information window was unchanging. Looking at the Help Network Traffic window it looked like the network IO had been completed. Windows task manager showed that all processor cores were busy servicing Bitcoin Core. The program appeared to be hung, except that the two windows responded to mouse actions. Checking the Debug Log it appeared that blocks were being processed and logged normally at the usual high speed. The problem appeared to be a lagging user interface display, not an actual lag in processing.

   When catchup happened, the progress display still showed 3 days of blocks to catch up just before it disappeared and the green check mark appeared.

2. 
   patrikr commented at 5:51 am on January 16, 2015: none

   I’ve noticed the same in Windows XP. 0.10’s GUI doesn’t seem to update very often, including the debug window. I have to look at debug.log to see what the status actually is.
3. 
   Diapolo commented at 7:38 am on January 16, 2015: none

   @cozz @laanwj Did we change UI update frequency recently?
4. 
   laanwj commented at 9:43 am on January 16, 2015: member

   I suspect it’s that the cs_main lock is contended, so the GUI never gets to fetch new statistics. High CPU usage confirms this. It’s preferable to the hard GUI hangs which would happen in 0.9 in the same situation.

   (One could work around this by subscribing to a signal from the core, e.g. NotifyBlockTip, and report statistics to the GUI periodically in a more asynchronous way. But be careful not to overload Qt’s event mechanism on frequent updates)

5. laanwj added the label GUI on Jan 16, 2015
6. laanwj added the label Priority Low on Jan 16, 2015
7. 
   tl121 commented at 3:35 pm on January 16, 2015: none

   I agree that the new way is preferable to the old hard GUI hang. I reported this primarily because it might be system dependent and hence hadn’t been seen yet. Also, at least on my system it is repeatable.

   There may be a related problem during block acquisition whereby all network activity ceases for several minutes while downloading but all the blocks haven’t yet been downloaded. In this case, the difference would be that the system would be quiescent with no processor, disk or network activity but unfetched blocks available on peers or fetched but not being processed by the CPU. At the time I suspected this was happening it was not repeatable, which is why I didn’t report it. If this actually happened then it would be a performance bug and would affect timing of initial bock acquisition. Probably not a low priority cosmetic bug (unless it was rare and unique to my system) but definitely not a high priority bug either.

8. 
   laanwj commented at 7:04 am on May 29, 2015: member

   Probably the same problem as #5851
9. 
   laanwj commented at 1:40 pm on November 30, 2015: member

   Solved by #7112
10. laanwj closed this on Nov 30, 2015

    ---

11. MarcoFalke locked this on Sep 8, 2021

Contributors
tl121 patrikr Diapolo laanwj

Labels
GUI