yes i agree im going to finaly get broad band on monday the 4th (FINALY), and want to be able to throttle my Download & upload speeds so i may have a slight chance of playing the occasional Counter-Strike or H-L2 :P

This is really a bug fix request. Two problems with the user interface are massive nuisances:

• Making multiple selections is broken and has been for ages. Control and shift clicks are interpreted correctly much of the time, but a random fraction are treated as plain clicks, and clobber your elaborate half-built selection, which is evil and rude. Moreover, shift-clicks sometimes do not extend a range correctly. Clicking a file and then shift-clicking a file way below creates a range as expected (when it doesn't just change the selection to only the lower file; we'll assume it worked though) -- now if you shift-click the next file down, it will frequently leave you with just the bottom two files of the intended range selected, rather than everything from the first file clicked on to the final file. (Sometimes it will just select that last file, but again that's the shift key being ignored rather than incorrect range extension.) This is unfortunate, because needing to extend a range by one is very common and control-click is far more likely than shift-click to hit the "ignored modifier" bug. As for why needing to extend a range by one is very common:
• Not only do the items move around constantly while trying to select from the list if there's a lot of activity happening, but the UI's response to your mouse clicks lags behind your input noticeably, and often enough for it to get the order of events wrong when the items shift. E.g. you click item A, shift click item C, and everything moves up one; but your shift-click is ignored until after the move, and you end up with A-D instead of A-C selected. If the shift-click happened before the move the consequences should be processed as occurring before the move goddammit.
• Clicking of "resume" or "find sources" is sometimes, incorrectly, ignored. The item is not greyed, and animates sensibly, but nothing happens.
• Recent versions of Limewire grey this button out sometimes. This makes sense for connecting and waiting in line, but I used to be able to select a download that had stalled and "resume" it; now it's necessary to make a larger selection that includes the download to prod a download into activity and even then it doesn't always work. Is it really intended that people no longer be able to resume stalled downloads unless they fail completely? Being able to prod a host that had apparently forgotten you were there with some kind of "keep alive" signal seems to be essential, since a download that slows down and stops is very likely to turn into a busy signal if you don't get it running again quickly, and since it is for some reason a very common occurrence for hosts to slow down sending a file to a trickle, and eventually stop altogether. (Often, when a host decides to start neglecting one of your downloads, the throughput starts dropping like a stone and reaches 0 without a single additional percentage point bein reached -- and usually the file will end up languishing as "busy" or "needs sources" for days, incomplete, if you don't get the rest of it straight away!) Maybe a better idea is to send a keepalive automatically if the throughput drops below, say, a quarter of the peak throughput observed for that file. So a file that has hovered around 3-4K/s that slows down will trigger an automatic keepalive signal (rerequesting the next chunk from the host? I don't know much about the details of the protocol I'm afraid) if it dips below 1K/s. Alternatively, send them if the throughput drops to a flat zero but not otherwise.
• Related: stalled downloads waste a download slot at one end and an upload slot at the other end. Sometimes, if the download turns into a busy signal it will resume at a decent throughput almost immediately when it is reattempted. For these cases it would be nice to have a way to stop a download that doesn't remove it from the list entirely, but instead bumps it from "downloading" to "connecting" status. The original download connection is dropped and a new one is immediately started that attempts to resume a partial file, to the same host(s). This would be for if "keepalive" isn't prompting any response from the remote host. (All too common.)
• Limewire developers can do little about most of the misbehaving clients that slow down and stop an upload and then let it languish, or suddenly interrupt one and send a busy signal, but they can do something about one such client: Limewire. Unfortunately, I frequently see this behavior from hosts identifying themselves as Limewires. Hosts that aren't misconfigured (exporting a 10.* or 192.168.* address) and with my own peer not firewalled, I might add.

Better detection of corrupt files. I often get files arriving that never generated the "Limewire has discovered a corruption in..." message, but which are nonfunctional -- images that won't render or render only partially, mp3z with distortion or which cut off, videos that won't work or only the audio works (ones in avi format seem to be especially prone to this, probably because errors completely destroy the ability to decompress any of an avi file, rather than just introducing distortion the way they usually do in mp3/mpeg format files).

On top of that, there are the substitutions -- files that aren't as advertised, such as deliberately-spoofed mp3z and jpegs whose content has been completely replaced with (rather than just painted over with) spam of some sort.

All of these have in common that the received file will have a different MD5 sum or SHA1 from the file that produced your search result. In principle, discovering that the file you got is either damaged or a fraud should be almost 100% accurate -- the odds of a hash collision being very remote. In practise, though I was sure Limewire uses SHA1 to detect these situations, it apparently doesn't because the majority of obviously corrupt/spoofed files do not get detected as corrupt at all -- perhaps one in eight get detected, if that.

(This is entirely separate from the issue of spoofed search results -- spoofed search results are easy to detect and avoid, since they always produce ridiculous numbers of supposed sources, claim to have a high speed connection and zillions of open upload slots, and the filename is just your query string, sometimes modified in one of a few ways (changing spaces to underscores, adding extra underscores, and changing capitalization, typicaly). Others have already suggested ways to exclude spoofed search results, by blocking all the hosts that respond to a random nonsensical query string automatically and rerunning on occasion since the b*stards seem to have several whole blocks of ip addresses sometimes. I'm talking about search results that are clearly genuine, but when downloaded, the downloaded file is either a) damaged, or b) a substitute. Killing that damned ipod spammer is going to take both solutions -- not only are a bunch of spoofed hits returned for every query with ipod spam, with this one spammer having several whole netblocks to judge by the hosts I've already identified and manually blocked, but the f*cker is also substituting his crap in responses to non-spoofed search results. I've gotten several valid search results I downloaded only to find that the ipod spammer had somehow intercepted the download request, I guess by participating in the file's mesh, and sent me his bullcrap. NOT ONE of these was discovered to be corrupt by Limewire, even though the ipod spam and the original, legitimate search result surely had different SHA1s. (The result was known to be legitimate in each of these cases due to having few sources, an honest Modem speed advertised, a queue, and the result's file name actually containing things besides underscores that weren't in my query string.))

Another bug for ya -- searching for a specific file, I find that the search box malfunctions in a very specific way if you try to type in a query containing an underscore. The underscore doesn't appear and a noise is made. It almost looks as if it's being deliberately rejected; but that, of course, makes no sense as it's a common component of file names and therefore often needed to narrow down a query when a specific file is sought.

(The query language is also woefully simple -- it just seems to be an AND of the terms. Quoting a phrase will not result in an exact match being required, even -- the words in the phrase can still apparently match the query by occurring separately and in any order, and not just sequentially in the specified order. There's no OR facility, though you can kludge that by doing multiple searches. There's no apparent way to wild match "a single character or nothing" either -- it'd be nice if the query le?ann matched both leann and leeann and le*ann matched those and leighann as well, just as an example. Of course, with those and quoting, we'd need a way to match actual question marks, quote marks, and asterisks; say a backslash preceding any of those, or for a literal backslash, preceding a backslash. This would be nearly back-compatible since normal queries are just alphanumeric with some spaces anyway, but advanced users would be rewarded by the additional options when they had a tricky query.

A NOT function might be nice too, if most of the hits for something are turning out to be irrelevant. You can try to craft the query to reject the irrelevant results.

Anything that enables more narrowly targeted queries helps the network.

Google's search options should be your model here -- you can match on date or site (site is, admittedly, irrelevant here), as well as name and size, and the name can include exact phrases, "near", "not", and "or" words, and so forth. And this is without really getting into the "advanced search" options...

VERY USEFUL FEATURE!
 

I think LimeWire should include an extractor - useful for when you are downloading .zip, .rar, etc. files, when they are done downloading, you are able to extract them to a folder on your computer using LimeWire :)

Yes Good idiea.. but you don't know how long it may take them to code it

Re: VERY USEFUL FEATURE!
 

I don't want to see that at all.
On my 700MHz machine, any task that takes cpu cycles away from LW causes transfers to crawl. LW uses enough cpu already.
Just because LW can transfer various filetypes does it mean it needs to work with them too?
I already think the mp3 player's useless. Most everyone already has one, & at least I always have mine playing in the background when I'm on the computer. When I preview an audio file, It's usually to see if it's been converted from say, 64 to 320, or from mp3 to flac anyway. If I play a track with LW, I'll wind up hearing both tracks at once & then I can't hear quality value.
Would you want LW's installer to get fat enough to include a text editor? A photo editor? An avi converter? No way.

Re: Re: VERY USEFUL FEATURE!
 

i agree, i dont want a swiss army knife. i have stuff it for that, and itunes for listening etc.

Is there an option on limewire that lets me sort my files by tittle. If not it would help a lot if there was such a thing its so hard keeping up with all the files because its not organized in any sort

For your own purposes (in LimeWire), it is only necessary to click on the 'filename' column, which will sort that column into ascending sequence. Click again, and it will go to descending sequence. Click yet again, and future entries will return to random sequence by entry time (or whatever other sort you choose).

You may also use your Windows (or Mac) options to sort your entire folder via (Windows) 'view'->by name.