LimeWire 4.1.8 Beta
 

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

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

Is the geman translation complete?

Re: LimeWire 4.1.8 Beta
 

That's a good step.

Ivan
In the dark we make a brighter light

Uploading problem
 

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.

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?

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.

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.

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.

Quote:

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

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

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