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.

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.)

Multiple copies of a file uploaded
 

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)

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

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

What language do you want to change it to? We discovered a problem with changing it to some languages, where the chosen language didn't stick on the next startup. This will be fixed for the next beta.

Yes they do.

After Uptime: 21:06:20 the vm rose from 432mb to 932mb. That's with no searches and no downloads--just serving uploads as a leaf.

Thanks very much, stief. Can I bug again and ask if it happens without uploads and as a leaf?

Hmm--as in just being connected with no shared files? No downloads or searches?

Yup. Trying to see what area of the code is causing problems. Since we're not able to reproduce it as easily, the smaller we can pinpoint the problem, the better. If you could also disable incoming connections (firewall your computer), that'd help also. So, if the memory problems can occur on a leaf that's just sitting around doing nothing, it's relatively small portion of code to sift through (as opposed to the whole mass of code). (And make sure you're using 4.1.8 please. Thanks very much.)

Ok--this will be interesting: trying to get LW to NOT do anything from behind a firewall! I'll let it run overnight and let you know in the morning. I think I'll set it up in a new user account so everything will be from scratch (in case the prefs have other old settings). Cheers

As you can see, I can only see half the characters under progress and in the mediaplayer. I didn't have this problem with the freeware 4.0.8 version.

You know you can drag each section of a window around for resizing purposes don't you. There's small arrows that separate each section that can be dragged. Also the bottom RH corner can be dragged to resize the entire interface - try making it larger.

Does this happen with all Skins or only this one?

Yes I know. It already was in full screen mode, but I just cut out this section, because this is the only area where the problem exists. All the other characters are just fine. Dragging and resizing didn't help, and it also happens with all the other skins.

I'll leave this one up to the others I think! What OS version & Java version are you using? Is this the 1st time it's happened? Have you restarted the comp since it started happening?

OS: XP Prof SP2
Java: 1.4.2_05

I noticed directly when I started using it yesterday. Restarting both LimeWire and the computer didn't help.

This is a big shot in the dark & probably won't do anything, but try changing monitor resolution & see if it has any effect. Then switch it back.

Did you use the international installer, scamp? If so, it isn't gonna be 1.4.2 (it'll be 1.3) -- the cutoff looks indicative of Java 1.3. Go to Tools -> Options, Bug Reports and click 'Example Report' and double-check the Java version?

Yes, it does.

The VM grew at about 5-6MB/hr, even with a fresh default install into a new admin user account, with no searches, downloads, or uploads
(Interestingly, it quickly went to turbocharged, even with the firewall fully on and the ports not forwarded).

No VM growth, with all View options turned off, while disconnected
No VM growth, with all View options turned off, while connected

VM grew by turning on View->Connections (while connected).
(also noted that the 30 minute sleep function works)

No VM growth, with zab's garbage collector CVS version (thanks zab--hope this gets into the next beta).

So, looks like the VM growth is tied to displaying Connections View when connected, and that better gc will fix the problem.

cheers

Wow. Thanks stief -- that's some excellent debugging work. Hopefully we can now find what's causing it and fix the bugger!

Yes I did and you are right about the Java version. It also explains why the mousescroll wheel didn't work. I removed the internatioal version and am now using the english version instead. All problems are solved now. :)
Thanks for your help.

RAM use on iMac
 

Here's a user where the ram issue seems to be playing havoc with LW (unless it's something else) on an iMac with 512 MB RAM: http://www.gnutellaforums.com/showth...&postid=105520 Any ideas?
Quote: I do have a few other apps open when using lime wire, usually just i Tunes and Safari and maybe Messenger but thats about it. It did get better last night when i closed a few things down. Is Java getting a bit over-worked here?

another gui problem
 

well first off sorry for not having a screenshot ready- i did but i set my workarea smaller than the img on the clipboard..... it happens often enough that i'll have one soon tho-
what happens is this... after ive been away from the pc awhile, and i come back n bring lw outta the tray, the horozontal bar at the bottom of the screen doesnt appear. instead the list extends to the bottom window border. if i close (to tray) and re-open it comes back w/in 3 tries.

btw: anyone know where i can host an image free so i can post a link? i used to have a bookmark, but its been lost. ty

duh...
 

i guess some details would help....
lw418pro java5 ultrapeering upload cap at 21kB, xp home, 512ram, 1.4 celly and 45 or so processes any given moment eating 5-600M, most of which running in idle priority, cpu's always hella busy- usually hangs out around 60% busy when im not, ram's usually got about 100m free

Yeah, that's a known problem EllisD. Auto-fixing it has proved elusive so far.. we'll see if there's a way.

I thought most pc's could take snap-shots! I don't remember what the keyboard command is though for windows. Oh how about the Printscreen button &/Printscreen & alt is it, I'm not sure for selective size. And then paste the snapshot into another app. For mac there's a keyboard command & I also have a freeware app that saves the pic in any format I wish. I'll generally resize the image smaller before I use it in the forum.

yup thats how it works...... is there a way to make the board accept a file directly? all i see is the img button that asks for a remote location

yo just as i pressed the "submit reply" button i saw the file chooser.... really ive never noticed it there before- only the img button..... needless to say i feel sooooooo stupid!!!

download connections breaking on chunks?
 

Hi all--some more info re interrupted transfers

while testing magnets (downloading the latest jum360 from jum's very busy client :) I noticed it would transfer 100KB then show the "Waiting for Busy" message in the downloads panel. We are both using the latest CVS version (jum360). A few minutes later or by using the Resume button the dl continues. So far only 45% of the file has downloaded in 3 hrs.

I wondered if this is intentional--will a busy host rotate uploads after serving up one chunk, or is this a problem?

btw--the GC fix seems to be working: I'm running as the usual UP with lots of uploads and as many GUI parts open as I can, and the VM has only gone up very slowly.

Limewire relies on the host OS management of TCP. At least on linux that is totally unfair and if bandwidth throttling is enabled, one fast downloader will monopolize the entire available bandwidth - we've observed situations where one upload is going at the maximum allowed bandwidth and 19 other uploaders at 0KB/sec. The same is likely true for windows and mac osx since everybody uses the NetBSD tcp stack anyways.

Whether this is a real problem in the network is debatable because everything works fine when bandwidth throttling is not enabled or is enabled but the limit of simultaneous uploads is small (<5). Vast majority of the users out there will not have that enabled, and the few that do will most likely also limit the number of simultaneous uploads.

I have a suggestion. I often download big files that end in "need more sources" state. However, I often continue uploading those partial files. Is LW asking chunks of those files to these possible sources and also verify if there are known alternate sources with them? That would save me doing searches to find more sources....

Ciao

salut all

the VM problem is back for OS X here: Looks like the View->Library is the factor.

ran Jum's latest CVS version (jum360) for 16 hrs yesterday as I normally would (UP, uploading ~45KB/s on average and with all the GUI turned on), hoping the VM would be stable at ~750MB. However, after about 8hrs HD space started dropping, and the VM was up to 1.1GB.

Turned off all options possible in the View Menu, and over three hours the VM remained stable at 1.12 GB.

Turned on ONLY the View->Library pane, and the VM rose to 1.71 GB in 2 1/2 hrs.

Turned Library pane off again, and the VM remained constant for the next 1 1/2 hrs at 1.71 GB

left it to run overnight, but logs show Java crashed about an hour later, followed by a limewire crash 39 seconds later. (Here's the basic info

Quote:

avaNativeCrash_pid388.log An unexpected exception has been detected in native code outside the VM. Unexpected Signal : Bus Error occurred at PC=0x90195238 Function=[Unknown.] Library=/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation LimeWire.crash.log Exception: EXC_BREAKPOINT (0x0006)

Sorry Sam: after your kind words previously I really hoped the VM problem was fixed here.

If you are in a rush to get 4.2 out, would it help if the OS X View options could be turned off when there is no user interaction for, say 15 minutes, and turned on again when LW detects user interaction?

I am having only the search page up and on my OS x box after three days the virtual size of LimeWire is at 2.2 GB. I will probably need to stop it shortly so I can reclaim all the swap space.

weird. 44 hours uptime from the CVS version of friday. 3 gigs uploaded, been running as a leaf 40 hours, as UP 4 hours. 598 megs VM. Since Java 1.4.2 update 2 I never got VM problems. Could it be JUM specific? The only changes I made are the clients banned for uploads...

Ciao

Hi jum--good to hear from you again.
So you're seeing it too! Whew :) Ca you tell me if the jum 360 includes the garbage collector submission? http://limewire.org/fisheye/changelo...20041101172124

Roger is helping me learn to use the CHUD tool BigTop to try to see what's going on. Any tips?

Well, anything can be possible. Due to the more activity via the timers it could be the trigger. I will check this by running it without any timers and also moving away my LimeWire.bsh file I should have the same thread configuration as in the standard CVS build.

Randow chunks seeding is a great optimisation... but it kills hard drives! You should hear HD activity once you are dling and uploading a couple of large files in overnet :) I prefer the LW way for now. Might be slower, but it doesn't affect the computer so people can run LW longer without noticing or complaining.

Yes, the garbage collector thing is in. If you look at the date of a jum build and may be count a hour or two back you have the state of the CVS I did use for a build. I only additionally have a few patches in that are known already (I submitted these to the developers list in the past).

I have no experience with CHUD yet, although I will definitely be looking into it in the near future. But for tomorrow I am pretty busy perparing ARWEN for winter, tomorrow is crane day.

How to do this? Are these entries in Filters>Hosts?

My 4.1.8 jum (1st I think) after 12 hrs after updating to OSX3.6 with search & lib windows only is 656 MB RAM & just over 1 GB VM.

You have to modify the source to ban some clients, then compile LW. Not a task for the average user. I think that with Trap_Jaw builds, you can filter some clients without recompiling LW. You can ask him. I'm now at 84 MB ram and 629 MB VM. There is a steady increase of 5 MB/hour of VM as Stief reported before on my machine. BTW Stief is testing my CVS build against the JUM one to see if there is any differences on his machine.

Ciao