--several times the Monitor showed a duplicate upload (different progress) to the same IP/vendor. Uploading the same file at the same time seemed a waste of bandwidth, so I had to kill one (the lowest) and reset the upload prefs to only allow one slot per person. Too bad--I'd like to allow more slots per person.

Does not seem to be a bug, but a normal behavior. That remote host just happens to use its two upload slots to download distinct fragments of the same file.
This is a feature of swarming. This is not a "duplicate" download, but a convenience (because you have allowed two slots per user, you allow that user to use these two slots as he wants to download any file or fragment from you).

The progress bar only show the position of the download fragment in progress.
This would be a bug if the two progress bars were showing identical positions. Also it may happen (sometimes) that the apparent same downloader is a pair of distinct hosts connecting to you through the same NAT router or proxy. These two users may not be aware that they are trying to download the same file.

However if they are on the same LAN, may be the Multicast support of LimeWire may allow them to cooperate by downloading each a separate fragment from you and uploading to each other the same fragment. I don't know if alternate source discovery also searches the LAN for available files or fragments with Multicast... It could be useful because it will speedup their download experience with Ethernet speed from each other.

--the 'already-downloaded icon' doesn't pick up on tunes that get sent to the shared iTunes folder if they are manually deleted from the unshared dl folder . (Roger--I don't work with iTunes much, so this is likely to be a new user problem. Otherwise, I was impressed by how well LW integrates with iTunes). I guess keeping the Library updated is in the future plans. The recognition of files in the unshared folder does work well--thanks for that.

It depends how iTunes is configured ("Copy files to iTunes Music folder when adding to library" or not - former is default) and if you delete the tune from your shared directory then LimeWire is no longer aware of it (iTunes holds an own copy of it, see the above setting) and it's therefore a new file at the next search from LW's perspective.

Edit: and the future is close. :D

stief posted: Thanks for the earlier info Philippe, and for all your gnutella/LW work too

May be I should add to visitors of this forum that, despite my involvement to the LimeWire project, I am not a LimeWire employee and not a contractant; just a volontary contributor to the open-source project, where I perform beta-tests, suggest corrections, try isolating bugs or performance bottlenecks.

I try to follow all the LimeWire development (as well as the discussions in the GDF group where the evolution of the Gnutella protocol and its usage policy is heavily discussed and debated), but sometimes I may give errors in my responses here and a LimeWire crew will correct me.

I manage most of the work related to incoming translations. Also I am maintaining the French translation up-to-date, and I help translators or contributors that write to the LimeWire "translate" mailing-list.

I also created the "Amber" theme for LimeWire (because I like very basic, non-distracting, themes without bold characters and many colors, and because it was missing to allow displaying correctly some languages written with scripts with complex glyphs (like Chinese or Korean).

I needed this clean theme to test LimeWire in Chinese, Japanese, Korean, Thai, Arabic, and Hindi Devanagari (I used random text for Thai, Korean and Devanagari because we still need translation contributors for these languages).