"last received block was generated 1 minute ago" message is wrong #2334

issue dooglus opened this issue on February 24, 2013
  1. dooglus commented at 7:15 PM on February 24, 2013: contributor

    When I hover over the checkmark in the bottom right corner, I see "last received block was generated 1 minute ago". That's after my computer has been offline for over 12 hours, and so can't possible be true.

    The "1 minute ago" seems to mean "the block was generated 1 minute before it was received", but that's not what the message says. I don't really care how long elapsed between block generation and my client receiving it. I care how old the block is now (because that tells me whether I'm up to date or not), and that's not what is displayed.

  2. rkfg commented at 9:56 AM on March 3, 2013: none

    I wanted to open this issue a while ago but thought maybe I don't understand something. But that's true, the message is wrong when you've caught up. I've done a bit of grepping of the source and found the related function, it's BitcoinGUI::setNumBlocks(int count, int nTotalBlocks) on line 500 @ src/qt/bitcoingui.cpp. The problem is that it sets the tooltip just when the block is received and the time is (QDateTime::currentDateTime - lastBlockDate). Obviously, it's the time between block generation and receiving by your node thereby it's pretty useless. I propose calling this function on several events from labelBlocksIcon, progressBarLabel and progressBar. Maybe onMouseMove or onTooltip. I'm not into Qt at all and I don't know which events can be processed and how they're called. I'll try to implement this myself, should be pretty straightforward but I don't promise anything.

  3. rkfg commented at 10:39 AM on March 3, 2013: none

    Well, here's a little patch to make it work as expected. It forces updating the block count and time since the last block every 10 seconds (20*500ms).

    diff --git a/src/qt/clientmodel.cpp b/src/qt/clientmodel.cpp
    index 084ad12..d7fe156 100644
    --- a/src/qt/clientmodel.cpp
    +++ b/src/qt/clientmodel.cpp
    @@ -17,6 +17,7 @@ ClientModel::ClientModel(OptionsModel *optionsModel, QObject *parent) :
         QObject(parent), optionsModel(optionsModel),
         cachedNumBlocks(0), cachedNumBlocksOfPeers(0), numBlocksAtStartup(-1), pollTimer(0)
     {
    +    forceUpdateCounter = 0;
         pollTimer = new QTimer(this);
         pollTimer->setInterval(MODEL_UPDATE_DELAY);
         pollTimer->start();
    @@ -61,13 +62,14 @@ void ClientModel::updateTimer()
         int newNumBlocks = getNumBlocks();
         int newNumBlocksOfPeers = getNumBlocksOfPeers();
    
    -    if(cachedNumBlocks != newNumBlocks || cachedNumBlocksOfPeers != newNumBlocksOfPeers)
    +    if(cachedNumBlocks != newNumBlocks || cachedNumBlocksOfPeers != newNumBlocksOfPeers || ++forceUpdateCounter == FORCE_UPDATE_COUNTER)
         {
             cachedNumBlocks = newNumBlocks;
             cachedNumBlocksOfPeers = newNumBlocksOfPeers;
    
             // ensure we return the maximum of newNumBlocksOfPeers and newNumBlocks to not create weird displays in the GUI
             emit numBlocksChanged(newNumBlocks, std::max(newNumBlocksOfPeers, newNumBlocks));
    +        forceUpdateCounter = 0;
         }
     }
    
    diff --git a/src/qt/clientmodel.h b/src/qt/clientmodel.h
    index 1afccb7..c25a173 100644
    --- a/src/qt/clientmodel.h
    +++ b/src/qt/clientmodel.h
    @@ -62,6 +62,7 @@ private:
         int numBlocksAtStartup;
    
         QTimer *pollTimer;
    +    int forceUpdateCounter;
    
         void subscribeToCoreSignals();
         void unsubscribeFromCoreSignals();
    diff --git a/src/qt/guiconstants.h b/src/qt/guiconstants.h
    index 405ba39..9799f95 100644
    --- a/src/qt/guiconstants.h
    +++ b/src/qt/guiconstants.h
    @@ -3,6 +3,7 @@
    
     /* Milliseconds between model updates */
     static const int MODEL_UPDATE_DELAY = 500;
    +static const int FORCE_UPDATE_COUNTER = 20;
    
     /* AskPassphraseDialog -- Maximum passphrase length */
     static const int MAX_PASSPHRASE_SIZE = 1024;
    
  4. laanwj commented at 1:16 PM on March 3, 2013: member

    Indeed, the underlying problem is that the tooltip is generated when a block comes in, not when the tooltip is requested to be rendered. @eurekafag's patch works around this by sending the numBlockChanged signal even though the number of blocks hasn't changed (which is contrary to the principle of least surprise, I'd say).

    Another related problem is that the tooltip is never updated while it is visible. This is a qt limitation. I suppose to really fix this the tooltip should be drawn manually.

    Edit: issue #2233 was about the same problem

  5. rkfg commented at 2:04 PM on March 3, 2013: none

    Maybe it would be good to split the setNumBlocks function in two, one for setting the block count and another for updating the tooltip with time passed since the last block. Then we can update only the time once in a while following "the least surprise" principle as you said. I set 10 seconds to clearly see the update process but it may be as well 60 seconds since the tooltip doesn't show seconds after the first minute. I understand that the code sanity is a priority over features so my dirty hack definitely needs variables renaming and such to comply with the project's guidelines. But at least it's something working already.

  6. dooglus commented at 9:54 PM on March 3, 2013: contributor

    I don't know anything about Qt, but according to your principal of least surprise it would be better not to mention the time since the last block was received at all than to use a value that could be out by several hours.

    My Internet was down all night. When it comes back, sometimes bitcoin-qt doesn't resume downloading blocks. I hover over the checkmark and see that the last block was generated 15 minutes ago. It's pretty damn surprising when I find out that that actually means "last block was generated 15 minutes ago from 12 hours ago".

  7. dooglus commented at 5:35 PM on April 23, 2013: contributor

    How about including the time and date that the last block was received?

    Currently I hover over the green checkmark and see "last received block was generated 9 seconds ago".

    I have no idea whether that was today or yesterday. Sometimes the client takes a long time to even notice that it's out of date, so it sits there says "9 seconds ago" when it's actually 24 hours out of date (since I've been offline for 24 hours).

    If the tooltip included the date and time that the block was received, I'd be able to tell if the client was up to date or not. That should be a trivial code change.

  8. laanwj commented at 8:34 AM on April 24, 2013: member

    It used to show a time and date, and then people wanted it this way. There is just no way to satisfy everyone, sorry.

  9. rkfg commented at 8:46 AM on April 24, 2013: none

    Of course, there's a way. It's called "options". Just add an option to show the time in a "date" form or "x y ago" form which I personally hate because it's too rough and often even seconds matter. It's outrageous that even github adopted this format for comments and even commits which is too bad. But some people are ok with this so it needs to become an option in the settings.

  10. laanwj commented at 9:53 AM on April 24, 2013: member

    We won't add options for every trivial ui decision. That's a maintainability and testing nightmare. We are understaffed in that regard already.

    This issue must be solved nevertheless, and you are right in that simply showing a date is the most straightforward path to that if we don't want to mess with qt internals for real-time tooltip updates. Hmm...

  11. dooglus commented at 6:55 PM on April 24, 2013: contributor

    It used to show a time and date, and then people wanted it this way.

    I don't think that's really accurate. I can understand if people wanted it to say "3 minutes ago" instead of showing a time that is 3 minutes earlier than the current time, but I doubt anyone wants the current system which is to show "3 minutes ago" and keep it showing "3 minutes ago" until the next block is received, which could be days later if I go offline.

    I would prefer "x ago" instead of a timestamp if the x was true, but "x ago" where x is calculated once and never updated is truly useless, and reminds me of an old bug from 1957: http://youtu.be/-tjHlFPTwVk

  12. laanwj commented at 3:14 PM on November 11, 2013: member

    This is no problem anymore (starting from commit 24cde0b7d1ad014ffca5d0af896bc50b30e5ddcd) as the smallest granularity of generated XXX ago is in weeks, not minutes or seconds.

  13. laanwj closed this on Nov 11, 2013

  14. MarcoFalke locked this on Sep 8, 2021
Contributors

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bitcoin. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2026-04-16 00:15 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me