3 instead of 6 connections
 

In the connections tab I have set to hold about 6 connections but Limewire holds only 3 connections. I have to write a "6" again into the little text field (where the 6 is already) and THEN Limewire connects with 6 hosts.

I restarted Limewire a few times but it has no effect on the problem.

I use Limewire 2.8.6, Java 1.4, Linux.

That behaviour is intended because the number of ultrapeer connections should not be set to a value greater than 3 by default.

6 connections down to 3
 

I realize that the number of connections should be 3 but to disable the ability to go higher is kinda lame. It was there before and now they take it out altogether? Adding in additional connections was about the only way for me to get any decent search results. That and if do a search with 3 and then again with 6 the result set was much better. There were a number of times that 3 would return _nothing_ and 6 would return _something.

Also the the total files goes up to 800M for me at 6 and < 120 with 3 connections. So yea the return set is low if at three.

Bottom line, I disagree with taking it out. I wish I knew that before I upgraded otherwise I would not have done it. Now it is a useless tool.

I USED to be a paying customer......

The idea was, that if all leafs have 3 connections, you could search a lot more leafs although searching the same number of ultrapeers.

In addition LimeWire is increasing the number of intra-ultrapeer connections to 15, so you should already see more results than before.

The number of results returned by an ultrapeer is limited now. The more exact your search is, the more ultrapeers the search will effectively reach. Searching for "eminem" should not return you more than 300-400 results, but searching for "eminem song title" could easily return 150-200 results for one song alone.

I agree
 

I get much less search results than before. I don't know that it is worth the time using!...(I am using 2.9.8 Pro)

same here
 

Same here, I took two machines, one running 2.9.8 and the other running an earlier version. Earlier version comes back with 30-40% more results. I like the program a lot but after this connection reduction thing, I doub't Ill continue with it.

The number of results returned by LimeWire ultrapeers have been limited to about 80 per ultrapeer and search. However it is very likely that a search will return more results if it is really popular.

the keyword "if"
 

The operative word "if" is the key here. One of limewires greatest attrations was the ability to find the "not so popular" items that are out there. Yea the "wishlist" did this to some degree but I usually kept the setting on 3 connections unless I was trying to find something that was indeed hard to find. I found that I had a higher chance of finding it with 6 connections and letting it sit for 30 minutes so that the number of files it can see goes up. This greatly increased the possibility of find the "rare ones".

I hear you on the connection improvement but tests says otherwise. One machine at 3 connections only show on average ~800M of files where as the earlier version running at the same time on a different machine with 6 connections found 2.4G of files.

I don't think it makes much sense to argue with you about it, but let me tell you this much. Increasing the number of leaf connections from 3 to 6 increases your search horizon only by some 30%-50% because each of the hosts you are connected to will probably search the same set of hosts.

The reason searches would return more results was that the pre 2.9.x network was so overloaded that many searches would be dropped before they could reach the whole reachable network. With more connections the probability of one search surviving long enough to return more results was just a little greater.
Since LimeWire has reduced the traffic and the number of dropped searches, there is no need to increase the number of connections anymore because you will always be stuck with the same set of searchable ultrapeers +/- a few dozens.

So why can't we find anything......