Good to hear from you again bigearedone

re the incompletes being able to be refound, I wish it were easy.

There does exist a unique identifier, called a hash (sha-1). It's used for the bitzi lookup, magnet links (control-click a file in your Library Pane to see one of those), to verify that the file you received *exactly* matches the one sent, and probably more. There is also a more recent method of checking smaller chunks of a file, generally callled THEX, and it is still being improved/implemented more widely. I asked zab (now HE is expert on this part) if maybe one could resurrect an old incomplete file just from the bits already downloaded, but it doesn't look likely. And so, if the data in the downloads.dat file becomes corrupt or useless, there's not a method currently used to rebuild it.

Also, searches by hash have been . . .in short, banned. Not sure of the exact reasoning, but they were found to be easily abused and the network apparently suffered. Hashes are also "expensive" in terms of CPU use, but I gather this is a tradeoff to prevent a network being flooded by fake files because of a quicker and less secure hash method.

Keyword searches will indeed find current sources, but the problem is the cost of matching the new bits with the old. Too, files which may seem similar (size and much of the name) may actually be different in a few bytes. I guess the answer is currently coded as "just start from scratch after 6 failed attempts."

btw--I've quickly found "reading the manual" is not very reliable, since the developers are rightly spending their time developing. heh--in a dynamic network, it makes sense that the info is dynmaic too: static manuals get outdated pretty fast. The new wiki at http://www.the-gdf.org/wiki/index.php?title=Main_Page should help the developers update the info more, and I'm finding reading there quite interesting.

Sorry I can't be clearer with answers to your questions: I am not an expert, but you're welcome to what I've read

And yes, there is hope about the new spam. The LW folks are talking with the Credence developers, for example. I guess the risk is that any "banning" mechanism can be tricked to ban legitimate hosts, which poses a risk to the network. The more I read, the more aware I've become of the 'politics' of p2p network development. LW is getting to be quite the grandfather here with its upcoming 5 years of development, and its growth is more fun to watch than many sports matches

on the old downloads thing - this is what I did

I copied off the whole "incomlete" folder onto a different computer, 2800 files. I took 2000 out and left in a folder and started limewire. Limewire loaded the old downloads and then I went into Library and incompletes and refresh then I selected everything in that window and hit resume

It seems to have worked and Limewire seems happier and faster to respond. It has crashed but only after a few hours on when I noticed most of the files had the 'need more sources' status so I selected 40 or 50 and hit resume and it started looking but I think this sort of messes with Limewires system and it just craps out a while later

I am curious about trashing the downloads file itself in the incomplete folder and seeing if the incomplete files themselves can be loaded and downloads start?
I suppose Im not desperate enough yet to try it but I could do it with just a few files on another computer - or perhaps someone had done that?

have you ever got in touch with any of the Limewire people? - I thought when I went pro that I would at least get some reply to my emails?
Nada.
Now I know I didnt pay much and perhaps there are only a few people working behind the scenes but I think encouraging some feedback or having a little button somewhere to suggest a new feature might be beneficial to the developers and ultimatly to us the end user?

a mass network of creative minds brainstorming a problem . . . .

on that thought Im wondering if there is any lunux / open source / copy left aspect to Limewire or is that covered in the generocity to share files and thats enough...?

You're right about the brainstorming . . . and although these forums are independent of LW, members of the "team" http://www.limewire.com/english/content/team.shtml do get involved here, and often ask for suggestions http://www.gnutellaforums.com/forumd...?s=&forumid=24 or encourage feedback with beta testing http://www.gnutellaforums.com/showth...threadid=32702

I did get an answer through Pro support a once after a while, but honestly found the help in these forums faster. There's LimeWire.com, the commercial side; and LimeWire.org, the opensource project side. I figure if I stay away from the .com email support, more o' me bucks ends up supporting the .org side

Back on topic: if you lose the relevant "downloads.dat" or its associated "downloads.bak" file, your incompletes cannot resume at more than zero kilobytes. So, another way to trim the incomplete folder is to weed out all the zero KB files.

Try running LW with less than 10 incompletes and see the difference (even 800 is too many).

Cheers

just an observation I wanted to share with other users

deleting all the downloads in the main window doesnt delete any of the incomplete files so what I have been doing is deleting all the downloads in the download window and quiting.

then I reboot and go into the incomplete folder in the library window and select all and hit resume

after a few minutes things start downloading and the whole thing seems to work better and files that have been sitting there doing nothing start downloading

its a bit like spring cleaning

if I have no files downloading or waiting I will now delete all the downloads and quit and restart them

yihaa!!!

Does anyone know why this is the case?
Its as if Limewire does a better search for the files whereas before it might have been looking for a file on a specific IP?

any ideas??