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

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.