Thanks for all of the comments. Our apologies for not responding to some of the threads -- we really do have limited resources and have to make a tradeoff between working on the program and answering people's questions or responding to their comments. As you probably know, I and the other LimeWire people who post here are the developers who actually write the software (and there are only five of us!), so it's just a constant battle to try to get to everything!

We are working on the resuming issue in various ways. Actually, we're really tackling it by just improving the general architecture of the network so that resuming will improve along with a bunch of other things. The changes will really be on two fronts: 1) HUGE (Hash/URN Gnutella Extension), as mentioned above, will introduce a really nice scheme for efficiently finding duplicate of file on the network in a really robust way, which will improve resumes when you need to resume from another host and 2) Far better swarmed downloading using HTTP 1.1, which will make resuming an issue less often. This change will significantly improve download speeds.

So, we have at least a couple a neat features coming along in LimeWire 2.3.0 fairly soon. We will also be updating the integrated player at least on OS X to use the native QuickTime API, so you'll get the best sound available on any system, at least on OS X. We may integrate this as an optional download on other platforms as well.

I think 2.2.1 for Linux has a memory leak. Java is using like 20-60 cpu usage on average. Sometimes it gets higher than that when I search. 2.2.0 did not do that, it was a lot faster. Thats the only thing I've noticed with the new version.

Also when I leave 2.2.1 running overnight when I wake up the next morning its gone, core dumped. I get a lot of of console messages while it is running also. This are some of the last messages before it pooped out.


"Thread-1" (0x8c7ce10)
java.lang.Object@28D27108/296C5A90: <unowned>
Waiting to be notified:
"Thread-1289" (0x8f48830)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28D9FAB8/29694F20: <unowned>
Waiting to be notified:
"Thread-140" (0x8e1d5e8)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28E60520/296A6848: <unowned>
Waiting to be notified:
"Thread-184" (0x8ee1658)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28D9CB18/296A1368: <unowned>
Waiting to be notified:
"Thread-144" (0x8ea9ce0)
java.lang.Object@28D280B0/296C26F0: <unowned>
Waiting to be notified:
"Thread-1285" (0x8f44780)
com.limegroup.gnutella.downloader.ManagedDownloade r$RequeryLock@28E5C7E0/296A6D88: <unowned>
Waiting to be notified:
"Thread-185" (0x8ec7718)

Thats everything that was in the buffer. Hope it helps.

I have great respect for what you guys have accomplished, and I am very grateful, but I don't really understand this idea that resumes will naturally get better as the infrastructure is improved. Sure, if Limewire supported hashing, etc., then resuming downloads could be more robust -- assuming they worked at all. But it seems to me that they DON'T work at all, ever, and the real problem is not architectural but just that there are *specific bugs* in the resume implementation that prevent it from working. (e.g., when Limewire resumes a download, even automatically, it usually restarts it at the beginning in another file with a different name, or restarts at the beginning of an already partially downloaded file, overwriting what was already saved.)

So you can improve the architecture as much as you want but it seems to me that this won't be of any use unless the bugs are fixed. Example: requerying was introduced in 2.2 and unfortunately this feature is essentially worthless because when a partially downloaded file is automatically requeried and restarted, it doesn't resume properly. I don't see what the point is of adding features that can't be of any use until more fundamental bugs are fixed.

If you are gonna use Quicktime on Mac OS for the player .
Consider using DirectSound (Directx sound module) on the Windows version .

For one it doesn't hog that much resources as Quicktime .
Most people have Quicktime itself set to use DirectSound on Windows .
So if you use Quicktime , lot's of systems will load both Quicktime and Directx .
A waste of CPU time if you can pass the sound on to DirectSound in the first place .

VTOLfreak, I don't see the point in creating any more OS specific extensions to LimeWire (especially if it is that good-for-nothing player we're talking about). Quicktime could be called more or less cross-platform, but DirectSound is solely a windows issue.

And Quicktime is a resource hog .
Like it is now : make the player work decently or dump it .
Most Windows users chose to dump it .
It skips , its a resource hog and there is background noise .
And with an SB Live I do not tolerate those things .

It's just an suggestion .
Because if you don't like the player , don't use it !
I don't use it ...

Of course I don't use it, but why would YOU make such a suggestion, if you aren't using it anyway? As Adam stated, windows users wouldn't have to use the Quicktime enabled version.

It's turned on by default .
Then it skips and people too stupid to read the manual or take a look in the options screen mail me and complain .
I used did not bother for these annoyances but since I'm in the CLW project I get more and more mail .

VTOLfreak) You get E-Mails hehe :-) I'm the sole developer for Mac versions of CLW and I get nothing (It could be that they don't have my E-Mail) But hehe... And I really wish our host would finish switching their backend server (It's up more than down here)