LimeWire 4.1.8 Beta

[sberlin]

The LimeWire 4.1.8 beta has been released. Pro users can download it from their personal download page. The free version is available at the LimeWire Beta Page.

LimeWire 4.1.8 includes the following changes:
- Bootstrapping now makes use of multicast hosts prior to attempting UDP Host Caches.
- Locale preferencing is less important (which should reduce the fragmentation that some locales are seeing).
- Bootstrapping is even faster, making use of more lightweight UDP pinging to hosts prior to making heavyweight TCP connections.
- Corrupted data on disk can no longer cause LimeWire to report errors or fail to start up.
- The 'Review' and 'Tell A Friend' links from the Help menu have been removed.
- Spanish users will see a completely new (nearly 100% complete) translation.

LimeWire 4.1.8 is another step on the road to 4.2. Please continue to let us know about any problems with the betas. Thanks very much to all the contributors and beta testers who have helped and continue to help make LimeWire the best file sharing program on the planet.

Thanks,
The LimeWire Team

[arne_bab]

Does that mean, the UDPHC-implementation you posted in the GDF is already working? Great!

Is the geman translation complete?

[backmann]

Originally posted by sberlin
- Spanish users will see a completely new (nearly 100% complete) translation.

That's a good step.

Ivan
In the dark we make a brighter light

[stief]

With 7 free slots available, 2 hosts are queued behind 3 slow uploaders (upload bandwidth throttled to 90KB/s).

Queued at (1) 158.3 KB 0 BearShare 4.5.2.2 (Nederlands)
Queued at (2) 348.9 KB 0 LimeWire/4.0.8 (Pro)
Uploading 74,498 KB 0 gtk-gnutella/0.94 (2004-07-10; GTK2; Linux 2.4.23 i686) 0KB/s
Uploading 293.6 MB 0 gtk-gnutella/0.94 (2004-07-10; GTK2; Linux 2.4.23 i686) 0KB/s 33:23:13:15
Uploading 329.8 MB 0 gtk-gnutella/0.94 (2004-07-10; GTK2; Linux 2.4.23 i686) 0KB/s

The LimeWire upload Queued at (2) eventually changed to "Transfer Interrupted". I couldn't see anything (like browse host) in the upload request and response stats that could account for the 7 free slots being tied up somehow.

After about 20 minutes I killed the gtk's, and then new unique hosts were able to begin uploads.

[zab]

Limewire actually does not encourage the queue to be filled to its maximum capacity. It stops sending back search results as soon it knows it will not be able to immediately service an upload.

Most of the time uploads get in the queue because of alternate locations, Unless your ip address was listed as an alternate location for some file(s) on a lot of hosts, hardly anybody will enter your queue once your upload slots fill up.

However, the issue with the very slow uploads not getting killed is something interesting. Can you see if it happens only to gtkg's?

[stief]

Thanks for the info. A quick check of the uploads since show a couple of "Complete 452.6 KB 100 gtk-gnutella/0.94 (2004-07-10; GTK2; Linux 2.4.23 i686)" . So, that host/vendor was subsequently able to complete a few uploads.

btw--how do I sort the Monitor table by "time started"? (Auto clear is unchecked).

Still, LW should have been able to serve more uploads with only 3 slots taken, no? There was plenty of bandwidth available.

[Lord of the Rings]

LW 4.1.7: Last night I ran out of space on my OSX partition. 1st time that's ever happened. I forgot to check the VM amount. I was in too much of a panic trying to create space. (Lucky I just got an external HDD yesterday.) I had LW running about 3 days. I was not keen to close LW at the time. But I haven't tried 4.1.8 yet.

[stief]

Grrr--only 13 hrs as an Ultrapeer with 4.1.8, running NO downloads or searches (only uploads) and I got the "startup disk is almost full" message just now.

LimeWire version 4.1.8 Pro
Java version 1.4.2_05 from Apple Computer, Inc.
Mac OS X v. 10.3.5 on ppc
Free/total memory: 16931728/51314688[edit:details snipped]

LW4.1.8 isn't ready for OSX

[sberlin]

Can you see if the memory problems happen as a leaf?

[stief]

Ok. I'll restart the machine after disabling UP and let you know what happens tomorrow.

[zab]

Originally posted by stief
Still, LW should have been able to serve more uploads with only 3 slots taken, no? There was plenty of bandwidth available.

Well, that depends on how many upload slots you have told Limewire to use. The default is 20 iirc, and if you hadn't changed that but were still observing only 3 uploads at any given time, we may have a problem.

(there is a known issue where if you have more than 5 uploads all going at less than 3kb/sec limewire will not accept any more, but it should not happen with 3 uploads.)

[Lord of the Rings]

I realise this doesn't have anything to do with the time of day, but I have a person (same person) dwnlding from multiple copies I have of a particular file; filling up all of my upld slots. lol Never seen that before!

[stief]

Originally posted by zab
Well, that depends on how many upload slots you have told Limewire to use. The default is 20 iirc, and if you hadn't changed that but were still observing only 3 uploads at any given time, we may have a problem.

I've PM'd the relevant parts of my LimeWire.props file.

Months ago I may have changed the default. Currently the hard max is set to 10 (which is why I thought 7 were free when three were active and 2 queued)

[AustinForest]

I have just installed the international version of limewire ß on a pc running xp SP2 and the version is running in English, I can't change the language in the GUI, the language files are in the relevant .jar. Manually editing the limewire.props file didn't change anything...

This is the first time Limewire make me that.

Thanks

[Lord of the Rings]

Well I don't know if this applies at all but see both: http://www.gnutellaforums.com/showth...662#post101662
& http://www.gnutellaforums.com/showth...threadid=27905