Closed GoogleCodeExporter closed 9 years ago
The problem is there is no single truth. Any peer can be at any count of blocks.
Also, the percentage from last version did never really work.
Original comment by andreas....@gmail.com
on 23 Oct 2011 at 5:57
I guess it should be there, at least how many blocks are downloaded already and
some information whether it has downloaded all of them to date or not. Now
there's only a warning in this case which doesn't clearly state the end of
downloading.
Also, when both prodnet and testnet are running their block counters replace
each other and you have no idea how many blocks each client has downloaded.
Labeling them would be nice and the warning can find its place somewhere else I
guess (for example when the user starts the app for the first time). It takes
too much screen space for the one-time notification. It can be used better.
Original comment by radioano...@gmail.com
on 10 May 2012 at 6:56
The problem with prodnet and testnet blockcounters replacing each other should
be fixed for some time. If not, please open individual ticket.
Original comment by andreas....@gmail.com
on 16 Jul 2012 at 11:57
Issue 103 has been merged into this issue.
Original comment by andreas....@gmail.com
on 16 Jul 2012 at 12:00
The progress bar _can_ be the amount to download in this session. See
DownloadListener for an example of how to do this. If you make the bottom bar a
progress bar that shows how much is left to download from the selected download
peer, it will become a lot more useful.
Original comment by mh.in.en...@gmail.com
on 17 Jul 2012 at 7:25
(I was just going to write a lot of how unintuive progress bars are in the
context of the blockchain, when I had an idea and I deleted it all)
The only case where a progress bar IMHO actually makes sense is first-time
setup/blockchain reset.
I propose the following: If the app gets reported the first peers chain height
(and I really mean first, so this will be persisted), the app will start
displaying a progress bar that will go from 0 towards that reported chain
height. If the height is passed, it will be gone and never be seen again (until
blockchain reset that is).
After that point, and with autosync hopefully to be active by default soon,
there should never be a reason for displaying progress again.
The progress bar could perhaps report the estimated *download time* inline,
although this is problematic again because there could be larger gaps in
download.
There is the slight chance that the first peer reports a vastly wrong chain
height, but this would not be the end of the world. A "known minimum" threshold
could protect against this case.
Original comment by andreas....@gmail.com
on 18 Jul 2012 at 1:54
I think Satoshis code takes the most common height reported by all connected
peers.
I'm not sure why just displaying the amount to download from where we are now
to where we think the chain is, is so problematic. It should usually result in
a fairly rapid movement of the progress bar from left to right.
Original comment by mh.in.en...@gmail.com
on 18 Jul 2012 at 2:02
As the reference implementation has now more or less copied the approach of
just showing number of hours/days/weeks behind, I doubt this will change soon.
I'll close this issue for now.
Original comment by andreas....@gmail.com
on 24 Feb 2013 at 11:25
Original issue reported on code.google.com by
vn654...@googlemail.com
on 19 Oct 2011 at 1:49