LimeWire 2.4.0 Beta Available
 

The LimeWire 2.4.0 beta has just been made available at:

http://www.limewire.com/index.jsp/download_beta

This version includes dramatic performance enhancements, particularly for users who are sharing a lot of file. It also includes the following features:

<ul>
<li> new "add to wishlist" feature for searches that do not return results
<li> fixed bug where download would stall at 99% complete, automatically switching to faster uploaders when this situation occurs
<li> detects corrupt files when downloading from multiple host (by checking overlapping regions)
<li> connects to the network faster (using socket timeouts and increased parallelism)
<li> increased ultrapeer connectivity
<li> reduced bandwidth from requeries
<li> incomplete files are no longer deleted with certain expiry times
<li> new "about" menu lists contributors, including contributors from the open source project
<li> sends "Remote-IP" header when handshaking
<li> turns of uploads when in "shutdown after transfers" state
<li> vendor column in connection tab
<li> fixed issue on the Mac where using custom fonts could make the options window unusable
</ul>

Again, the performance improvements are really vital, and it will improve network performance significantly overall as more people migrate to 2.4.0.

We hope everyone likes it, and thank you all for your helpful feedback and comments. The performance bug that we fixed in 2.4.0 was identified by users on this forum as well as by one of our open source contributors -- we would not have noticed it without your help.

Re: LimeWire 2.4.0 Beta Available
 

You are doing a wonderful job, but you MUST add checksum detection.

Connection are better, but I get "File Corrupted" on almost every MP3 I try to download (At about 5%).

That doesn't sound good and is very odd. We're working on changes that will add full-file hashing for all shared files on the network, making this operation much more robust and hopefully eliminating corrupt file messages.

The addition of the corrupt file messages is a good thing in some ways, however, because with the previous implementation the files would have been corrupted without you knowing about it.

Is anyone else seeing this? You are getting the message very consistently?

I've get a couple of 'File Corrupt' messages (Been using 2.4 for an hour or so).

It is nice to know how clean the copy is - but for movie files a couple of corrupt bits here and there usually aren't too important. I'd like the notification but would prefer to be asked what to do about it (Since this is just an interim solution before hashing, I won't ask for some guide as to /how/ corrupt the file is).

Alternatively, a nice easy way to resume the download (or even start over) would be useful.

Mark

Question for people who are getting the corrupted file bug: what OS are you using?

Thanks,
Christopher Rohrs

WinMe.

Is it a bug?

Win2000.

Mark

What percentage of downloads would you say are corrupted? How many did you try?

I don't know, I'd say 25%, and that ALL the "corrupted" files, are not really corrupted (I downloaded them with 2.3.0).
Maybe they do have some corrupted bytes, but that doesn't mean I can't listen to those mp3's, or watch those videos.

I'm downloading large files (250-700 MB) so I've not had a chance to complete any downloads yet.

Of the 19 files I've made some headway on, 5 are now corrupt. None has downloaded more than 15%. The corrupt files were stopped at 15, 1, 0, 0 and 0 percent.

[I pointed 2.4 at my 2.3.3 incomplete directory - it found the files to attempt to automatically restart downloads - but so far has always started from 0% - i.e. it hasn't continued any of my 2.3.3 downloads].

Mark

Im also getting the file corrupt message when I download. It happens pretty often, about 1/4 of the time and force resume wont resume it. Im using win98.

Why has the connection bandwidth requirement gone so much higher? With 2.3.2, I could have 10 ultrapeers and use less than 1k/sec. Now having 3 uses at least 2k/sec (this is a guesstimate since ZoneAlarm is repeatedly flickering green, my lo-speed DSL modem's lights are always flickering, and the windows connections manager is always reporting activity, but there is no accurate meter like in gnucleus) Could it be that 0.6 connections are being used and being reported falsely as ultrapeers? I thought the 'peers were supposed to shield leaves from heavy bandwidth requirements sorta like fasttrack.

Second, the search horizon seems lower, as i get fewer results (like 2000 in 2.3 vs. 1000 in 2.4) for a generic search like "blink 182". That might be because of the 3 'peer limit, which won't save when I enter more. 2.3 always connects to 10 ever since i entered it in the limwire.props. This was also tested within the same hour, so little bias should lie there.

Last, the bars still don't save their positions. Only the search windows' bars are choosable, resizable, and saveable. Truthfully, my low rez screen don't have enough room for a 100 pixel bar containing a 10 pixel smiley. And making the smiley/chat bar larger than the progress bar makes no sense to me. PLEASE put this in. :( I beg of you! :p

I haven't been able to try any downloads, so i'll post back later on those, but it seems there may already be enuf reports on those. :rolleyes:

Thank you for the speed improvement in OSX. The startup time is cut in half at least. I downloaded 5 mp3s with no problems with file corruption. But I am having problems staying connected to the network. Within a few minutes of startup all of my connections have failed and I cycle through tons of them in just a few minutes and then I cannot reconnect. I have disabled ultrapeer. Hope this helps.

Connection problems happen often when trying to connect with a 56K modem while downloading / uploading.

Dividend: to my knowledge we haven't changed anything that should affect the amount of bandwidth required for leaf nodes. (You're sure you're a leaf mode, yes?) Perhaps you have an old-fashioned non-ultrapeer connection? (Rare but possible.)

More corruption questions
 

I'm hearing that LW is detecting the corrupt file very early in the download, like at 0, 5, or 15%. Is this true? This is very odd. Normally corruption won't be detected until near the end of the file.

A few questions: what version of Java are you running? Did you install 1.4? Was LimeWire swarming before you saw the error, i.e., did it say "downloading from N hosts", where N>1? How fast is your connections speed in the Tools->Options->Speed window? Finally, do you have a lot of incomplete files that you might be resuming to?

Thanks,
Christopher Rohrs

I did have one file that made it as far as 35ish% before deciding it was corrupt - but most (around 10 now) die showing 0% (but these are large files).

I have both version 1.4 Java and the earlier 1.3something installed. I assume that LimeWire is using the 1.4 version since my mouse wheel is working in LimeWire.

It is difficult to tell after the event whether LimeWire was swarming in all cases. It certainly was swarming on at least a couple of the files - but I /think/ that it wasn't swarming on all the ones that failed.

I've selected Cable/DSL and disabled Ultrapeer. Theoretically, my connection is 576kbps down and 288kbps up.

Yes - most of the files were started in 2.3.3 - nearly all failed files should have been restart attempts - however, no downloads have started at more than 0% - It looks like all files are being restarted from scratch. Given this I have just deleted all of my incomplete files and started again from scratch. Having done this (maybe 20 minutes ago) - I have 1 file failed as corrupt at 0% - I don't know if it attempted to swarm, it failed almost immediately after I started the download.

Mark

Re: More corruption questions
 

Java 1.4, Not Swarming, Downloading from 1 host, Cable\DSL, No files for resume - It happenes with new files.

limewire still creates new folders
see http://cmt.homeip.net/bug.jpg
the right folders are on the right, those on the left contain nothing and are created by limewire at each startup. Needless to say, limewire recognized my shared folder and my mp3s in it. Lime is indeed using the folders on the right.

I dislike those extra directories being created, so I turned it off.

for those with the source code,
In SettingsManager.jaya, find these lines:

try {
SetSaveDirectory(DEFAULT_SAVE_DIRECTORY);
} catch (IOException e) {
e.printStackTrace();
// this should not happen with the default directory
}

I commented them out, and no more extra incomplete and shared directories. No side effects for me, on winXP pro. Dunno what it might do on other OSs, but like I said, all it does in XP is stop those extra directories from appearing.

We released another beta version (LimeWire 2.4.1) that simply disables the corruption check feature. We will likely release a 2.4.2 update quite soon that will notify the user of the corrupt file in some way, but that will allow the download to continue.

Let us know if this one gives anyone problems.

Aha! All of that bandwidth seems to be coming from searches. I can set the "Show last X searches" to 200 and have it filled inside 30 seconds. In 2.3.2, I actually DID see few to no searches - Maybe one search every 3 seconds. I'm preety sure I'm a leaf, as I have disabled ultrapeer capable abilities and my computer should be an unlikely candidate for being a 'peer anyways (see sig). On close examination in the Windows Connection box, it seems to be a steady 1kb/sec downstream. I know its LimeWire because it only happens when its opened and connected, and I have the Cydoor dummy file so it couldn't be that.

Also, the connections settings are screwed. I enter 6 connections and it always gives me 3 on a restart of the prog.

And PLEEZ fix the bars (saving positions and add a right click menu for all, not just search.)

I'll stop whining now and be happy with 2.3.2

Adam, what purpose does the code I commented out serve?

Why would I want the default save directory set to the default if I already specified what to use as the save dir when I first ran the program?

The only thing I can see that code doing is creating two empty directories: install and shared that I don't use, since I specified a shared directory elsewhere.

If you're seeing more incoming searches in your monitor than you did before, that probably means that you're just sharing more files now, so more searches make it through to you. That said, seeing the screen fill up with searches within 30 seconds is a really moderate number of searches to see, and that should take up very little bandwidth.

On the connection settings, I'll have to ask Chris if he did this intentionally -- it might be a bug, or it might be there to more actively limit the number of connections that leaves can have.

On the "bars" I'm really not sure what you mean. Menu bars? Tool bars? Scroll bars??

Back on the bandwidth topic, there's no reason that 2.4.1 would take up more bandwidth than previous versions, as this code has not been modified. I strongly suspect that you're simply sharing more files now. Is this not the case?

On the directory issue, I put that code back in basically because there has been a bug reported that is caused by not having a save directory set, and always setting a default makes this not occur. Also, without that code, the save directory would handled differently from all of the other settings in the sense that it would not have a default. I've been meaning to refactor that class for some time now, and having all of the settings follow the same pattern code-wise simply makes refactoring easier down the road while also improving the maintainability of the code.

That said, I will try to come up with something better when I do get around to refactoring everything, as I agree that it's a bit annoying.

Thanks.

Aww geez. Now 2.3.2 is doin it too, with the 200 searches filled in 30 sec thing. After a little more rootin around I found a new verion of Gnucleus. I'll bet there's at least a hundred thousand Morpheus/Gnucleus users trying out their new versions by firing off tons of useless searches. I found it when I noticed in the "vendor" column a "Morpheus PE". Last i checked Gnucleus didn't support 'peers so that must be it. I also think ZoneAlarm is f***ed badly as it reports that 1kb/sec downstram trickle the same as a full speed download, even tho the numbers in ZA's alert panel don't budge. In other lime vesions, ZA was oblivious to ANY activity, so it don't make for a trustworthy source. I get my numbers from window's connection panel.

I haven't been sharing any more files, the same 217 MP3's i've had all week. And certainly not any files that MATCH have those searches (although they have been getting cleaner lately).

Anyway, I do like the fix of the bouncy transfer rates (16k,0k,16k,0k,etc), a very nice touch.

And these be the bars I'm referring to:
http://www.mts.net/~spider4/bars.jpg
They never stay put on restart and can't be chosen with a right-click (only the search bar does that).
Fixing these shall bring world peace. :)

/Thanx

I'm trying LW 241 pro and I'm seeing what looks like a problem with the last several versions of LW using Java1.4 on WinME. The speed of every upload from my system remains at 0 KB/s and there is no progress. I do see a number of people trying to upload stuff from me so I know their searches are finding files on my system. Note, when I use gnucleus 174 I see upload progress and speed actually indicating that a upload is taking place and it completes successfully. In LW most uploads end in transfer interrupted. Is this a bug in LW?

I am also seeing bandwidth problems in 2.4.0. i used to get 3.5kb/s on the old Lime Wire using my 56k but now it wont even get to 3.00.
Also the meta data searches for MP3's are pretty bad, if i type in an artist and a title it brings back totally irrelevant files which have a couple of the words from my criteria in them. For example if i type the Artist "Ash" and the Title "Goldfinger", it brings back results from bands called "Goldinger" with the track name "Open your eyes", all it did was found my track name i searched for and found an artist with the same name. I hope the meta data searches won't be that hard to fix. The only search which is good for finding specific tracks is the "Any Type" search window.

Anyways keep up with the development.

I hope that Morpheus is not trying to act as an Ultrapeer without our QRP (query routing protocol) in their code. That would be a disaster for our Ultrapeers.

Thanks
-greg

If it's A new Morpheus on Gnucleus 1.7 code there will be no problem but if it's the 1.6 code... Ouch. You'd be screwed.

corrupt files
 

Some people were having problems with too many corrupt files using LW 2.4.0. The weird thing was that the corruption was happening after downloading just a few percent of the file. If you're having this problem and are willing to help debug it, please email me at crohrs at limewire dot com.

dimagor, MooseMuffin, and treatid: I already sent you a personal message with some debugging instructions. If you have some time, any debugging information would be most useful.

Thanks,
Chris

Startup is slow. Can this be improved?

Startup probably can't be faster, because it's a Java Application.
Java application load slowly, but run fast.

You could try the newer Java 1.4 if you dont have it already. I believe you need to ininstall 1.3.1 beforehand, otherwise any Java apps will just continue to use 1.3.1 (because 1.4 doesnt overwrite it).

I encountered quite a decrease in download speed and got fewer hits when upgrading to 2.3.3.
When I upgraded to 2.4.0, then 2.4.1, and also upgraded the Java engine to 1.4, things improved and it seems to me that my downloads is faster now. ;)
Still, Limewire is trying to connect to 5-6 extra hosts now and then.
The connection attempts disappear after a couple of seconds, but the established connections seems to be quite unstable, and they are renewing themselves after a while.
Other than that, I'm quite happy with the improvements in the GUI using the 1.4 Java engine. (<Enter> now works on OK/Cancel dialogs - yeeah!)
The number of hits on my searches has also somewhat decreased after upgrading to 2.4.x, but that may also be a bug in the Ultrapeer code - several of my connected Ultrapeers is 2.4.x.

Note: The newest version of LimeWire is currently 2.4.2, the "beta" is now old. Grab the newest version from the front page @ www.limewire.com ...

Java/LimeWire using all processor
 

Windows 2000, Java 1.4 on an AthlonXP 1500.

From time to time, LimeWire/Java take up all my processor time (So much so that it nearly looks like the computer has locked up).

If I have sufficient patience, processor usage drops back to a more reasonable level (usually between 10 and 20% use) after a half hour or so.

I think that I have managed to close LimeWire during one of these peak usages - The Java VM continued to take up all my processing power (It is possible I just minimised LimeWire).

This has happened on a few (perhaps as many as half a dozen) occasions now. I'm reasonably sure it isn't new to 2.4 of LimeWire.

This could well be something like a garbage collection issue within Java and not LimeWire's problem.

I think most of these near lockups have started when I've done a re-search - but I've done a lot of 're-search'es that have not caused any kind of lockup.

Mark.

For Mark
 

Are you a leaf or ultrapeer? How many connections? Do you get this when disconnected from the network?

I'm a leaf. 6 connections.

While LimeWire/Java is taking all the processing time, LimeWire is unable to keep any connections for more than a brief period of time. Last time this happened (started a couple of hours ago) LimeWire claimed it was disconnected. Some uploads got a brief look in - downloads were not happening.

Switching off the ADSL connection did not seem to improve (or worsen) matters.

I got bored after a couple of hours of slowdown and killed Java from taskmanager. Restarting LimeWire went fine, picked up all the incompletes and is currently working without a problem.

Mark

This last episode started when I stopped LimeWire and restarted it because all the uploads had dropped to 0K - As LimeWire was going through restarting the (fairly larger number) of incomplete downloads it started taking all the processing time (I've set maximum number of downloads to 30).

How many incomplete downloads? How many files are you sharing?

Currently around 370 files in my incomplete directory and sharing 99 files.

Mark

you mean you have 370 files in your download queue????

Not now because I've just had a crash and my queue is now empty.

And probably not quite that many previously - but yes, I have a fairly large download queue.

I tend to (try to) download larger files. If a file doesn't download in one session (and 600MB rarely does) then it can be a long wait before the host is available again. The vast majority of the time only a handful of files are available at a time - the rest either have no hosts available or the hosts are heavily accessed and trying to get a download slot is nigh on impossible.

I also find that I have a lot of the same file in the queue (or in my incomplete directory) but with slightly different names (It would be nice if people didn't rename files). When I've finally get a file down, I delete the other aliases, but in the mean time, I try to get them all (Yes, this is a waste of bandwidth - Yes, I'm looking forward to a hashing implementation that will fix this).

Mark

It would be nice if the LW developers had a link to a change log from the LW pro download page so I could see whether the version of the week has fixed the things that I find bothersome.

LIMEWIRE PRO UPGRADE SUCKS SO FAR! I keep getting error messages. I should now have upgraded!

Is there any such thing as a ChangeLog or anything that I can use to get some information what has changed between the releases?

I dont even _dare_ to ask for something like a plan for which features you (the LimeWire Team and the open source developer) spend the time....

It's a bit sad we dont know anything here...

cu Martin

I've upgraded to beta 2.4.3 pro, and so far I'm having lockup problems when starting LimeWire.
The Java engine is draining 99% out of my cpu for a long time, but it resumes to normal activity after 15-20 minutes.

Also, the connection list seems to refresh itself all the time, and when it's searching for new connections it often grabs all of the cpu.

Eventually, if I shutdown LimeWire, it clears all my download entries, so the next time I start the program it's with a blank download list.

Sorry, there was a bug in both my attention and the forum autologin. The above message was posted by me, but I failed to notice that I was not logged in when posting the message.:eek: