Thank you for the explaination...

LW 2.70 Beta Pro

On the settings issue, I found a problem with the installer that was causing previous settings to not be saved correctly. I attempted to find a solution that would allow settings from previous versions to be preserved seamlessly, but the solutions were quite complicated and would likely lead to bugs in the future. I decided instead to change the way settings are preserved so that they will be cleanly migrated in future versions. So, as some of you have experienced, you will likely lose your settings on this upgrade, but all future upgrades will preserve your settings correctly.

My apologies for the inconvenience. The problem arose from compatibility issues in InstallShield between the old InstallScript way of doing things and the newer Windows Installer Service. We're now using Windows Installer Service for everything, as InstallScript was overwriting registry settings for previous installations.

Thanks.

Same results here.... Thanks LW developers!

An oddity...

I left LimeWire running over night and came back to find that while it was claiming to be downloading it wasn't...

There were four or five files supposedly downloading (one of them at 24KB/s). The download rate was not changing for any of the files although the time to completion was decreasing. My network connection was still up but the traffic was very low. Uploads were also dead.

I was able to do searches (my connections were still active) but couldn't kick start the existing downloads. Closing and re-starting LimeWire fixed the problem.

A quick look at Task Manager showed that a chunk of processor (around 30% of an AthlonXP 1500) was in permanent use by LimeWire. I suspect a task/thread leak somewhere (but not a serious memory leak).

I do currently have an excessively large download queue (thanks to the ability to resume incompletes) which probably exacerbates the problem (but shouldn't be the cause of the problem).

Mark

Mark,

Are you sure your downloads were really not progressing? If LimeWire reports decreasing time until completion, it sounds like everything is working right.

The 30% CPU usage is disconcerting, however. Did it persist if you shut down all messaging connections? How about if you closed all downloads and uploads as well?

-Chris

Yes - I'm certain the downloads weren't progressing. I use an independent network traffic monitor (there was traffic relating to the active connections - but not to the upload and download queues).

I agree that it is odd - LimeWire responded in all other ways - but the reported speed of the downloads was stuck rock solid (no variation at all). The time countdown looked to be about 1 second a second - so it was consistent - but there was no data transfer.

Sorry - I didn't kill the uploads and downloads. I did kill off all my connections - no difference.

Since then I've been struggling with LimeWire using way too much processor time.

When I initially installed LimeWire 2.7.0 I lost my download queue (a little over 1000 entries - outrageous I know - but it worked).

I used the resume incomplete downloads feature to resume all the incomplete files in my download queue (turned out at nearly 1800 files).

Since my last report LimeWire has been using more and more processor time. I have been deleting files (both from within LimeWire and directly from the incomplete folder) and shutting down and restarting LimeWire. Each restart used more processor time. On the last occassion it stuck at 100% processor utilisation (for an hour or so before I gave up).

I noticed that the downloads.dat file grew to a little over 9MB and was being re-written very frequently (subsequent refreshes while looking at the file would show its size rapidly rising from nothing to 9MB then back to nothing and grow again). Before the upgrade, the largest my downloads.dat file got to was 855K.

I have now deleted my download queue (and the downloads.dat file). And LimeWire seems to be behaving normally.

I shall play further and let you know how it goes.

There is a good chance that my problems were related to a corrupt downloads.dat file (even though it was being re-written?). I'll let you know how things go now that I'm starting the download queue from scratch...

Mark

We've just updated the beta to 2.7.1 with some minor fixes based on feedback. In particular, we fixed an issue where the Mac 9.x and below version would fail to load entirely. We also fixed an issue with downloads, fixed an error with the files in the library, and made several other minor changes.

We have not addressed the problems seen by Mark, as we have not fully diagnosed the issue at this time.

Thanks for everyone's help!

Thanks for the update Adam!

Anxiously awaiting G.U.E.S.S. !!

I have set my "Uploads Per Person" to one to only allow one file to be downloaded per remote computer. This all works fine and well for normal uploads. But on the new queued uploads as soon as these are converted to real uploads it does not honor this setting, it does go up the maximum number of upload slots. Is this an oversight?

Mark,

I'm a little confused by the situation you're describing. So let me see if I understand what happened:

You installed LW 2.7. You had a large number of temporary files in the incomplete directory. Initially there were no downloads in the download window. (Any active downloads from 2.6 were lost.) You select a thousand incomplete files from the library and click "resume". LimeWire kicks of 1000 downloads. Most of them are queued by LimeWire, but some enter the requery state. LimeWire runs slowly. The downloads.dat file grows very large then shrinks. Deleting downloads or incomplete files and restarting LimeWire does not help.

What's the size of your download queue? (Tools->Options->Maximum Downloads) Note that by "download queue" I'm referring to the downloads that say "Queued" because of LimeWire--not those that are remotely queued ("Waiting in Line").

Thanks,
Chris