I dislike those extra directories being created, so I turned it off.

for those with the source code,
In SettingsManager.jaya, find these lines:

try {
SetSaveDirectory(DEFAULT_SAVE_DIRECTORY);
} catch (IOException e) {
e.printStackTrace();
// this should not happen with the default directory
}

I commented them out, and no more extra incomplete and shared directories. No side effects for me, on winXP pro. Dunno what it might do on other OSs, but like I said, all it does in XP is stop those extra directories from appearing.

We released another beta version (LimeWire 2.4.1) that simply disables the corruption check feature. We will likely release a 2.4.2 update quite soon that will notify the user of the corrupt file in some way, but that will allow the download to continue.

Let us know if this one gives anyone problems.

Aha! All of that bandwidth seems to be coming from searches. I can set the "Show last X searches" to 200 and have it filled inside 30 seconds. In 2.3.2, I actually DID see few to no searches - Maybe one search every 3 seconds. I'm preety sure I'm a leaf, as I have disabled ultrapeer capable abilities and my computer should be an unlikely candidate for being a 'peer anyways (see sig). On close examination in the Windows Connection box, it seems to be a steady 1kb/sec downstream. I know its LimeWire because it only happens when its opened and connected, and I have the Cydoor dummy file so it couldn't be that.

Also, the connections settings are screwed. I enter 6 connections and it always gives me 3 on a restart of the prog.

And PLEEZ fix the bars (saving positions and add a right click menu for all, not just search.)

I'll stop whining now and be happy with 2.3.2

Adam, what purpose does the code I commented out serve?

Why would I want the default save directory set to the default if I already specified what to use as the save dir when I first ran the program?

The only thing I can see that code doing is creating two empty directories: install and shared that I don't use, since I specified a shared directory elsewhere.

If you're seeing more incoming searches in your monitor than you did before, that probably means that you're just sharing more files now, so more searches make it through to you. That said, seeing the screen fill up with searches within 30 seconds is a really moderate number of searches to see, and that should take up very little bandwidth.

On the connection settings, I'll have to ask Chris if he did this intentionally -- it might be a bug, or it might be there to more actively limit the number of connections that leaves can have.

On the "bars" I'm really not sure what you mean. Menu bars? Tool bars? Scroll bars??

Back on the bandwidth topic, there's no reason that 2.4.1 would take up more bandwidth than previous versions, as this code has not been modified. I strongly suspect that you're simply sharing more files now. Is this not the case?

On the directory issue, I put that code back in basically because there has been a bug reported that is caused by not having a save directory set, and always setting a default makes this not occur. Also, without that code, the save directory would handled differently from all of the other settings in the sense that it would not have a default. I've been meaning to refactor that class for some time now, and having all of the settings follow the same pattern code-wise simply makes refactoring easier down the road while also improving the maintainability of the code.

That said, I will try to come up with something better when I do get around to refactoring everything, as I agree that it's a bit annoying.

Thanks.

Aww geez. Now 2.3.2 is doin it too, with the 200 searches filled in 30 sec thing. After a little more rootin around I found a new verion of Gnucleus. I'll bet there's at least a hundred thousand Morpheus/Gnucleus users trying out their new versions by firing off tons of useless searches. I found it when I noticed in the "vendor" column a "Morpheus PE". Last i checked Gnucleus didn't support 'peers so that must be it. I also think ZoneAlarm is f***ed badly as it reports that 1kb/sec downstram trickle the same as a full speed download, even tho the numbers in ZA's alert panel don't budge. In other lime vesions, ZA was oblivious to ANY activity, so it don't make for a trustworthy source. I get my numbers from window's connection panel.

I haven't been sharing any more files, the same 217 MP3's i've had all week. And certainly not any files that MATCH have those searches (although they have been getting cleaner lately).

Anyway, I do like the fix of the bouncy transfer rates (16k,0k,16k,0k,etc), a very nice touch.

And these be the bars I'm referring to:
http://www.mts.net/~spider4/bars.jpg
They never stay put on restart and can't be chosen with a right-click (only the search bar does that).
Fixing these shall bring world peace. :)

/Thanx

I'm trying LW 241 pro and I'm seeing what looks like a problem with the last several versions of LW using Java1.4 on WinME. The speed of every upload from my system remains at 0 KB/s and there is no progress. I do see a number of people trying to upload stuff from me so I know their searches are finding files on my system. Note, when I use gnucleus 174 I see upload progress and speed actually indicating that a upload is taking place and it completes successfully. In LW most uploads end in transfer interrupted. Is this a bug in LW?

I am also seeing bandwidth problems in 2.4.0. i used to get 3.5kb/s on the old Lime Wire using my 56k but now it wont even get to 3.00.
Also the meta data searches for MP3's are pretty bad, if i type in an artist and a title it brings back totally irrelevant files which have a couple of the words from my criteria in them. For example if i type the Artist "Ash" and the Title "Goldfinger", it brings back results from bands called "Goldinger" with the track name "Open your eyes", all it did was found my track name i searched for and found an artist with the same name. I hope the meta data searches won't be that hard to fix. The only search which is good for finding specific tracks is the "Any Type" search window.

Anyways keep up with the development.

I hope that Morpheus is not trying to act as an Ultrapeer without our QRP (query routing protocol) in their code. That would be a disaster for our Ultrapeers.

Thanks
-greg