* Milan Holz?pfel <listen at mjh.name> [2007-01-06 08:56:46]: > On Thu, 4 Jan 2007 16:03:22 +0100 > Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> wrote: > > > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-01-04 > > 15:48:09]: > > > > > [...] > > > > > > But the current behavior often leads to downloads that have more > > > than 100% progress *g* > > > > Is it *that* important to have an accurate progress bar ? some blocks > > can take *ages* to be retrived whereas some will come up > > instantaneously... Imho we can't provide a reliable > > percentage/ETA/whatever for small files even if we had detailled stats > > on what's going on. > > That's probably very true, but I always wonder whether > 100% means > that there is a bug in fproxy / freenet and it will never finish > because it didn't notice that it was finished already or something.
It's not a bug. > It's probably a bad idea to say that the download is > 100%, from a > user point of view. Well, it won't say such a thing if you aren't running the "AdvancedDarknetMode" :) See how it's implemented on http://emu.freenetproject.org/cgi-bin/viewcvs.cgi/trunk/freenet/src/freenet/clients/http/QueueToadlet.java?rev=11427&view=markup look for "private HTMLNode createProgressCell(" ... Depending on if advanced mode is on or off, we consider that the total amount of blocks is either the "required" or the "total number of inserted blocks". Both approaches do have problems : in non advanced mode, a download can finish at 2/3 in avanced mode a download can finish (worst case assuming it finishes) at 3/2 ! ATM it's up to FCP client authors to choose one of the above "strategy" to show the progress. > > That an ETA will not be that reliable is a different topic if you ask me. it's related :) > > > Btw, haven't you ever experienced the same "bug" on the queue toadlet > > on fproxy ? > > [...] > > One of my downloads on fproxy's queue page says it's at 101.2%. I > think that this is this bug? Yes, that one :) As said previously it's not a bug :) but actually a feature. > > Regards, > Milan -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20070106/6c7270bc/attachment.pgp>
