View Single Post
  #203 (permalink)  
Old July 5th, 2005
Spextacle
Guest
 
Posts: n/a
Exclamation

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.
Reply With Quote