-Maximum - + Minimum file size filter-
i just saw a stupid file with the size of only 851,7KB calling up itself in every search, i would sure be nice to search/download files withouth clicking that file and get a virus on my pc!!!!

allow user to download entire albums easily (egon slsk where you can download containing folder

I'm not sure to what extent the LW devs can help with these problems with bugfixes/features/changes, but here goes.

My modus operandi when using Limewire is as follows: I share a select few files from one directory and download to another. I keep an Explorer window open to the download directory. Every so often I examine these and delete any bad/unacceptable files (spoofed, spam, damaged, or mislabeled and contains something horrible). Also, less often I move the files out and categorize them, adding some to the shared files, etc. -- and replace them with zero length files of the same name, so I'll get overwrite prompts for these files and not redownload ones I already have.

Here're the problems. First, the icons in results lists don't accurately reflect which files I already have. Files with a green check don't always produce an overwrite prompt (and in the new beta, sometimes produce neither an overwrite prompt nor the "this file is the same as..." one -- if the green check doesn't mean the file name exists in the download dir already, and doesn't even mean the file's content is duplicated elsewhere on your hard drive, then what the heck does it mean?) and files often show stars that are downloading or downloaded, or torn paper, or show four stars but don't download quickly or at all -- in general, the icon system is a mess and doesn't seem to be very accurate at all. Of course, to compound this the overwrite prompt does not have a "No to all" button...

Next problem is that deleting a spam or other bad file causes Explorer to hang the next time a file is downloaded. Also, the Windows picture previewer takes forever to preview files from the download directory. It sits at "generating preview..." for ages. The odd thing is, if I browse on inside the previewer, it takes almost no time "generating preview" for the subsequent images -- it's only the first one viewed that takes forever to generate a preview. It seems to me that this has gotten worse with time, as well. The only difference between that directory and others as far as statistics and permissions and such are concerned is that it has tens of thousands of files in it. The previewer's preview generation should scale with the size of the file, not the whole directory, however, and should be the same for every file previewed... Since these seem to be Exploder bugs I'm not sure what you can do about them, though perhaps someone knows of workarounds. Googling didn't turn up any. Disabling all non-MS shell extensions didn't fix the problems, nor did disabling the image capture service. (WinXP home SP2)

The ideal solution with Limewire would be to make the following additions/changes:

• You can designate directory trees for file matching that are not shared. This would obviate the need for the zero length files I use -- I could match against all my downloads without needing them and without sharing everything downloaded. Sharing everything downloaded caused huge performance problems, crashes etc. once the number of files got much above 10,000 back in the day -- even with only a few upload slots. Somehow shared files you weren't actively uploading contributed to memory/CPU use? It also stopped me deleting spam etc. and moving and categorizing files without exiting limewire first because the files would be "in use".
• The icons accurately reflect the file status. A four star result really is on a non-busy host with a good connection. A green checked file really does have the same MD5 sum as a file in the above proposed directory tree somewhere. And so on.
• Performance is improved all around. The new beta seems to perform much worse than 4.8.1, and apparently it's linked to how many files are in your download directory -- even if they aren't being shared. But I must have as many files in the download directory as I've ever downloaded, or else I won't be able to avoid downloading files I've already downloaded! You see my problem... A better way to reliably weed out files that match files (not necessarily shared) you already downloaded is needed, and it has to scale to hundreds of thousands of files, given that it's already tens of thousands and will only keep growing, especially as disks and computers get bigger.
• Performance of Limewire doesn't seem to improve by adding RAM to the machine. I've gone from 256MB to 512 and then 1GB on this machine over the past several years and every other performance-heavy app I use has shown big jumps in performance both times. Not Limewire. This is very peculiar.
• If you can, duplicate Explorer's previewing functionality in the Library tab and make the Library tab much saner in terms of performance. At a guess, it currently loads something into RAM for every file shared (whether currently uploading or not), every incomplete file (whether currently downloading or not), and every file in the download directory. This stuff should be accessed from a random access DB on disk, rather than data structures in memory, with the operating system's disk caching taking care of keeping frequently used records in the DB in RAM. This would vastly improve memory performance, which is currently horrible especially if you have numerous files in any one of those three categories. Also, duplicating Explorer's previewing functionality would obviate the need to have an Explorer window open on the download directory to view and, sometimes, move or delete new files -- hopefully avoiding the Explorer crash described above. (Which is really nasty by the way. The window locks hard and Explorer goes to 100% CPU use. On top of the high CPU use from Limewire. Which usually means Limewire hangs, half of everything else hangs, and the system direly needs a reboot. It's a struggle just to save everything you had unsaved changes in because of the CPU use!)

Hope someone can help here.

Hi I have 3 kids and they all use the computer and one day one of them deleted a movie file i waited for 3 days to download I can't find it anywhere it didn't go to the recycle bin as i expected and its gone lol

Hi Mandelbrot,

Searching for File Hashes doesn't scale well in the current Gnutella Network, which means they waste lots of bandwidth for all Users.
(Check http://gnufu.net - Query Routing Protocol for more information )

To do this, LW would have to run two seperate networks: One for Hashes (with a completely different organisation) and one for normal searches (for which the current Gnutella Net is strongly optimized).

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

Well then implement that separate network. As things stand, requeries are nearly useless (and the recent betas only made them worse) and you often end up with most of the files you want languishing "awaiting sources" -- lots of them after downloading 50% and then deciding that the file no longer existed anywhere on the internet anymore. :P

for movies, i highly suggest using bittorrent. i really only consider using gnutella for files under 100MB. BUT the files that i do download from bittorrent i do share on the gnutella network. IMO this helps adds more content to the network.

Most of the files I'm downloading are under 100k. :P

Image dimensions should be one of the column choices for media searches -- and should replace the useless Bitrate column as the default rightmost column for image searches.

The ipod spams would be easier to avoid this way, since the jpegs are all the same dimensions. They come in several file sizes (anyone have a clue why?) and they don't ALWAYS seem to show huge numbers of sources, a T1 speed, and a name that contains all the query terms, in order, and no other words. They OFTEN do, but not always, not by a long shot. The wmvs are all soo small in file size to be legit, which makes those easy to avoid. The jpegs that do fit the pattern described above are equally easy to avoid. But the "stealth ipods", jpegs with a couple of modem and cable sources and a random name that isn't just your query string slightly modified, continue to be a massive nuisance -- especially because every time I delete some from my download directory, the next time Limewire successfully downloads a file Explorer wedges and I have to reboot.

…instead of sticking it in the middle of limewire.props as a line of text.

I'd like to be able to provide you folks with a half decent filter. Editing the limewire.props file works, but this is clearly beyond the abilities of the average user.

If I could just provide a standalone file with simple instructions on where to put it, a lot of people would enjoy the benefit of being able to block most of the spammers and hostiles out there.

See "The LimeWire Fullsize Hosts Filter!" for details on how to install and use it.

Alternate link (If the forum moves to it's new address before you see this): "The LimeWire Fullsize Hosts Filter!"