Yes - I thought I was getting a bit garbled.

> You installed LW 2.7.

Yes.

> You had a large number of temporary files in the incomplete directory.

Yes.

> Initially there were no downloads in the download window. (Any active downloads from 2.6 were lost.)

Yes.


> You select a thousand incomplete files from the library and click "resume".

Yes - close to 2000 as it turns out.

> LimeWire kicks of 1000 downloads. Most of them are queued by LimeWire, but some enter the requery state.

The vast majority went quickly to the requery state. (aside - I've noticed that when I start LimeWire 2.7 that the files very quickly go to the requery state - previously they would stay at queued until a free download slot tried to connect the file).

A half dozen had started downloading by the time I came back (telling 1000 files to resume takes a few minutes to process :^) ), a few were waiting on busy - the majority were on requery.


> LimeWire runs slowly.

Initially it performed pretty well considering the load I was putting on it. But over the next 48 hours it was using more and more processor time despite me removing 500 or so files from the download queue.

> The downloads.dat file grows very large then shrinks.

Yes.

> Deleting downloads or incomplete files and restarting LimeWire does not help.

Perhaps it slowed down the rate at which things got worse. Or it may have been my fiddling that was making matters worse. Sorry I can't be more helpful here.

> What's the size of your download queue?

The maximum was 30 (I never achieve that many downloads - it has only ever made a difference to the rate at which queued files are converted to requery).

In an attempt to reduce CPU usage I dropped it down to 10 (and 5 briefly). It didn't appear to make any difference.

...

Since I deleted the download queue and started from scratch things have been running fine.

I currently have around 400 files in my download queue. The downloads.dat file is currently at 1,813 KB although it is growing at an appreciable rate (now 1,822 KB). And shrinking before coming back up to the current maximum size (looks as if the file is being re-written (hence the small sizes as I catch it part way through the re-write) and growing overall.) (now 1863 KB).

(now 1,894 KB).

Mark

(now 1,919 KB).

I haven't yet DL'd this new version because I'm a bit curious about the 'QUEUE' feature.

Where do we stand with users running the previous version without this feature? If they are NOT to be queued when making a request, as we with the new version are, then how does the newer version prioritize the queue for a request. Seems to me that the new version could keep me waiting in line longer than average if there are users that can override a queue. If I'm not misstaken, that's why this feature has been added in the first place so that users don't bombard the network with multiple requests.

During my usage of LimeWire 2.6, for example, if get a 'requery' result all I do is search for the exact same content again and, low and behold, as soon as my search finds that file, the requeried file starts downloading. In so doing this, aren't I skipping in line through other requests and pushing my request through?

If this is not the case, then can someone please explain the default parameters during this scenario? In other words, how are these 2.6 requests prioritized within our new queue function?

CkyFan

LimeWire is exhibiting same/similar problems as before.

I've left it running so I can try out any fiddling you might suggest.

Situation:

I have around 400 files in my download queue. One file is actually downloading - it claims from 4 hosts.

The speed is shown as a rock solid 13.4KB/s and the countdown timer is decrementing at about a second per refresh.

Looking at the file in the incomplete folder - it is growing - so the download is happening.

My uploads are also showing a constant number of KB/s (but the variation there is usually less anyway). The countdown timers (on the four files currently being uploaded) are decrementing at between 1 second/refresh and 3 seconds/refresh - extremely consistent - no jumping of a few minutes as I would normally expect - the variation in countdown times is /across/ the uploads - each individual upload has a very consistent rate of decrement).

I am able to start new downloads (search for a file - put it in my download queue and a couple have started downloading). They are definitely downloading - I can look in the incomplete folder and they are growing at an appreciable rate - BUT they are shown as downloading at 0KB/s - no time to completion shown.

I think processor usage is more than normal - but it isn't extremely obvious - I have a suspicion that it will get more pronounced over time.

I have tried setting my number of connections to zero and removing all the active connections - this made no difference to the behaviour reported above.

I haven't tried removing either uploads or downloads from the relevant queue yet.

My downloads.dat file is currently 3,280 KB. (9 files added to the download queue since my last report - as detailed above, two of these are the new downloads I started).

Mark

I have now tried Killing uploads from the uploads queue.

I killed off the uploads in progress first - this resulted in them being removed from the upload queue as expected - but nothing jumped in to take their place despite having around ten "queued" upload requests (There is usually a lot of demand for upload slots - I would expect a free upload slot to be filled instantly).

I then went on to Kill the "queued" uploads. They were removed from my upload queue. - They were eventually (after a minute or so) replaced with other queued items.

I now have 10 queued uploads and one "uploading". However, the one uploading is showing as 0KB/s although the progress bar is now at 1%.

Searching is using up /way/ more processor time than it should (at a rough estimate - an order of magnitude more - err... 10 times more than normal). Oops - not quite true...

A search that returns a total of 152 results uses a normal amount of processor time (a maximum of 50% processor usage (mostly a lot less) for around a minute (normal search time)).

A search that returns a total of 1466 results used up 100% processor for for around 6 minutes.

But (sorry) 1387 results - does go to 100% processor but only for around 20 seconds (A little high - but within spitting distance of normal).

It seems that occassionaly (I can't find a bit of consistency yet) a search takes a lot (a lot) more processor than normal.

Downloads.dat is the same size as reported at the end of my last message.

The progress bars on the upload and download queues seem to be correct - it is just the speed which is stuck.

Mark

ckyFan:

2.6 users can never jump the queue. If the uploader is busy, 2.6 user will simply be rejected as usual.

-Chris

Mark,

LimeWire isn't really designed to handle so many downloads. I expect (hope!) most users don't have more than 10 or so active at a time. Does LimeWire still have problems if you only have a few downloads and no active searches?

Do you get performance problems if you have just one download and then do a very popular search with lots of results? If so, I think I can fix that for LW 2.7.2.

-Chris

I would welcome any performance improvements - but that isn't the problem (I accept that a popular search may take processor usage to 100% - the problems I'm describing are new in the 2.7.0 and 2.7.1 versions of LimeWire).

There are two serious problems that may or may not be related.

1. If I leave LimeWire running continuously (which I normally do) the speed indicators on the download queue, on the upload queue and i/o on the connections all freeze (between 24 and 48 hours).

2. LimeWire uses more and more processor time - this only becomes obvious after 48 hours or so. This is not fixed by closing down LimeWire and restarting it (it actually gets worse). It is fixed by deleting the download queue (and downloads.dat) completely.

There is something seriously broken that was not broken prior to 2.7.0. I may have forced the problem by stressing LimeWire more than average users... I am not mis-interpreting normal LimeWire behaviour (I know LimeWire can be a resource hog - these problems are over and above that).

LimeWire is currently using 80% to 90% of my processor - I have no connections (set to zero), no uploads (set to zero), no searches (set to 1) and I'm downloading 6 files(maximum of 10). I have an AthlonXP 1500. This is *far* too much processor usage both in absolute terms and in comparison with 2.6.3.

Mark

Mark,

Thanks for the clarification. Your reports are disturbing. Does error #1 happen without any downloads? (I.e., do uploads and connections freeze on their own.)

I would be very grateful if you could tr running LimeWire with profiling turned on. To do this, change your LimeWire shortcut to

java -Xrunhprof:cpu=samples,depth=20,thread=y -jar LimeWire.jar

Use this shortcut to start LimeWire. After you shutdown LimeWire, it will write profiling information to the java.hprof.txt file in your current directory. Please email this to me at crohrs at limewire.com, along with a brief description of what you did during that session (e.g., start 3 downloads). You can run LimeWire in different situations and send multiple files if you want. This might help us separate the two issues (if they're different).

Thanks a ton!

-Chris

Note: when scrolling down through a file list using the down arrow on the keyboard the program responds differently in the search and library tabs.
In the library tab, when the cursor get to the bottom visible line of the file list, the list starts to scroll up so the highlited file is always visible.

In the search tab, the highlited cursor scrolls out of sight. If I click on the scrollbar I can bring the highlited file back into view.

Preferrably, I'd rather have them both work like the Library tab.

After reading the messages from Mark, I know this takes low priority, but should be much easier to address <grin>


Associated request for enhancement:
How much trouble would it be to be able to use the scroll wheel on my mouse to move through the files?

suIre
2.7.1
Intel 1800, 256
Sharing 1200+

Scroll wheel works fine for me....