And the f*cking thing jsut hung AGAIN. I switched to it after that last post and got nothing but a blank grey window. Minimizing and unminimizing didn't change anything; maximizing and unmaximizing either. Trying to reduce it to the tray by the close box had no effect whatsoever; Limewire simply ignored me, which is ABSOLUTELY NOT CORRECT BEHAVIOR FOR AN INTERACTIVE APPLICATION -- UNDER --ANY-- CIRCUMSTANCES WHATSOEVER!!!!! I am fed up. I want these bugs fixed. I expect a genuinely STABLE "stable branch" version on the website by next Wednesday evening or ****ing else!

I don't like having to regularly kill something via task manager. I don't like it losing my download list when I do. I don't like the way it brainlessly loses the list even though while riffling through its directories earlier I saw that it DOES save a ****** backup -- which either it doesn't use, or stupidly corrupts at the same time as the main copy instead of always leaving the backup file as the last known-good version. I don't like applications that gobble up RAM and then complain that a full gigabyte is still not enough for them, and I don't like anything that regularly hangs or loses data for whatever reason. There's no excuse for showstopper-magnitude problems like this outside the odd-numbered branch, for Christ's sake; no excuse at all. Nor for posting "minimum system requirements" of a few measly megs of memory (64, was it?) and a couple hundred MHz CPU when I regularly see it max out the CPU on a 1.5GHz Athlon and complain of low memory on a machine with sixteen! times! the minimum recommended memory. And I don't need anomalously heavy usage to experience these issues either; simply starting it with a blank download list and leaving it on overnight suffices to hang the 4.0 series on my machine. Which ought logically to be able to run ten instances concurrently without more than a little slowness with bandwidth, given that I never see it exceed around 120M actual memory usage or 1/3 the total bandwidth I have.

I don't know if it's because it's written in Java, or because the developers are clueless, or because it just doesn't play nice with Windows XP. The fact of the matter is it just plain does not work acceptably on a run of the mill middle-high end system with the commonest end-user OS, up to date on service packs and drivers, with a broadband connection, and sharing a reasonably large library of files. That's not tolerable. The speed and stability of 3.3.5 must be brought back or else the features have to start being scaled back as too expensive in terms of performance. That's the bottom line.

You have till next Wednesday, close of business. If I don't see a version on the site then that actually works on my (by no means low-end) machine, then it's the end of any chance I'll ever spend a dime on pro, and the start of a very high likelihood I'll report these issues rather more widely so as to facilitate informed consumer choice.

If there's any remainind doubt that these problems are occurring with nonexcessive or abnormal usage and a fairly beefy machine, the following just happened:

Started it up again -- predictably, it refused to resume old downloads. Sharing 10,681 files. Hash index recently rebuilt. I did a single search; after five minutes I switched back to Limewire and found 192 results (some duplicates, and most files I already have). Selected them all and hit download, then sorted through the overwrite dialogs hitting "no" to each. (This, rather than just sort by "quality" and select just the ones with stars, because I've found the paper-with-check often fails to appear for files I have and sometimes appears for files I don't. Until it works I'm stuck with this method for making groups of files complete.) About 3/4 of the way through the list, Limewire hung, and task manager showed greatly decreased network activity and over 100 threads. About five minutes later, the thread count dropped to around 50 and the UI became responsive again. At this point commit charge 798M/1622M, actually on the high side for usual; note that 1GB of the 1622 is *physical* ram so the system's about two more Limewire instances away from swapping, let alone running out of memory, based on its current process size of 103,664K (that's VM process size listed in Task Manager -- both virtual machine and virtual memory, so, the true size of the process excluding DLLs concurrently in use by other processes). Nonetheless, there's an out of memory error dialog displayed prominently in the Limewire UI, mocking me and my gigabyte of RAM. I dismiss it, and note that my connection quality is merely good -- one red bar. Within seconds, though, it becomes two and then three! Limewire has apparently taken it upon itself to close some connections without any input from me on the matter -- and it must be happening locally, since independent failures at three remote hosts (or routing three remote hosts) are very unlikely indeed. Astronomically so. Either my network connection is malfunctioning or Limewire is, and the network connection checks out fine since browsing to this "submit a post" page in Firefox gives no trouble or so much as a hint of delay. If www.gnutellaforums.com is reachable it's unlikely three specific independent hosts in geographically random locations (thanks to turning off locale preferencing!) all became unreachable within seconds of one another. Oh no, Limewire is surely to blame here, taking the initiative to trim bandwidth usage I suppose, while the task manager's network monitor shows a full 2/3 of my bandwidth available. (This is with normal activity; it recovered about when the bogus out of memory error appeared.) Shortly the connection quality recovers. In the download list: seven files. Miraculously, one of them actually ****ing downloads successfully in seconds, as I watch in astonishment.

Seven files, and up for about ten minutes, one search done which returned a typical number of results -- that's all it takes to get unacceptable crashes/misbehavior from Limewire on a 1.5GHz 1GB Athlon machine. The developers must test this on 4GB quad Xeon boxes or something if their test suites don't reveal problems like this prerelease. Nothing, however, excuses them from releasing into the stable branch code that must have had everyone betatesting 3.9.x pulling out their hair at the error messages, the frequent hangs and data loss... What were they THINKING?!

Addendum: it failed to find the other 6 files on requery, and it also failed to find more than about 800 additional MB to allocate on several further occasions, each announced with great fanfare with a huge, focus-stealing dialog box. (Exactly how big a chunk it requested each time is a mystery, but it has to have exceeded 800M for the system not to find it somewhere in the bowels of the 1600M virtual memory with only 700-odd in use.) I closed it down, and waited the interminable time it takes for the process to disappear from task manager (over 2 minutes this time; I clocked it, and sometimes it's over ten) before launching a new instance.

Predictable as cloudless skies in the weather forecast for Cairo: "Sorry, but Limewire was unable to resume your old downloads!" There's no excuse for the code to display that dialog even being in the source tree, let alone actually being executed. And for a list of only six files? How ****ing hard can it be to load six old downloads? Especially when I've seen older versions (3.3.5 comes to mind) able to load over 2000(!) without difficulty -- and that arguably *is* excessive.

This software sucks. Version 4 just plain doesn't work. It sort of goes through the motions of vaguely resembling something that's pretending to work while actually only being a cardboard cutout that does no work at all well -- a big, fat, lardy 100MB cardboard cutout that is. And it sure uses a lot of CPU doing nearly nothing except failing to present a UI, composing the latest out of memory error dialog of doom to present to me like a birthday gift from Satan (the clocks must all be wrong down there since it's not my birthday for some months yet, but since they can't ever see the ****ing sun or moon from there I can't really blame them for failing to keep an accurate calendar), and seeing how many concurrent threads it can spawn before Windows XP chokes (answer: over 700, since I've seen it grow to that many threads more than once both in some of the poorer 3.8.x versions and all the 4.0.x ones, before I killed the process so as not to find out how many it takes to crash XP and lose all my unsaved work in other applications, the loss of unsaved work in Limewire being by then a foregone conclusion)...

Maybe I can't blame Satan for not keeping an accurate calendar but I sure as hell can blame Limewire for not keeping my download list across sessions, despite professing to have done so since version 2.x. My official position is that I'm still waiting for this feature to actually be implemented.

Preliminary indications are that you have failed. 4.0.5 is slow the UI intermittently hangs, and I've already seen three "out of memory" errors on my 1GB system. During this time, there were never more than five items in the download list pane -- and the only likely culprit for any kind of "bad interaction", firewall software, was disabled the whole while. Commit charge 481/1622M. If it genuinely failed a memory allocation, it wanted over 1100M! (A smaller allocation from a fragmented heap might explain it, except the machine was rebooted less than an hour ago and there hasn't been time for the machine's memory to get badly fragmented yet. I've not done much since the reboot save a bit of surfing and launching Limewire and attempting to use it.)

If you mean things like spyware, viruses, and the like, the system's clean -- I scan new executables, I run Spybot S&D, and so forth. If there's any malware lurking inside my machine I'll eat my dusty, sputtery casefan for a crunchy after-dinner treat. :P

About the only thing I can think of that could possibly be the problem if Limewire itself isn't, especially now firewall software is eliminated as a possible cause, is the VM itself. But it's Sun's most recent version (1.4.2), so it's neither out of date nor a weird, dubious 3rd party VM that may not implement the full spec. In short, Limewire performs poorly on a commonplace OS with the reference implementation VM and a decent hunk of hardware resources to draw upon. I hate to think how horribly 4.0.5 must run, if it can even get out of the starting gate, on the many older P3-266 128MB Windows 98SE machines still floating around out there!

Only an idea but do you share many mp3s with ID3v2 tags? If yes then remove them temporary from the shared directory and see if it helps!?

I'll try it, but why on earth would it? Limewire performance shouldn't be affected at all by the content of the files, and it should scale reasonably with the quantity of shared files.

MP3 thing: As a test, I removed "mp3" from the list of shared file extensions. It didn't run any better for the rest of that session but when I closed and restarted limewire, it seems to be running more smoothly, with 95M process size instead of 105-120. Still sharing 9433 files. Any clue what's going on here? It does look as if sharing one mp3 file is more "expensive" somehow than sharing one jpeg file or even large mpeg file, in terms of performance and memory demand. And why would having lots of mp3s shared make it either think it needed more than 1GB RAM or think I no longer had anywhere near 1GB RAM?

Peerless: what "utilities" package? For what software? What's the detection procedure for whatever it was that you had? URL to read up on it? Any new kind of malware existing detector software doesn't catch I need to know more about.

Maybe Limewire doesn't have a problem with mp3 files. Maybe the RIAA does, and when they detect someone sharing files with that extension they try to flood them off the net? Limewire might be freaking out due to huge amounts of malformed traffic intended to bring it down or degrade its performance. Even if you have just legitimate mp3s, maybe the RIAA still takes a preemptive "shoot first and ask questions later" approach...wouldn't surprise me at least to find them playing dirty in such a way!

Interesting RIAA DOS idea, Zarcuthra, but it doesn't seem to jibe with my seeing reduced network activity during episodes of particular slowness/unresponsiveness.

Also, it's bloated back up to 105MB and I just had the UI lock up for a couple of minutes, about 30 items currently in the download list and still sharing 9433 files. No complaints that 1GB is not enough from it yet this session though.

I think we have three problems here:
1. It's inefficient -- sharing 9433 files makes it need 95MB? Assuming the mem usage in a clean install is around 30M (which, though high, coincides with most of the major browsers such as Firefox), this is about 6500 bytes more for each shared file. How much of that really has to be resident all the time and how much can be retrieved when the file's requested? It seems to me only the filename and maybe metadata for matching and maybe the hash need to remain in RAM at all times to match against incoming queries -- and for leaves shielded by ultrapeers (including my node), not even that. The info needs to be sent to ultrapeers upon connection (and reconnection) and then ultrapeers manage routing queries to me only if I have matches on my system. So, I'd say zero bytes need to be resident per shared file on average!

Add to that that adding about 30 downloads made it bloat to 105, or 20 more megs, suggesting an astounding 600K(!) of resident data for each item. That's assuming, of course, that it doesn't leak, which since it's Java it shouldn't.

Why does it need 600K (not bytes, K!) per download list entry? Earlier versions didn't -- 3.3.5 could have 2000(!) download items and run OK on a half-gig machine. That means, assuming it used all available RAM for just resident download information, it used at most 256K per download item. I find it unlikely it used even that much. In fact I think:

2. It leaks. Despite running in a garbage collecting environment, it leaks. I guess never-to-be-used-again objects remain reachable. Does it create and then discard circular data structures? Some GC implementations (reference counting, for one) won't discover that two objects are garbage if they each refer to the other but nothing else refers to either. I hoped Java's wasn't among them, but the fact is Limewire seems to leak memory. And recent versions (4.0 and above) seem to hemmorhage memory.

3. Like some archaic, long-forgotten MS-DOS applications, it doesn't recognize all of the installed memory. While those DOS applications recognized only 640K (which "ought to be enough for anybody", according to Bill Gates), even if you had several megs XMS or *** memory, Limewire seems to recognize 128M. That's an improvement, but it's not enough. Obviously. This, I think, is the only logical explanation for it reporting "out of memory" errors when its process size is around 120M and the system still has gobs of free ram. It's that, or it's trying to allocate hundreds of meg in one chunk, or it's lying altogether. Anyway, there's no excuse for not using as much RAM as needed out of all that's available on a modern 32 bit platform with protected mode flat virtual memory addressing. This isn't MS-DOS or the ancient hoary versions of MacOS where every app had a fixed allotment of RAM and hairy near and far pointers and segments and offsets were commonplace programming vocabulary. The only case now where per-application memory restrictions make sense is in some circumstances involving multi-user time sharing systems. And since my box isn't one of these, it's a single user home machine, I should be able to turn any such restriction off. If there is such a setting buried in the bowels of Limewire I've been unable to find it, either in the options dialog or with a hunt for Limewire-related registry keys in regedit or by opening every ascii file in either Limewire's program directory or its settings ".limewire" directory in a text editor! This suggests if such a "feature" exists, it was, in a true display of archaism, hard-coded without any way at all for end-users to alter it to suit their particular circumstances! That's really stupid. Hard-coded limits can't be outgrown without changing and recompiling the source, which most end-users can't be bothered to do even with open source stuff and can't do with closed-source, and Moore's Law makes the outgrowing of such limits inevitable. Not foreseeing the need to revise them upward on high end machines in the near future is like not foreseeing that using a two-digit field to store dates was going to be a problem in a few years' time back in the 1990s -- and yet there was software written in that decade that needed Y2K fixes.

Of course, people had to pay for those fixes. Could this be built-in obsolescence? A way to force Pro purchasers to buy upgrades to keep their Limewire functioning as the machines have more and more RAM and user tasks demand more and more? I hope not. That would indicate very underhanded motives on the part of the development team. And why put a built-in obsolescence restriction in the free version? I suppose to motivate people to buy pro? It won't work -- all it does is make people try Limewire Basic, think "This runs like a pig and crashes all the time with memory errors on my gigabyte machine! I'm not paying for crap like this!" and switch to Gnucleus. Which doesn't work with Zonealarm, unfortunately, or I'd switch to Gnucleus!