LimeWire 1.9c beta
 

LimeWire has released the beta version of LimeWire 1.9c, available at:

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

This beta is almost identical to the 1.9b beta (probably the most short-lived beta in LimeWire history!) with several important fixes for non-Windows systems. As with 1.9b beta, this is primarily a maintenance release, although the improvements over the LimeWire 1.9 beta are crucial, particularly in terms of performance. The changes include:

<ul>
<li>Significant performance improvements, both in terms of CPU and memory.
<li>Prevents spurious disconnects from UltraPeers after conducting searches that return a lot of results.
<li>Ads in non-Windows versions! Seriously, they are there. Don't worry too much, though -- we did the ads ourselves, so they're a bit less annoying than the Windows ones. If you click on the Amazon link to do late Christmas shopping, a portion of the proceeds goes to support LimeWire and the open source project.
<li>Minor bug fixes with swarm downloading.
<li>Improved logic for grouping similar results for swarm downloading and smart downloading.
<li>Improved UltraPeer election process, so you will not get elected as an UltraPeer if you are a modem user.
</ul>

As many of you have noticed, we are having problems with the Linux installers. We are still unable to identify the precise system configurations that will cause the error, but if the beta installer gives you problems, try just using the tgz file available at: http://www9.limewire.com/beta/1.9c/l...eWireLinux.tgz. This file will also work on most other Unix and Unix-like OSes.

The most important change for the beta is really in performance. You should see significant performance improvements, especially as an UltraPeer, over the previous version.

As with the short-lived 1.9b beta, thanks very much for everyone's feedback on 1.9. Your assistance has been invaluable, and we have fixed many bugs in this version that we likely would not have found without the help of all you forum readers out there!

LimeWire 1.9c is working on FreeBSD. I just had to comment out

J2SE_PREEMPTCLOSE=1; export J2SE_PREEMPTCLOSE

so it would work. If not it gave me this error

/usr/local/linux-jdk1.3.1/bin/i386/green_threads/java: error in loading shared libraries: /usr/local/linux-jdk1.3.1/jre/lib/i386/libpreemptive_close.so: undefined symbol: pthread_kill


But anyways, I have it working...I like the little neat features and options it has. Keep up the good work!

Works Under Linux
 

Installer works for me! Good Work!
P.S. Linux installer hasn't ever worked for me til now! (all betas)

Ads
 

I tried clicking on the ads and nothing happens. Should my browser or something open? I'm using linux. I know Limewire can load a browser because Help-Forums works! thank you.

Glad it seems to be working for everyone so far. Good point on the browser launching with the ads -- browser and file launching on Linux in general is quite tricky, and is an area that we hope to improve. It should work, however, whenever any of the help menu items work.

Anti-Bearshare -- thanks for the tip on the PREEMPTCLOSE variable -- I believe that we put that in there for the Linux JVM (if I remember correctly), so this makes some sense that it would cause problems on FreeBSD. That's great you're running FreeBSD over there -- I was woefully ignorant of its significance to computing in general until reading up on my computing history over the last year. Glad LimeWire's working on it.

I like the LimeWire ads, they look nice. I would like to see more Open Source ads or geek ads (ThinkGeek). Ads along that nature. Even though I cant click on the ad to let it pop up a web page what is the LimeWire Pro all about. Whats the url?

uhmm ok.....

I've been running LimeWire 1.9c since the first time I posted which was not so ever long ago (I would do the math but the board is set on a different time zone or something). This is a fresh install of LimeWire on this system so of course it shouldnt have any values set for my stats (uptime, downloads, etc). But I noticed I'm already an Ultrapeer. This is the first time I have became an Ultrapeer. Before I was running Windows (I wont go into that :x). Anyways I can see that some of my connections are 0.4 and some say leaf. So I'm guessing only 1.8 and up only support the Ultrapeer function? For some reason I was thinking the older clients could take advantage of becoming a leaf. I guess I was having a brain fart (this past week I took all my finals for this semester :P).

Glad you think the ads look alright. If you click on the Amazon ones to do late Christmas shopping, we get some of the profit =).

As far as the connections issue, older 1.8 clients did not have any logic in them to take advantage of new UltraPeers, although this would have been very nice. We really merged in three major projects into 1.9 that had previously developed relatively independently (the swarmed downloading, the UltraPeers, and the query routing, which had undergone an earlier sort of merge with UltraPeers), and none of these had previously been in the code.

Moving forward, we should see some really nice improvements as more nodes become UltraPeers.

afisk, you didn't answer my objections concerning the modem-exclusion for swarming. i ask you again to remove it. one highspeed connection downloading five files could easily consume 30 swarm sources. a modem user would hardly ever use more than 3 until his speed is maxed out. therefore, it is not them who are responsible for having less upload slots. the highspeed users are. furthermore, the current swarming feature allows highspeed users to swarm from up to six modem users and decrease the little bit of bandwidth that they have, while a modem user can only download from one other modem user. sure, modem users don't profit as much as highspeed users. but that also means that they can't harm the network as much. this doesn't make any sense at all. how do you think i feel when i know that:

- highspeed users may swarm
- this decreases the number of upload slots
- therefore modem users (who hardly consume any slots compared to highspeed ones) are excluded from swarming
- but the highspeed ones are still eating up my bandwith in order to max out theirs?

if you want to ensure the number of available upload slots find better ways . for example, link the numer of allowed download connections to the number of upload slots. so a user who has allowed no more than 5 simultaneous uploads should not have more than 5 connections to simultaneously download from.

the way it is is not peer to peer at all. it is next to exploiting modem users. on a p2p network, either everyone should be allowed to benefit from swarming, or noone should.

-- awaiting comments

Abaris-

I did not neglect your questions intentionally -- it is just a bit difficult to keep up with all of the threads and release new clients at the same time.

We do dynamically allocate upload slots in 1.9 and above versions of LimeWire based on your measured bandwidth. The quick solution to this problem is to switch your connection speed to cable in the options window. If you do uploads and downloads, we will still be able to measure your speed, and you will still be reported as a modem in outgoing search results.

We may change this behavior at some point, but this is the way it is for now. It's too sensitive a change to make this close to final release.

Thanks for bringing this up -- you raise valid concerns that we will consider in the future.