The bulk of my suggestion may be found here.

In thinking more about this, it is not a matter of file content, but one of file size that needs to be addressed.

Something like

• < 1 MB
• > 1MB < 8MB
• > 8MB < 75MB
• > 75MB

where each group may have a different number of active upload slots open. My options would be small numbers of large file uploads -> large numbers of small file uploads.

How about a size search criteria backed up with a size filter? Oh hey I think I mentioned that one before. lol

There are File Type options for columns in the search results & library window except the download window. Just wondering whether this was an oversight? I'd find it handy myself. Then could arrange downlds via type.

Attached Images

type.gif (233 Bytes, 491 views)

I was thinkin of somethin like usernames and passwords for each user to make it able to create a User List just like in 'Soulseek'.

And there also should be something allowing users to see how much of a file is downloaded in bytes.(not the percentage)

When a file that is currently paused due to a 'need for more sources'. I would like to have an option with LimeWire where these paused files would feature an automatic search for more like files. WinMx already does this very useful feature and it enables the user NOT to have to keep clicking on each of these paused files in order to search for more downloadable files.

Also, I would like to see an better option for 'clear inactive files' Some files such as the paused ones I described above are immediately erased even though they were still in the 'pause' phase. The only files I consider to be INACTIVE should be only those that I have cancelled myslef, have been cancelled by the uploader, or have been already fully downloaded by me. No other reason should my files be deleted just because they are in need of other sources. IF the files must be deemed 'inactive' and deleted, then they should be ultimately restored and in process of finishing the download the next time LimeWire program is restarted.
[FONT=arial][COLOR=purple][SIZE=3]

BitTorrent is probably a good addition to think about: we could still exchange torrent links/trackers in the serch results, but then BitTorrent could be used as an alternate transfer protocol.
The caveat is to define a way to regulate the traffic with other Gnutella messaging and Gnutella HTTP transfers.
Also, it's still quite difficult to unify sets of sources for the same file that would be available on Gnutella and on BitTorrent trackers.

It's true that very large files like videos are more present on BitTorrent than on Gnutella. But I fear that without some regulation, Limewire could be perceived by BitTorrent users a a leacher, and it could be banned if Limewire does not reshare all the files it has downloaded from Torrent sources. To implement BitTorrent in Limewire, would mean that LimeWire should dedicate a minimum output bandwidth for BitTorrent reshares.

But if one finds some solution to manage this share of bandwidth smartly, Gnutella would then benefit of more large files initially loaded from Torrent sources.

For now, all you can do is to install a separate BitTorrent client, running in parallel with LimeWire, and adapt their mutual settings, so that each will have its own minimum dedicated bandwidth.

This solution is workable in practive only for those users that have more than 128Kbit/s of output bandwidth (else, using both clients in parallel will make browsing and emailing a nightmare, and users will need to shutdown one of the two clients. May be this is already happening, so users have to switch from one client to the other, and this gives a negative impact on both networks, with too low connection time...)

Note: we would need a complete open-source Java implementation of BitTorrent; for now Limewire has no time to develop and support it; you should know that what makes BitTorrent so popular is in its protocol that allows swarming; but Limewire implements now secure swarming, including from firewalled sources with its very fast FW-2-FW transport protocol based on UDP (which can be even faster than TCP...)

It is not recommanded however to run two separate P2P clients in parallel on the same Internet connection, as they don't mutualize their use of the bandwidth, and it's difficult to tune them so that they can cohabit. Also, each one will consume large amount of resources on a local host (notably for their internal caches), unless you have comfortable memory, a fast swap disk, and a veryu recent OS that supports hundreds of threads efficiently, and some good knowledge of networking limits in your OS, and in your router configuration.

/me has an open-source BT implementation for LW. However it won't make sense to add it until LimeWire has switched to NIO.

I would like to see feedback in this thread as to which suggested new features are accepted ... preferably with a guesstimation of in which version of LimeWire the feature will probably appear.

I have close to 100 large TV show videos (340MB+ each) that I would like to share, providing there is some way I can prevent all available slots from being grabbed for transfers that take 2 (or more) days at 2KBPS ... when my primary delight is in sharing audio files. So when my desired new feature is implemented, I would jump at the opportunity to D/L the new version.

@GooRoo: The feature you talk about was suggested some time ago (some time means Summer 2003) during the Queue-Discussions in the GDF.

http://draketo.de/inhalt/krude-ideen...sscussion.html

Sadly it still isn't realized. It seems we will first have to find some developer of a small servent, who implements it and shows, that it truly does work (the problem was the same with swarming and automatic requerying (which evolved to the download mesh).

Maybe you could ask the Programmer of Phex (Forum in Gnutellaforums). He sometimes does work on donation-basis for deciding which feature to implement next.

__________________

-> put this banner into your own signature! <-
--
Erst im Spiel lebt der Mensch.
Nur ludantaj homoj vivas.
GnuFU.net - Gnutella For Users
Draketo.de - Shortstories, Poems, Music and strange Ideas.

I would LOVE a feture that would work like Amazon.com's

"People who like X also like Y and Z"

For example, when I do a search for an artist under audio, I would like to see a list of Artists that seem popular on the Host computers that have matches for the original search.