LimeWire 2.7 beta now available
 

A beta version of LimeWire 2.7 is now available for download at http://www.limewire.com/index.jsp/download_beta. PRO users can download it from their download page.

In addition to fixing several bugs, LimeWire 2.7 introduces several new features:

• Remote queueing: if an uploader is too busy to handle a download request, it will queue you. The uploader then serves downloads in a first-come, first-serve basis. This feature is compatible with the queueing schemes used by other vendors.
  
• Resume from library: you can resume incomplete files in the library with a single button press.
  
• Safer resumes: LimeWire keeps track of the hashes for all incomplete files. This reduces the chance of a corruption when resuming.

As always, we welcome any feedback and bug reports you may have.

Sincerely,
Team LimeWire

LimeWire 2.7.0
Java 1.4.1
Windows 2000 (full admin rights)

I really, really like the resume download from library feature. Absolutely fantastic. Thank you for that one.

I upgraded from 2.6.1 - LimeWire didn't remember my settings again. I have now uninstalled LimeWire completely and re-installed 2.7.0. As soon as it has finished hashing I will re-install 2.7.0 over itself and see if it remembers settings this time.

Mark

Well... I tried to re-install. But the installer recognised that it was the same version and gave me the repair, modify or remove options.

Modify fails looking for a file in the temporary directory (I think with a .msi extension).

Repair seemed to work and didn't ask for new settings.

I'll let you know what the next (minor) version does when it is out.

Mark

Under the monitor tab - 'Transfer Interrupted' uploads are not automatically cleared anymore (with Auto-Clear completed uploads ticked). Completed uploads and upload requests are being cleared as before.

Mark

Waiting message
 

Received Waitin in line 10 message in Status area in download window? What's this?

LW 2.70 Pro Beta

Great to hear of another update.... I've just installed.... and I'm off to check it out! :)

I just went to my download page and it offers me 2.6.5 pro not 2.7

Norm

Kath,

I am asleep too. The beta is at the very bottom.

Norm

A small hitch - Limewire offers to install in C:\Limewire. I redirected the install to my E drive. All went fine but Limewire had written a Limewire and a Limewire shared directory on my C drive. Not a big issue, I removed them, but a glitch non the less.

2.7 hashed at the rate of about 100 files a minute and is, so far, operating without a problem. Searches are returning good results and both uploads and downloads are fast and reliable.

Norm

>Received Waitin in line 10 message in Status area in download window? What's this?

means you're 'remotely queued'. it's very different than a requery, because you've obtained a download slot. every minute or so limewire will check what your new position is and when it's your turn, the host will let you download.

Thank you for the explaination...

LW 2.70 Beta Pro

On the settings issue, I found a problem with the installer that was causing previous settings to not be saved correctly. I attempted to find a solution that would allow settings from previous versions to be preserved seamlessly, but the solutions were quite complicated and would likely lead to bugs in the future. I decided instead to change the way settings are preserved so that they will be cleanly migrated in future versions. So, as some of you have experienced, you will likely lose your settings on this upgrade, but all future upgrades will preserve your settings correctly.

My apologies for the inconvenience. The problem arose from compatibility issues in InstallShield between the old InstallScript way of doing things and the newer Windows Installer Service. We're now using Windows Installer Service for everything, as InstallScript was overwriting registry settings for previous installations.

Thanks.

Pleased with 2.7
 

Same results here.... Thanks LW developers! :)

An oddity...

I left LimeWire running over night and came back to find that while it was claiming to be downloading it wasn't...

There were four or five files supposedly downloading (one of them at 24KB/s). The download rate was not changing for any of the files although the time to completion was decreasing. My network connection was still up but the traffic was very low. Uploads were also dead.

I was able to do searches (my connections were still active) but couldn't kick start the existing downloads. Closing and re-starting LimeWire fixed the problem.

A quick look at Task Manager showed that a chunk of processor (around 30% of an AthlonXP 1500) was in permanent use by LimeWire. I suspect a task/thread leak somewhere (but not a serious memory leak).

I do currently have an excessively large download queue (thanks to the ability to resume incompletes) which probably exacerbates the problem (but shouldn't be the cause of the problem).

Mark

for Treatid
 

Mark,

Are you sure your downloads were really not progressing? If LimeWire reports decreasing time until completion, it sounds like everything is working right.

The 30% CPU usage is disconcerting, however. Did it persist if you shut down all messaging connections? How about if you closed all downloads and uploads as well?

-Chris

Yes - I'm certain the downloads weren't progressing. I use an independent network traffic monitor (there was traffic relating to the active connections - but not to the upload and download queues).

I agree that it is odd - LimeWire responded in all other ways - but the reported speed of the downloads was stuck rock solid (no variation at all). The time countdown looked to be about 1 second a second - so it was consistent - but there was no data transfer.

Sorry - I didn't kill the uploads and downloads. I did kill off all my connections - no difference.

Since then I've been struggling with LimeWire using way too much processor time.

When I initially installed LimeWire 2.7.0 I lost my download queue (a little over 1000 entries - outrageous I know - but it worked).

I used the resume incomplete downloads feature to resume all the incomplete files in my download queue (turned out at nearly 1800 files).

Since my last report LimeWire has been using more and more processor time. I have been deleting files (both from within LimeWire and directly from the incomplete folder) and shutting down and restarting LimeWire. Each restart used more processor time. On the last occassion it stuck at 100% processor utilisation (for an hour or so before I gave up).

I noticed that the downloads.dat file grew to a little over 9MB and was being re-written very frequently (subsequent refreshes while looking at the file would show its size rapidly rising from nothing to 9MB then back to nothing and grow again). Before the upgrade, the largest my downloads.dat file got to was 855K.

I have now deleted my download queue (and the downloads.dat file). And LimeWire seems to be behaving normally.

I shall play further and let you know how it goes.

There is a good chance that my problems were related to a corrupt downloads.dat file (even though it was being re-written?). I'll let you know how things go now that I'm starting the download queue from scratch...

Mark

We've just updated the beta to 2.7.1 with some minor fixes based on feedback. In particular, we fixed an issue where the Mac 9.x and below version would fail to load entirely. We also fixed an issue with downloads, fixed an error with the files in the library, and made several other minor changes.

We have not addressed the problems seen by Mark, as we have not fully diagnosed the issue at this time.

Thanks for everyone's help!

Thanks for the update Adam! :)

Anxiously awaiting G.U.E.S.S. !! ;) :D

Queued uploads and "Uploads Per Person" not honored?
 

I have set my "Uploads Per Person" to one to only allow one file to be downloaded per remote computer. This all works fine and well for normal uploads. But on the new queued uploads as soon as these are converted to real uploads it does not honor this setting, it does go up the maximum number of upload slots. Is this an oversight?

for treatid
 

Mark,

I'm a little confused by the situation you're describing. So let me see if I understand what happened:

You installed LW 2.7. You had a large number of temporary files in the incomplete directory. Initially there were no downloads in the download window. (Any active downloads from 2.6 were lost.) You select a thousand incomplete files from the library and click "resume". LimeWire kicks of 1000 downloads. Most of them are queued by LimeWire, but some enter the requery state. LimeWire runs slowly. The downloads.dat file grows very large then shrinks. Deleting downloads or incomplete files and restarting LimeWire does not help.

What's the size of your download queue? (Tools->Options->Maximum Downloads) Note that by "download queue" I'm referring to the downloads that say "Queued" because of LimeWire--not those that are remotely queued ("Waiting in Line").

Thanks,
Chris

Re: for treatid
 

Yes - I thought I was getting a bit garbled.

> You installed LW 2.7.

Yes.

> You had a large number of temporary files in the incomplete directory.

Yes.

> Initially there were no downloads in the download window. (Any active downloads from 2.6 were lost.)

Yes.


> You select a thousand incomplete files from the library and click "resume".

Yes - close to 2000 as it turns out.

> LimeWire kicks of 1000 downloads. Most of them are queued by LimeWire, but some enter the requery state.

The vast majority went quickly to the requery state. (aside - I've noticed that when I start LimeWire 2.7 that the files very quickly go to the requery state - previously they would stay at queued until a free download slot tried to connect the file).

A half dozen had started downloading by the time I came back (telling 1000 files to resume takes a few minutes to process :^) ), a few were waiting on busy - the majority were on requery.


> LimeWire runs slowly.

Initially it performed pretty well considering the load I was putting on it. But over the next 48 hours it was using more and more processor time despite me removing 500 or so files from the download queue.

> The downloads.dat file grows very large then shrinks.

Yes.

> Deleting downloads or incomplete files and restarting LimeWire does not help.

Perhaps it slowed down the rate at which things got worse. Or it may have been my fiddling that was making matters worse. Sorry I can't be more helpful here.

> What's the size of your download queue?

The maximum was 30 (I never achieve that many downloads - it has only ever made a difference to the rate at which queued files are converted to requery).

In an attempt to reduce CPU usage I dropped it down to 10 (and 5 briefly). It didn't appear to make any difference.

...

Since I deleted the download queue and started from scratch things have been running fine.

I currently have around 400 files in my download queue. The downloads.dat file is currently at 1,813 KB although it is growing at an appreciable rate (now 1,822 KB). And shrinking before coming back up to the current maximum size (looks as if the file is being re-written (hence the small sizes as I catch it part way through the re-write) and growing overall.) (now 1863 KB).

(now 1,894 KB).

Mark

(now 1,919 KB).

In the Queue???
 

I haven't yet DL'd this new version because I'm a bit curious about the 'QUEUE' feature.

Where do we stand with users running the previous version without this feature? If they are NOT to be queued when making a request, as we with the new version are, then how does the newer version prioritize the queue for a request. Seems to me that the new version could keep me waiting in line longer than average if there are users that can override a queue. If I'm not misstaken, that's why this feature has been added in the first place so that users don't bombard the network with multiple requests.

During my usage of LimeWire 2.6, for example, if get a 'requery' result all I do is search for the exact same content again and, low and behold, as soon as my search finds that file, the requeried file starts downloading. In so doing this, aren't I skipping in line through other requests and pushing my request through?

If this is not the case, then can someone please explain the default parameters during this scenario? In other words, how are these 2.6 requests prioritized within our new queue function?

CkyFan

Chris:
 

LimeWire is exhibiting same/similar problems as before.

I've left it running so I can try out any fiddling you might suggest.

Situation:

I have around 400 files in my download queue. One file is actually downloading - it claims from 4 hosts.

The speed is shown as a rock solid 13.4KB/s and the countdown timer is decrementing at about a second per refresh.

Looking at the file in the incomplete folder - it is growing - so the download is happening.

My uploads are also showing a constant number of KB/s (but the variation there is usually less anyway). The countdown timers (on the four files currently being uploaded) are decrementing at between 1 second/refresh and 3 seconds/refresh - extremely consistent - no jumping of a few minutes as I would normally expect - the variation in countdown times is /across/ the uploads - each individual upload has a very consistent rate of decrement).

I am able to start new downloads (search for a file - put it in my download queue and a couple have started downloading). They are definitely downloading - I can look in the incomplete folder and they are growing at an appreciable rate - BUT they are shown as downloading at 0KB/s - no time to completion shown.

I think processor usage is more than normal - but it isn't extremely obvious - I have a suspicion that it will get more pronounced over time.

I have tried setting my number of connections to zero and removing all the active connections - this made no difference to the behaviour reported above.

I haven't tried removing either uploads or downloads from the relevant queue yet.

My downloads.dat file is currently 3,280 KB. (9 files added to the download queue since my last report - as detailed above, two of these are the new downloads I started).

Mark

Addendum:
 

I have now tried Killing uploads from the uploads queue.

I killed off the uploads in progress first - this resulted in them being removed from the upload queue as expected - but nothing jumped in to take their place despite having around ten "queued" upload requests (There is usually a lot of demand for upload slots - I would expect a free upload slot to be filled instantly).

I then went on to Kill the "queued" uploads. They were removed from my upload queue. - They were eventually (after a minute or so) replaced with other queued items.

I now have 10 queued uploads and one "uploading". However, the one uploading is showing as 0KB/s although the progress bar is now at 1%.

Searching is using up /way/ more processor time than it should (at a rough estimate - an order of magnitude more - err... 10 times more than normal). Oops - not quite true...

A search that returns a total of 152 results uses a normal amount of processor time (a maximum of 50% processor usage (mostly a lot less) for around a minute (normal search time)).

A search that returns a total of 1466 results used up 100% processor for for around 6 minutes.

But (sorry) 1387 results - does go to 100% processor but only for around 20 seconds (A little high - but within spitting distance of normal).

It seems that occassionaly (I can't find a bit of consistency yet) a search takes a lot (a lot) more processor than normal.

Downloads.dat is the same size as reported at the end of my last message.

The progress bars on the upload and download queues seem to be correct - it is just the speed which is stuck.

Mark

Queueing
 

ckyFan:

2.6 users can never jump the queue. If the uploader is busy, 2.6 user will simply be rejected as usual.

-Chris

for Treatid
 

Mark,

LimeWire isn't really designed to handle so many downloads. I expect (hope!) most users don't have more than 10 or so active at a time. Does LimeWire still have problems if you only have a few downloads and no active searches?

Do you get performance problems if you have just one download and then do a very popular search with lots of results? If so, I think I can fix that for LW 2.7.2.

-Chris

I would welcome any performance improvements - but that isn't the problem (I accept that a popular search may take processor usage to 100% - the problems I'm describing are new in the 2.7.0 and 2.7.1 versions of LimeWire).

There are two serious problems that may or may not be related.

1. If I leave LimeWire running continuously (which I normally do) the speed indicators on the download queue, on the upload queue and i/o on the connections all freeze (between 24 and 48 hours).

2. LimeWire uses more and more processor time - this only becomes obvious after 48 hours or so. This is not fixed by closing down LimeWire and restarting it (it actually gets worse). It is fixed by deleting the download queue (and downloads.dat) completely.

There is something seriously broken that was not broken prior to 2.7.0. I may have forced the problem by stressing LimeWire more than average users... I am not mis-interpreting normal LimeWire behaviour (I know LimeWire can be a resource hog - these problems are over and above that).

LimeWire is currently using 80% to 90% of my processor - I have no connections (set to zero), no uploads (set to zero), no searches (set to 1) and I'm downloading 6 files(maximum of 10). I have an AthlonXP 1500. This is *far* too much processor usage both in absolute terms and in comparison with 2.6.3.

Mark

for Treatid
 

Mark,

Thanks for the clarification. Your reports are disturbing. Does error #1 happen without any downloads? (I.e., do uploads and connections freeze on their own.)

I would be very grateful if you could tr running LimeWire with profiling turned on. To do this, change your LimeWire shortcut to

java -Xrunhprof:cpu=samples,depth=20,thread=y -jar LimeWire.jar

Use this shortcut to start LimeWire. After you shutdown LimeWire, it will write profiling information to the java.hprof.txt file in your current directory. Please email this to me at crohrs at limewire.com, along with a brief description of what you did during that session (e.g., start 3 downloads). You can run LimeWire in different situations and send multiple files if you want. This might help us separate the two issues (if they're different).

Thanks a ton!

-Chris

2.7.1 feedback
 

Note: when scrolling down through a file list using the down arrow on the keyboard the program responds differently in the search and library tabs.
In the library tab, when the cursor get to the bottom visible line of the file list, the list starts to scroll up so the highlited file is always visible.

In the search tab, the highlited cursor scrolls out of sight. If I click on the scrollbar I can bring the highlited file back into view.

Preferrably, I'd rather have them both work like the Library tab.

After reading the messages from Mark, I know this takes low priority, but should be much easier to address <grin>


Associated request for enhancement:
How much trouble would it be to be able to use the scroll wheel on my mouse to move through the files?

suIre
2.7.1
Intel 1800, 256
Sharing 1200+

Hmmm.....
 

Scroll wheel works fine for me....

I think you need version 1.4 of Java (JRE) or later for mouse wheel support. The default installation installs version 1.3ish.

Mark

I have installed 2.7.1 nad it worked like a charm. But for the last two days it is slow as a dog, after a mouse click it takes 10-40 seconds to do anything. It is so slow, I do not want to use it.

0) I am sharing always the same number of files: 42.

1) tried waiting for 3 days - the problem remains (restart does not help)

2) tried reinstalling 2.6.5, does not work. The installer does not give any errors, but does not install either. 2.7.1 remains.

3) deleted the Limewire folder and reinstalled 2.6.5. Worked. However, 265 is now as slow as 271. How come ?

4) Since 2.5.x the installer was giveing me error messages which I always ignored; there were no consequences (so it seemed to me as a user):
java.lang.NullPointerException
at java.net.Socket.<init>(Compiled Code)
at java.net.Socket.<init>(Compiled Code)
java.lang.NullPointerException
at java.net.Socket.<init>(Compiled Code)
at java.net.Socket.<init>(Compiled Code)
at com.limegroup.gnutella.util.SocketOpener$SocketOpe nerThread.run(Compiled Code)
at com.limegroup.gnutella.util.SocketOpener$SocketOpe nerThread.run(Compiled Code)
java.lang.NoClassDefFoundError


anybody can help ?
thanks, Thomas

Thomas:

I would recommend you go to add/remove in control panel, uninstall Java, start Limewire. It will prompt you that Java must be installed and offer a link to install it. Follow the link and install Java. Reboot and try Limewire.

Good Luck,

Norm

for Thomas
 

Thomas,

Thanks for the feedback. Do you know if you are running as an ultrapeer? You can check by looking at your connections tab.

The NullPointerException is troubling. You're sure this happens when running the installer? What OS are you running?

-Chris

2.7.2 beta
 

LimeWire 2.7.2 beta is now available. This fixes a number of bugs. I think this will fix Treatid's performance problems.

Unfortunately, there are already two known issues with this version. First, "mpg" files are not shared by default, unless your old settings are used. Secondly, the international version of LimeWire may start in English on the Macintosh. The first issue was a simple oversight and has been fixed internally. We're still investigating the second.

Again, please let us know of any problems. Thanks!

apologies to all,

I caused the performance problem myself. I have this habbit of disabling extensions I accumulate ever 1-2 months. I remembered that I did remove a strange file called "ProxyApp" from the root of the system folder. I put it back from the backup and now everything works as always.

I reinstalled 2.7.1 and the installer log says the usual "
Custom Action: com.limegroup.install.SettingsTranslator
Status: ERROR
Additional Notes: ERROR - class com.limegroup.install.SettingsTranslator.install() Unexpected Fatal Error:"

thumbs up to those who suggested reinstalling MRJ.
Thomas

Well, Limewire 2.7.2 is an improvement over 2.6 for processor usage on mac osx 10.2, but I have a question for lime developers: when hidden, limewire uses 5% of cpu, and when it is not it consumes over 20% of cpu, why is it so? By the way, the window asking to register at startup is nearly to small to click on buttons with the French language. Also without resizing, I can't see how many files are shared in the bottom left corner, because the link asking to support open software takes too much place, in its French incarnation of course.

Happy hard coding!

Mouse Scroll
 

Mark, thanks for trying to assist. I am using :
Java(TM) Plug-in: Version 1.4.1_01
Using JRE version 1.4.1_01 Java HotSpot(TM) Client VM

Logitech Wireless Keyboard and Mouse under Win ME. Neither scroll wheel on mouse or keyboard are working.

Thats the trouble with message boards... When I thought it didn't work for anyone, I was OK with it, now that I know it works on some and not mine.... its driving me friggin crazy! <<Sigh>>

And yes, the wheels work fine on other pages with a scrollbar. Any other ideas on places to look?

:confused:

General Usage Report
 

Well it's been almost a week now and I just want to let you know how the latest version is working for me.

I'm not very bright when it comes to a lot of the 'tech talk' so I shall break it down in laymen's terms, and before starting, I will give you all of my specs.

I am running on a G4 1ghz DP, plenty of RAM (1.5ghz), on OSX.2 (Jaguar). I have yet to buy another drive, but for now I have 5.66 gig available on my 80 gig hard drive. I am prone to multitask while running LW becuase with that much RAM I can afford it. I do not use any other peer to peer or fileshring services other than LW mostly because I'm very happy with its performance in the past and I've grown quite fond of the other users' input and feedback on the forums that I see no other reason to switch to something else.

That being said...here's what I've experienced so far, using 2.7.2...


- Install -
Yes, it's true that the install did not remember any of my preferences and I had to reset them (no big deal), but other than that, a painless process.

- Startup -
Startup seems to be fine. I always immediatly open the 'statistics' window on startup to see how many hosts are connected and files available, and I see no dramatic difference in performance during startup. I will say however that I have quit and restarted it multiple times just to see how many downloads might resume on startup and I seem to remember that with 2.6.5, if I had 200 or so requests queued that an average of 3-5 of them would resume on startup and this is not the case with the new version. 1 or 2 if I'm lucky but never over that. I'm assuming that this has something to so with my place in line.

- Performance -
One thing that happened to me using this version (2.7.2) is that if I had uploads and opened up my preferences to give those users more bandwidth, as soon as I clicked on 'ok' I crashed and had to restart. Now this only seems to occur if I change that bandwidth drastically (more than 50%). This happened three times.

My downloads.dat file holds at a steady 48k with three downloads currently in progress.

This new 'waiting in line' feature seems to be an extremely rare occurance. I have only seen 'waiting in line' twice using 2.7.1 and 2 combined. Strangely enough one of those was the very first request I made when I installed 2.7.1 and only one other time, yesterday running the updated version (2.7.2).

Downloads are slower most of the time but, yes it's true, there are those times when I will get files coming in to me at 60kb/sec and that that puts a smile on my face, but nonetheless, I do see a general drop in download speeds.

In addition to download speed, I've noticed a big drop in downloads in general. Much less than usual. I don't think I could even give you any clues as to why this may be so, but I thought you might want to know, since I do basically run LW 24/7, and have been for the past 6 months or so. I have heard that it could be a port connection, that if one changes his/her port to another, that it might help, or by turning off and disabling 'ultrapeer' it might do something too, but until someone tells me firsthand what might be best for me and my system, I'm going to assume this is all myth. I have considered the possibility that most users now consider me a leech because I've already got what I can get from them and I've been cutoff until I can put somethinng in my shared folder that they might want. And there is the issue that my hard drive is almost full with only 5 gig left; could that be something? Whatever the case may be, it seems entirely too coincidental considering the fact that my download speed and frequency has dropped dramaticaly since the instillation of the new beta.

Another issue that came up during performance was that my hosts keep dropping like flies, especially if I had LW running in the background. In fact, I can say that there were four occaisions where I would hide LW, play 'Return To Wolfenstien' for an hour or so, and the when I returned to check LW there were 0 total hosts with maybe 1 download in progress. So then I'm thinking, 'Okay give it a few minutes, perform a search or two and see what happens.' Sorry Charlie, you still have 0 total hosts with 1 current host running. So what do I do? Restart. 2.6.5 seemed to work much better in the background than this later version.

All in all the performance seems a bit slower. Furthermore I uninstalled 2.7.1 when I had it, because that was buggy and reinstalled 2.6.5 and it was like I was still running 2.7.1. I read somewhere that if you uninstall and reinstall Java that it would restore the functionality of 2.6.5, but that was a suggestion for OS 9.2 and I don't know how to uninstall my Java for OSX because I don't have a 'control panel' in OSX. Any feedback on this would be helpful.

Anyway, LW rocks and I'm sure all of these issues are being adressed in some way or another already, but just incase, this is my general update for you which I hope helps a little.


Keep up the good work and thanks for the files,

Daniel

p.s. Will we be expecting a 2.7.3 anytime soon?

LimeWire version 2.7.3 beta is out. Download it here.

Any idea what the changes are? I imagine small bug fixes.

Norm

I think so Norm. ;)

I'm think'in.....
 

My guess is.... these are at least some of the issues addressed in 2.7.3

Can the LimeWire Team fill us in? :)

2.7.3
 

Yes, 2.7.3 just fixes the shared 'mpg' problem and the Mac internationalization issue.

2.7.3 also fixes the problem that some of your have seen where the Mac OS 9.x and below installer records an error. This error would also mean that international versions would not install correctly. This is fixed in 2.7.3.

Thanks, everyone.

Thanks guys
 

Thank you Chris and Adam for the info on 2.7.3 :)

Much appreciated... Great work guys.

Thanks guys
 

Thank you Chris and Adam for all that you have done. LimeWire is a great program. Great work guys. :D

You are very welcome. LimeWire is a lot of fun to work on. Thanks to you all for your invaluable help in tracking down bugs.

As you may have noticed, we officially released 2.7.3 earlier today.

Thanks again.

Clarification
 

As a clarification, this link does download version 2.7.3 However, it downloads the UNREGISTERED VERSION. If you want to download the registered version of 2.7.3 (Ad-Free) continue to log in to the limewire site as usual.

Problem with version 2.7.3 of LimeWire
 

When I opened LimeWire version 2.7.3 I noticed that it did not connect to the server right away. It just said disconnected / no files available. Then it connected. Is this normal? Adam, other than that, LimeWire works very well. The LimeWire Installer installed with no problems. With earlier versions of LimeWire and the end of the installation it said there was a error with the installation but now no problems with the installation. :D