Friends,

I don't know what has made me more angry: the fact that the LimeWire team has had the gaul to release 2.8.5 as a working version (when it is obviously a very poor quality beta) or the fact that they've gone totally silent in this Forum, not dealing with any of the legitamate issues we've raised.

I think we have to do two things, all of us

1. start looking for alternative software, and

2. let the LimeWire team know it.

I've sent emails to each of the developers listed as "moderators" on this Forum. I recommend you all do the same.

Janet

There are one or two really bad bugs (I know of) in LimeWire 2.8.5 - surprisingly none of the bugs mentioned in the forum had anything to do with it.

I'll give you a few examples:

The "could not move to library" problem (caused by other clients sending malformed queryreplies) has been existing for a few months now and it can't have become worse with LimeWire 2.8.5, since it simply didn't even try to cope with it (since it happens pretty rarely).

The slower downloads reported here cannot be confirmed by any test I ran and I don't think they are slower than before since the download / upload code wasn't really changed that much. It's true that it might confuse users to see downloads disconnecting and reconnecting every couple of seconds but that really doesn't affect the speed, because the TCP connection is kept alive during the entire download from one host. A simple fix would be for example that the GUI will not show that the HTTP connection is dropped after downloading 100,000 bytes so the user wouldn't be concerned.

There is now a GUI bug in the uploads window that causes uploads in chunks only to reach a few percent in the progress bar before restarting at zero. However this bug does not affect upload performance. (I think Sam Berlin already sent a fix for that).

Other complaints were more or less expressions of general discontentment with the new version and not really helpful for any developer.

The real problems, for example that version 2.8.5 will almost never become in ultrapeer and that there is a severe shortage of ultrapeers (causing poorer search performance, frequently failing connections,...) weren't mentioned here at all.

Besides - most of the LimeWire team has been on vacation since christmas and they are just about to resume work again, so you will probably see some bug fix releases next week.

I've tried all the suggestions made above that apply to my Mac and nothing's helped.

I've trolled the Forums for assistance and only found fellow sufferers.

No reliabe software developer releases a system as unstable as 2.8.5 (basically, it's a beta) and then sends his entire team on a three week vacation.

Briefly: I'm attempting to share a library of 40+ large (50-400MB) avi and mpeg files. I downloaded about half of these under LimeWire 2.7.6 and 2.7.13. The second half comes from other sources.

There are twenty avi/mpg files I'd like to add to my library. I've found at least 2 or 3 sources for all of them on gnutella. Many of then show up in my frequent searches.

However, since installing 2.8.5, I haven't been able to download any file that takes longer than 7 minutes -- most download attempts don't last even 5 minutes. The only way to get downloads to restart is to quit LimeWire and relaunch. Then, I get another 5-7 minutes from the same hosts as before. I can leave LimeWire running 48 hours straight, it doesn't matter. Downloads will not resume unless I relaunch.

On the upload side: I leave LimeWire running almost evey night. When I get up in the morning, I usually find about dozen or more uploads of my large files. Bearshare, gnutella, Sharezade, etc all show 100% complete. Some LimeWire 2.7.x and 2.4.x also show 100% complete. ALL LimeWire 2.8.5 uploads show Transfer Interrupted or are frozen at 5-10% "complete." I have not seen a single LimeWire 2.8.5 user complete an upload, ever.

The parcelled download/complete/download transmission philosophy used by 2.8.x is clearly flawed. Something about the system causes hosts to "time out" any download that takes more than seven minutes.

I'm not complaining that 2.8.5 is slow [it does appear to be, but I haven't taken any measurements]. I'm not complaining that it's buggy [it is -- there's the Window Manager bug, the cannot move to library bug, and others]. I'm complaining that it fails to perform the function for which it was designed. LimeWire 2.8.5 does NOT facilitate the download/upload of Gnutella files.

2.8.5 is a failure. The LimeWire team needs to fix it or withdraw it, not dump an untested system on users then abandon them for three weeks.

It I sound angry, I am. I woked in software development for 30 years. I made plenty of mistakes in my time, but I never walked out on users and left them to cope with my errors.

Janet

Way to go Jannuss.
Once again, we are faced with developer in denial syndrome.
While I may not speak 'developer', I can relay what is occurring, and I would think, if 'developer' tested the program with a watchful eye, he/she could replicate the symptom and put it into 'developer' language to share with other 'developers'.

I would have also liked to see Senior Member address the automated response telling us to revert to version 2.7.13, when in fact, that is impossible, because 'developer' has not made any provision to accomplish that task.

Plus the fact that Pro Support is not responding to emails, it just adds up to a philosophy that they want us to support their efforts, but will only deal with the peasants when it suits them.

Well, I don't support outfits that operate in this manner. I'll continue to use free versions, if and when they put one out that works, but my Pro days are over.

LimeWire's download behaviour is less aggressive than the behaviour of other clients. While other clients might keep hammering the same host for a file, even if it claims not to have found the file or if it doesn't respond at all to a connection request, LimeWire will just stop. Now if a remote host simply drops a connection for no apparent reason (e.g. because of a bug in the remote client - you will run into those bugs more frequently when downloading chunks), LimeWire unlike other clients, will think it is impossible to download from that host. LimeWire has always done this. I've been pretty successful downloading small files (up to 50-60mb's) from LimeWire. Very large files have never worked well, - they work better if you are using a more aggressive client like Shareaza or BearShare but they don't work really well with any gnutella client at all. The main problem is that people don't share big files on gnutella. If you want to download movies for example you use Kazaa or eDonkey, and thus you will share them on Kazaa or eDonkey. I've been sharing a very popular movie for two weeks on gnutella, and although at least three or four uploads reached 100% (I've got only 128kbit upstream) I've never seen a copy of my file again anywhere on gnutella.

With the current GUI problem you will never see a 2.8.5 user complete an upload in the 2.8.5 upload view, - the uploads do complete, however. The 2.8.5 user will download chunks of 100k and after each chunk the progress bar in the upload view shows 0% again. THIS DOES NOT REALLY AFFECT THE UPLOADS.

Trap-Jaw,

I know you're much more knowledgeable of the LimeWire download/upload procedures than I, but unfortunately, this time you are wrong.

1. I downloaded over a dozen large avi and mpeg files (80-450MB) from Gnutella using 2.7.6 and 2.7.13. But, from the day I installed 2.8.5, I have been unable to download any large files. The files I want appear in my searches; I know that at least one of the hosts containing them is on line nearly non-stop.

Old LimeWire users continue to upload files from me without difficulty -- on Friday a 2.4.1 user uploaded a 80MB file. This morning a 2.7.13 user uploaded two of the same size.

There is a real problem with 2.8.5 on downloads, and it is a new problem.

2. Since I do not have 'auto-clear completed uploads' checked in Preferences, I do not see uploads revert to zero after every parcel is completed. Believe me, I've been monitoring this for several week now. 2.8.5 users do complete 100% of uploads for small files (under 10MB). They do NOT complete large uploads. At 10KB/s, it takes over two hours to upload a 80MB file. If a 2.8.5 users shows "complete" after half an hour, he does not have 100% of the file.

2.8.5 is broken, Trap-jaw, it needs fixing.

Janet

That is entirely possible. If the remote host has a problem with http1.1 support although advertising it, - e.g. it drops the TCP connection after you stop the HTTP connection your LimeWire will just stop downloading. I know that does happen when downloading from some clients. I don't know which client behaves like this but you will not experience anything like that, if you are downloading from another LimeWire host.

There is absolutely no possibility of making sure 2.8.5 upload has reached 100% from your side. If a 2.8.5 user shows "complete" after half an hour he might have downloaded the earlier or from another host.

" There is absolutely no possibility of making sure 2.8.5 upload has reached 100% from your side. If a 2.8.5 user shows "complete" after half an hour he might have downloaded the earlier or from another host."

I think you should bring back an upload progress bar that works. Same ip connects and disconnects, no aqua in bar to indicate what stage upload is at, and time remaining never diminishes. Even if it is only relative, it would be helpful.

Plus, could somebody explain the way the Library computes uploads? I don't understand the fractions. Say it is 34/78, I would expect as chunks transmit, the first number would increase, but both increase, and often, the first number never catches up to the second number.
Very confusing.

>I think you should bring back an upload progress bar that works. Same ip connects and disconnects, no aqua in bar to indicate what stage upload is at, and time remaining never diminishes. Even if it is only relative, it would be helpful.

It's fixed for the next major version. (Don't think it'll make it into the 2.8 series, but it's just a display bug anyway.)

>Plus, could somebody explain the way the Library computes uploads? I don't understand the fractions. Say it is 34/78, I would expect as chunks transmit, the first number would increase, but both increase, and often, the first number never catches up to the second number.

It's not really a fraction. The first number is the amount of completed uploads, the second is the amount of attempted uploads. So, if one person tries to upload, it'll show as 0/1. If that upload completes succesfully, it'll become 1/1. If someone else attempts, it'll be 1/2. But, if that person cancels the upload, it'll stay at 1/2, and the two well never again be the same number.

Right now, chunks count as distinct uploads, so someone uploading one file in chunks may generate 50/50, or 49/50, if they decide to finish early. This may be somewhat confusing, and there's arguments for and against it... but changing it would require a pretty massive overhaul (well, not really, but doing it correctly would).

Any suggestions on how to make the numbers more meaningful?

"Right now, chunks count as distinct uploads, so someone uploading one file in chunks may generate 50/50, or 49/50, if they decide to finish early. This may be somewhat confusing, and there's arguments for and against it... but changing it would require a pretty massive overhaul (well, not really, but doing it correctly would).

Any suggestions on how to make the numbers more meaningful?"

Given the choice, I'd prefer you folks work on the important stuff that needs attention first. Once there, you can always do the .1, .2, .3, .4
dance to tweak things.

Sincerely,
Ready for Version 3