On Saturday 29 March 2008 15:05, freenetwork at web.de wrote:
> I can support the claim of problems with downloads.
> 
> Sometimes restarting the node helps to have the files downloaded to HDD, 
> sometimes the request has to be removed from the queue, then re-added 
> after a short time to have the download appear on HDD within seconds, 
> sometimes only both helps...
> 
> So from MPOV there's something not quite flawless regarding downloads.

I may have fixed it in trunk. A new build will be released soon with the fix.
> 
> 
> Matthew Toseland wrote:
> > I continue to see reports of downloads stalling and then showing dramatic 
> > improvements after a restart. I'm skeptical. I have not been able to 
> > reproduce the alleged bug recently: when I leave the node running 
overnight, 
> > I come back and I see that downloads are progressing, admittedly slowly. 
> > However I have a theory:
> >
> > On restart, every persistent request is started again from 0%. Because 
almost 
> > all files are splitfiles, it has to fetch the top of the splitfile first. 
> > This means it will start at 0% and, assuming it's fetched this part 
> > successfully before, rapidly progress towards 100% (because it's only 
> > fetching a few blocks, which are all in the datastore anyway). Then it 
will 
> > jump back to where it was, and make much slower progress, because it's now 
> > fetching the real data.
> >
> > If I am right, we need to make it a lot more obvious when a percentage is 
> > provisional (i.e. when it's likely we are going to add more blocks once 
this 
> > layer is fetched). We could maybe add a layer/stage indicator, either as a 
> > number or as a color?
> >
> > My apologies to all you who have reported this bug, it's entirely possible 
> > that there is a real download stalling bug, I'm just pondering a possible 
> > explanation - does it fit with your experience?
> >   
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Devl mailing list
> > Devl at freenetproject.org
> > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> _______________________________________________
> Devl mailing list
> Devl at freenetproject.org
> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: 
<https://emu.freenetproject.org/pipermail/devl/attachments/20080329/0e5923e5/attachment.pgp>

Reply via email to