LimeWirers of the world unit -- a little organized action should get a response
 

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 simply run out of ideas
 

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.

Re: I've simply run out of ideas
 

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.

Sorry, but the facts don't support your argument
 

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

Re: Sorry, but the facts don't support your argument
 

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

">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.)"


I'm a display kind of guy. It's more than a bug to me. But I am relieved to hope that it will be addressed. In the meantime, how do I tell how many chunks remaining in somebody's upload?

Sincerely,
Proud GUI

>In the meantime, how do I tell how many chunks remaining in somebody's upload?

that's kinda the beauty of chunked downloading -- there is no number. you can start by thinking you'll need 100, then find another downloader and realize you only need 50, then another and realize you only need 33, and then realize the other ones are slower and bring it back up to 50, etc... but nowhere in the code is there ever a number, it all depends on the progress of the downloading.

>I'm a display kind of guy. It's more than a bug to me.

i agree. :) but, given that all limewires connect with each other and with other clients, problems with the core networking code are the most important to fix first. otherwise the entire network could come to a screeching halt. don't worry -- things that look/feel wrong in the gui are still very important, especially basic things like displaying uploads correctly.

So far this 2.8.6 feels a lot more stable than the last incarnation. I hope that is an omen. Thank you for finally putting it out and replying to us.

How about some basic courtesy to users?
 

Why should we have to discover that 2.8.6 is out by reading it in a message buried 13 deep in some post.

A basic courtesy to readers of this Forum -- and simple good development practice -- would be to announce the latest version in a 'sticky' at the top to the formum page.

Janet

A hopefully simple way of expressing uploads would multiply the number of chunks transferred by the chunk size and dividing that product by the total size of the file. This value would give the number of times the full file was transferred. This method assumes the chunk size is always the same and the counter distinguishes between chunks at the fixed size and other transfers.

Example:
A 4,000 K file has 100 uploads at 98 K so 9,800 K transferred. Therefore the entire file transferred 2.5 times (9800/4000=2.45). Including a decimal place may hint that this value is an estimate and not a simple count.

That's a pretty good idea. Although I wonder if the decimals might be confusing for the average user (who is probably already confused enough at the non-fractionness of the fraction). I suppose it's easy enough to just seperate them into two columns, and then 'Completed', 'Attempted' as titles -- with the new ability to hide columns, it's probably less of a worry about column clutter.

You're welcome. :) -- Although the actual inhouse LimeWire team really does deserve the thanks more than me.

I'm not sure what to do about the message -- I just run LimeWire on Windows 2000 (my computer).

Neither am I sure what to do about caches -- that seems like a Jaguar thing.

I'm not sure if logging from terminal or process watcher would help (mainly because I don't know what kind of details they'd show) -- but nothing hurts.

There's no need to limit what you share -- the more, the merrier.

Others in the forums have gone into detail about how to configure routers and whatnot to forward ports to certain computers for running LimeWire. The push code will try and take care of everything, but it's always easier if someone on the outside can just connect to you. I, for example, run behind a firewall that completely disallows anyone to make a connection to me -- I must initiate it. There's absolutely nothing I can do about it, so I just let the push code handle all the work, and I still manage to serve a decent amount of uploads.

I've found that turning off the firewall is the way to allow the most uploads, not ideal by any means. Pushing the ip really decreases upload connections. Hopefully it will get better in version 3.

I have not played with the cache, the terminal, the process viewer, and have always installed updates right on top of the current installation. I disabled the ultrapeer capability, but still have had 3 unexpected quits over a 24 hour period. It is running with much greater stability in this version, although that may sound like a contradiction.
On the cable modem, I cut the bandwidth down to about 50%, and set uploads at 5, although I frequently see more than that uploading. That is a new bug, again hopefully fixed soon.

If I allow any more bandwidth, network usability for other activities degrades considerably.
Anyway, that is my experience.