minor annoyance: log spam-limiting for block processing ought not to suppress when finally synced

[carryforward]

This is a very minor complaint about the log output. It looks like the log spam rate limiting code suppresses a log entry even when it is fully synced. I guess it is a feature request.

here is an example log:

18:04:17 2014-09-30 [INF] BMGR: Syncing to block height 282103 from peer 89.248.162.189:18333
18:04:18 2014-09-30 [INF] BMGR: Processed 1 block in the last 12.68s (44 transactions, height 281362, 2014-09-24 12:26:01 -0400 EDT)
18:04:28 2014-09-30 [INF] BMGR: Processed 181 blocks in the last 10.05s (5415 transactions, height 281543, 2014-09-25 22:56:23 -0400 EDT)
18:04:38 2014-09-30 [INF] BMGR: Processed 205 blocks in the last 10.06s (7891 transactions, height 281748, 2014-09-27 12:32:40 -0400 EDT)
18:04:42 2014-09-30 [INF] CHAN: Adding orphan block 000000001897684c180811716e0218826856b471e099cb5a41ffb0d4aceebd53 with parent 000000009d2ec5b1fefafb9527ea3848ce06d1e42c73a580c180ab91848f5956
18:04:48 2014-09-30 [INF] BMGR: Processed 227 blocks in the last 10.05s (8505 transactions, height 281975, 2014-09-29 13:51:32 -0400 EDT)
18:05:37 2014-09-30 [INF] BMGR: New valid peer 5.9.10.71:18333 (outbound) (/Satoshi:0.9.2.1/)
18:06:37 2014-09-30 [INF] BMGR: New valid peer 198.50.229.255:18333 (outbound) (/Satoshi:0.9.2.1/)
18:09:06 2014-09-30 [INF] BMGR: New valid peer 24.125.163.221:18333 (outbound) (/Satoshi:0.9.1/)
18:09:28 2014-09-30 [INF] BMGR: New valid peer 54.72.209.27:18333 (outbound) (/Satoshi:0.9.1/)
18:09:39 2014-09-30 [INF] BMGR: New valid peer 192.99.195.19:18333 (outbound) (/Satoshi:0.9.1/)
18:09:50 2014-09-30 [INF] BMGR: New valid peer 198.46.158.134:18333 (outbound) (/Satoshi:0.9.3/)
18:18:23 2014-09-30 [INF] RPCS: New websocket client 127.0.0.1:42539
18:18:23 2014-09-30 [INF] RPCS: Beginning rescan for 261 addresses
18:18:24 2014-09-30 [INF] RPCS: Finished rescan
18:19:22 2014-09-30 [INF] BMGR: Processed 128 blocks in the last 14m33.86s (2909 transactions, height 282104, 2014-09-30 18:59:10 -0400 EDT)

The minor annoyance is the last line. The rate limiting code suppressed a log entry for the 127 blocks, instead of making a log entry when it was fully synced.

This data is from testnet. I ran it and it caught up from a few days being idle. I am running code tagged as the 0.9 release.

I looked into the gocode and it looks like in blockmanager.go in function:
func (b *blockManager) logBlockHeight(block *btcutil.Block) {
the check:

    if duration < time.Second*10 {
        return
    }

would need to be aware of:
bestPeer.lastBlock
in function
func (b *blockManager) startSync(peers *list.List) {

I just wanted to log this minor issue because I keep seeing it and it bothers me a little. I realize the testing would easily take longer than the implementation. Also the edge cases where the peer block height changes would need to be examined.

Please feel free to close the issue if you guys to not feel it is worth implementing.

[dajohi]

This has bugged me too.

[davecgh]

I agree it would be a good idea to log when synced