LimeWire 2.5.1 (pro), Java 1.4, W2K...

A couple of recoverable error bug reports have been sent to Bugs@limewire.com
...

Minor detail - probably more to do with Java than LimeWire... The dialogue boxes for selecting download and share locations do not support Windows network locations - i.e. I cannot browse to a network location (e.g. \\Mark\D\LimeWire).

I /can/ enter the location manually and it all seems to work (albeit - hashing of a few Gig across a 100Mb network connection is not very practical).
...

I haven't yet been able to shut down LimeWire and restart it without LimeWire getting locked into a state where it uses 100% CPU (Athlon XP 1500). It might eventually recover from this state - but not within the half hour to an hour that I've allowed it so far.

I have a suspicion that the problem relates to an inconsistency between the download.dat file and the actual files in the incomplete folder. If I delete the entire contents of the incomplete folder then LimeWire will start up without a problem (obviously with no files in the download queue).

Usually LimeWire does not immediately use 100% of CPU, but starts to do so at some point as it goes through the download queue.
...

I still have a problem whereby uploads drop off to 0KB/s and effectively block my upload queue (I have my upload bandwidth throttled).
...

When upgrading from 2.4.4 to 2.5.0 and then to 2.5.1, LimeWire did *not* keep my previous settings.

Mark

LW 2.5.3 / Mac OS 9.2.2

I previously said I was getting a lot of uploads, but I was only glancing occasionally at occupied slots and not paying attention to speed. I have now noticed that they all seem to sit at 0k and if I give them more bandwidth, they disappear.

Still LW 2.5.1...

I've been reminded (since it has just happened again) that occasionally LimeWire gets its names in a twist.

I've just downloaded a file from a series (avi) - LimeWire says the download is complete and the size was around 330MB.

The actual file that was downloaded is from the same series but has a different name and is around 20MB. (size is irrelevant - I mention it only to illustrate that the files do not match - the previous occassion that I caught, the downloaded file was larger than the file LimeWire thought it had downloade).

The actual downloaded file is correctly named - but was never in my download queue.

Mark

I think the weakest link in LimeWire is the upload part, as duplicate uploads are allowed and bandwidth utilisation is far from optimal, especially when throttled.
Also the settings aren't remembered when installing a new version, something new because prior versions took precedent preferences on osX.
I hope to see 2.6 in near future to correct those issues

i really find it ridiculous, that you claim this (german) translation was made by a native speaker. never! when i look at the german messages in cvs i can't believe that this translation is from a german...

Interesting on the German issue. Our translator is actually a native German speaker. Are there specific words or phrases that should be changed? Feel free to go to join the translation project at:

http://www.limewire.org/project/www/translate.html

Phillipe Verdy, one of our open source programmers, would be delighted if you wanted to take up making changes to that document. It's really easy to do -- you just have to change a text file.

Hi Adam,
I'm curious, what you are going to implement next. Could you please give us a quick preview of LimeWire 2.6? I know that you are working on non-blocking IO for Java 1.4 users (which as far as I do understand, will not improve the network itself significantly) and out-of-band replies (IMHO a very good idea).

Do you plan on implementing upload queues soon? I think it would be a great addition since it could really reduce the amount of requeries sent through the network while dramatically increasing the download success rate.

What does LimeWire think about partial file sharing. It'd be certainly useful for larger files. Do you expect it to be implemented soon?

How about gnutella weblinks? There are already a few websites offering links directing to files on the gnutella network via magnet-uris. I suspect integrating different browsers with java to implement one-click gnutella links is probably a little complicated, but I'd be already content with the possibility to copy the weblink, paste it into LimeWire and hit the "Add To Wishlist" button.

Another great feature that I would really, really love to see, would be the ability to run the LimeWire core in daemon mode, accessing it through a graphical frontend (possibly even from a remote computer) or even accessing the core from a webbrowser (with some kind of middleware mediating between browser and limewire core, - possibly a browser plugin). I believe it would be a great addition, if you could just click on a gnutella weblink, a go!zilla-like window pops up, showing you the progress of your download and a few minutes (hours, days,...) later the file is on your disk.

Maybe the last one is nothing for the next point release, but how about the other features: partial filesharing, upload queues and weblinks?

--
greg

IMHO almost every phrase must be changed. many sentences just seem, as if they were translated by a machine. that's the reason i don't really believe in you claiming that the translation is by a native speaker. if it is so, then tell the native speaker, he should translate the whole messages more freely, as no german will ever understand what f.e. is meant bei a "hauptrechner". (in fact it isn't even right, if you tranlate it back it is something like a "main computer" and not a host.)