Too early to tell yet if the disconnection problem can still occur, but another problem is already apparent: sometimes Limewire hangs for a significant period of time with nearly no CPU use. It never used to freeze without nearly 100% CPU use. So it looks like it now hangs temporarily under a whole new set of circumstances using 4.9.4 and Java 1.5.0_04, hangs that didn't happen with 1.5.0_03.

Since around beta 4.9.1, every search seems to produce a handful of undownloadable results. They show stars or torn paper, and if you select them and hit "download" they don't change to folders, don't actually start downloading or anything, and no prompt pops up either (such as "overwrite this file?").

Also, since installing beta 4.9.4 I'm having odd problems previewing image files I've downloaded. The Windows previewer keeps showing "drawing failed" or getting hung "generating preview..." or "drawing image..." -- the images look fine when opened in a paint program so it's the previewer that's malfunctioning rather than the files being corrupt. (Besides, I have Lime set to automatically abort corrupted downloads.) When I switched to this Web browser window to report these problems, the browser acted funny too! The display only partly redrew, and buttons were missing from the toolbar and the Google search box was missing. This is with a recent version of Firefox. No error messages, just abnormal behavior. Eventually it redrew itself properly and I wrote this.

Nope. Didn't fix it. I went out for dinner, came home, and Limewire showed five red bars and the "you don't have an internet connection" dialog box. Of course, I have an always-on internet connection so this is patently ridiculous. Closing the dialog and telling it to "connect" sufficed to fix it however, without restarting the client. So maybe there's some improvement; although switching to Java 1.5.0_04 didn't stop the problem happening in the first place it may have made it easier to recover from.

(Sanity check: yes I could browse Web sites just fine both before I left and right when I got back. No, I hadn't changed anything -- in fact I wasn't physically present to have changed anything even accidentally, this time.)

Please update to the most recent beta (at this moment 4.9.4) http://www.limewire.com/english/content/beta.shtml

If you still have problems with drops in connections & end up disconnect or of poor connection please see beta 4.9.4 dropping connections

Here are some bugs introduced in beta 4.9.0 that are still present in 4.9.4.

• Hitting "resume" on a file "awaiting sources" no longer attempts to connect to known, but busy, sources of the file. Doing this caused Limewire 4.8.1 to make an honest fresh attempt to connect to most files, occasionally resulting in a download. In all of the betas, it does nothing whatsoever.
• Stderr console frequently shows warnings such as "ignoring cancelled key" that did not occur with LW 4.8.1. What impact the cause of these warnings has on the app's functionality is hard to determine but it's doubtful it's any good.
• For some reason, the sort order has been changed so that when downloads are sorted by status, files waiting in line no longer sort last. Busy ones now sort last, and files waiting in line sort second-to-last. This seems to be related to a change in the wording for files with busy sources.

Longest-standing headaches still present in betas that were also present in 4.8.1:

• Sorting by status makes download list items jump around -- which is OK until you try to select a specific item, and it always interprets your mouse click as occurring one jump later than it really did. The real problem is that mouse clicks seem to be ignored for a time, then treated as having just occurred, instead of processed immediately. Fix: Boost the UI event handling thread to highest priority to it preempts all other Limewire threads when a UI event is generated.
• Sorting a large download list by name is slow. What are you using -- bubble sort? Use quicksort -- it comes with the JDK so there's no excuse for using anything quadratic like bubble sort.
• Mem & CPU use are still high, though better in the recent betas.
• The icons on search results still all seem to mean the same thing, that being "It's anyone's guess whether you have the file already or not, and if not whether it's going to download quickly, slowly, never, or it already is". Is it even possible to get it working? The number of failed attempts so far suggests it might not be, in which case replacing them with something actually useful, such as bitzi ratings for the files, might be a better idea than trying to fix the current icon system.
• It still freezes for a short time sometimes when initiating a search, especially after a period of inactivity, and when downloads complete. Clearing a bunch of duds out of the download list with a mass select and cancel download, or with (do not click this button!) clear inactive, causes the UI to hang until you force-quit Limewire.
• There is still no "No to all" on the overwrite prompt, or "remember this decision" check box, or similar feature. It is sorely needed. (Unless by some miracle you get those icons working, especially so that green checks appear beside all and only the files you already have. Given the current track record, this seems unlikely -- all the failed attempts to fix those icons suggest there are deep technical reasons making fixing them lie somewhere between "difficult" and "impossible", whereas adding the requested functionality to the overwrite prompt is probably a two-minute job.)

On a Windows XP box with Sygate Personal Firewall. Sygate has been told to let all Limewire traffic by unimpeded. Limewire has been told there's no proxy and no firewall. Beta 4.9.3 added the firewall detection thing in the status line. Beta 4.9.4 promptly broke it -- sometimes it shows "Limewire has detected a firewall" even though that's impossible on my setup. Sygate is configured to be transparent to Limewire, and Limewire has been told not to try to detect a firewall. How can this be happening?

The oddest thing is that despite incorrect firewall detection it actually seems to be downloading things and functioning OK.

Here's a strange one.

With recent betas, run a search for images and the media filter is likely to show "video" or "audio" as well as images as filtering options. Click the oddball media filter and the result list is pared down to ... not even an animated .gif, which might qualify as "video" in a technical sense. Just one or more ordinary jpegs.

But your priority should be getting Limewire 5 to have a user interface that is actually decently responsive. Limewire 4 or 3 anything seem to process input in batches, then store up but otherwise ignore input for a while, then process another batch. For example, trying to scroll through search results with a wheel mouse is an exercise in futility: first it won't budge, then it will start dancing up and down by itself and keep doing so for a while even if you take your hand completely off the mouse. Then when you go to scroll again it just sits wherever it landed ... the interface sometimes becomes almost totally unusable. Responding promptly to user input should take priority over whatever "thinking" an interactive application might do under the hood -- period. This kind of sluggish and frequently uncontrollable behavior is unacceptable, and that it has remained this prone to hangs, slowdowns, and ignoring-everything-you-do-for-five-minutes-then-trying-to-do-it-all-in-the-next-five-seconds through at least two major versions is unconscionable.

For a while now it's been impossible to clear out a large number of downloads without Limewire completely locking up. It's still the case with 4.9.4: the items disappear when you hit cancel or clear inactive, but the interface then stops responding. Task manager shows that Limewire has hung with 100% cpu use. If a stderr console is open it floods with lines like these:

The time given is wrong by exactly an hour -- the system clock when this one appeared was 10:27:34 PM.

Looks like clearing out downloads makes Limewire unload a semiautomatic directly into its own foot, resulting in the observed crash.

We'll try to reproduce this. Let us know:

* The speed of your computer (CPU, RAM, etc)
* Java version
* how many downloads approximately were there you tried to clear them

Couple GHz, 1GB RAM. Not top of the line but hardly pants either. And it's not like I'm trying to run the latest doom 3 expansion pack on it -- just network and productivity stuff mainly.



1.5.0_04 according to java -version. What's the _04 part mean anyway?

I don't know; a couple thousand?

Anyway the firehose stream of console warnings make me think whatever it fired into its foot may have been illegally converted for fully automatic fire. :P