Gnutella Forums

Gnutella Forums (https://www.gnutellaforums.com/)
-   New Feature Requests (https://www.gnutellaforums.com/new-feature-requests/)
-   -   Feature Requests (https://www.gnutellaforums.com/new-feature-requests/25656-feature-requests.html)

sberlin January 25th, 2005 08:51 AM

You can download the current betas at any time by going to the beta page. Each download page (free, or pro) has a link to the betas below the main links. The betas will be released into production shortly -- there's a few small problems we want to take care of first.

You can already drag files from within LimeWire to the desktop or other applications. For example, I routinely drag files from the library or download area into other folders on my desktop. Drag/Drop within the library (dragging a file from one shared folder into another) will be re-added when we make LimeWire recognize 'drop' activity. Along with that, you'll be able to drop files/folders from the desktop and LimeWire will ask if you want to share those files.

We'll look into making unshared folders in red. The only folder that could ever be unshared, though, is the 'Saved Files' folder.

stief January 25th, 2005 09:08 AM

If PFS is off--won't all incompletes be also unshared (making that folder also eligible for red)?

sberlin January 25th, 2005 09:15 AM

True. We'll look into it.

Lord of the Rings January 25th, 2005 06:41 PM

Quote:

If PFS is off--won't all incompletes be also unshared (making that folder also eligible for red)?
But won't that scare a great many people! At present files in red in the incomplete folder are ones that have lost their ability to downld for whatever reason. That issue was my 1st reason for posting on the forum. Library Items in Red How about a different colour or method.

KDII January 28th, 2005 08:24 PM

Unlimited Searching
 
It would be nice if you could keep the search open for an unlimited amount of time so more sources could be found. Then having the option to stop the search when you were satisfied with how many results you found.

unknownuser February 4th, 2005 03:05 PM

I think An option to have a sound played when a download is completed should be added.

Unregistxcveredccc February 5th, 2005 09:52 AM

Library categories
 
How about the abiliby to use teh "artist", "title" "album" and "genre" tabs in the Library tab, so you can sort the playlist by genre or artist?

SuperSayinHi February 19th, 2005 08:12 AM

This has probly already been said, but i would like LimeWire to have a seperate Downloads and Search page. Its easier to change the page than to slide the bar up and down or click those little black triangles..

Also, When searching for an audio file, theres 3 colunms to the left that say 'Genre' 'Artist' and 'Album'. IMO a 'Title' colunm would be better than all three of the others...

sberlin February 19th, 2005 08:42 AM

You can change what the filters on the left are filtering by clicking the circular icon in the top-left of the title of the filter.

redimpact1 February 19th, 2005 02:02 PM

could you please add bittront

GooRoo February 23rd, 2005 07:41 PM

Open Ports by file size
 
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.

Lord of the Rings February 24th, 2005 01:00 AM

1 Attachment(s)
How about a size search criteria backed up with a size filter? Oh hey I think I mentioned that one before. lol http://users.pandora.be/eforum/emoti.../happy/019.gif

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.

halo flow February 25th, 2005 09:11 AM

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)

divathequeen February 26th, 2005 11:21 PM

OPTION 4 AUTOMATIC SOURCE SEARCHES
 
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]

verdyp February 28th, 2005 06:32 AM

Quote:

Originally posted by redimpact1
could you please add bittront
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.

trap_jaw4 March 1st, 2005 02:05 PM

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

GooRoo March 1st, 2005 06:47 PM

Developers' feedback to requests
 
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. ;)

arne_bab March 1st, 2005 11:58 PM

@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.

boo_hoohoo March 2nd, 2005 08:47 AM

Re
 
Quote:

Originally posted by stief
--repeat search added to the context menu of the downloads pane

-*****ulative search results for repeat search (differentiate old sources by grey colour?).

--truncated filenames in downloads pane visible by tooltip (as with search items).

--clicking on a download enters the filename in the keyword search box (automatically or by contextual menu). [redundant if the edit menu happens].

--a Gnutella CONNECTION TESTER (stand-alone or integrated), that will diagnose and rate the health of the connection relative to what the user can expect with a browser, identify upstream blocks and filters, and link to suggestions for improvement as et voilą rightly suggests. [useful even if the firewall->firewall transfers become widespread] Old request here

--moving all the advanced stats (and maybe similar GUI options like IP, Location, and Vendor) to a standalone app or plugin (Pro goody?)

--first time splash screen that also warns about slow start-up because of hashing. Better yet, the hashing of 50 files before connections are attempted the first time. Hashing of further files and folders made relative to CPU usage.

--Add File menu item added to the Library->File Menu [already covered under Drag and Drop addition?]

--support for bit-torrents/bitprints/multiple networks or whatever the current filesharing fashion happens to be ;) . Do unto other networks better than they have done unto gnutella [discussion over here]


Unregisfefsxteredqwe12 March 5th, 2005 10:31 AM

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.

Queued March 6th, 2005 07:28 PM

or Awaiting Sources
 
I would like there to be one change that I think would be most helpful and that would be to allow us to see if we are in someones queue. I mean, I click on Resume, it then says Queued, then Awaiting sources, so what am I? Am I in someones Queue or am I still in limbo awaiting sources? I'd really like to know what position I am in someones queue and how many are before me. I think that little bit of info would be most useful.

GooRoo March 7th, 2005 06:18 PM

Re: or Awaiting Sources
 
Quote:

Originally posted by Queued
I would like there to be one change that I think would be most helpful and that would be to allow us to see if we are in someones queue. I mean, I click on Resume, it then says Queued, then Awaiting sources, so what am I? Am I in someones Queue or am I still in limbo awaiting sources? I'd really like to know what position I am in someones queue and how many are before me. I think that little bit of info would be most useful.
My experience has been that "awaiting sources" means that the 'source' one attempted to download a file from has gone off-line. Otherwise, one may get "waiting for busy host" (not in the queue), or if lucky "... position ##" if in the queue, with ##-1 being the number of users ahead of you in the queue.

Lord of the Rings March 8th, 2005 07:53 AM

(Just in response to the last few posts.)

It is my understanding the Resume button was designed to attempt to connect to the original sources. And that the Find Sources button was designed to try to re-connect to files that had been downlding earlier in that same session.

However it's my belief (right/wrong) that too many people have an easy plug & play attitude where they just want to open LW & resume all their files & runaway & play another game. I believe that's abusing the abilities of LW. It puts a lot of pressure on LW, the computer's resources, & also the connection, & probably also the Gnutella network with too much simultaneous/constant traffic. On the forum people wonder why their computers freeze or lose connection, or get poor results.

I find Resume is best used when a file has been previously downlding that session but stopped or else, the search results are still present & valid. Or the function is used well after LW has settled down & attempted to make its own connections with all incomplete files. Then choosing to resume individual files. Well that's my experience & IMHO. :rolleyes: :)

A search for the topic is the best way to find sources IMO. So LW sometimes needs some baby-sitting. Just letting LW look after itself seems to work for me most times. Perhaps b/c I very quickly seem to have people uploading from me - and I have a variety of shared material.

Queued_1 March 10th, 2005 08:57 PM

sorry if I mention something I shouldn't
 
I don't know if I'm allowed to mention other P2P programs here, so if you must, delete this post if I shouldn't have.

And I'm sorry if this sounds like an attack, if it does, it's not intentional and I don't mean it to but -

LOTR - Resuming a download from the original sources? Sorry, any other P2P will seek out new sources during the course of a download session for example "WinMX" will seek out new sources every 10 minutes and if it finds new sources you'll get multiple streams, just like Limewire, so I don't know why Limewire would just get stuck on a hump trying to resume from the original source host, do you? Mutliple point download is just that, if you're downloading from one individual and then he logs off, you shouldn't get stuck on a hump for days waiting for that individual to hook up again, should you? The program should just say, need more sources, not "Awaiting sources - queued - connecting - Awaiting sources" after you hit Resume.

What it should say is "Need more sources - searching - Need more sources", that's if it can't find that file on the network, not from the original source.

Or when you you go back to your computer the next day to see how your downloads are doing, if one of your downloads have stopped downloading the status pane should just be blank and that Resume button should say search when you click on the file you have partially downloaded that had stopped downloading.

Have you tried WinMX? I'm not saying it's better, but it will get results from multiple hosts for the same file even when one host disconnects you from their files, if that files available, it will pick up where the previous hosts left off and you'll continue to download.

I like Limewire, I think Limewire is one of the best P2P file sharing programs available, I just thought I would mention something that might make it even better.

I know if a file isn't available, well then, it isn't available, don't say I'm in queue and then put me back into the "Awaiting sources" limbo again, because searching and being in queue are two different things.

Lord of the Rings March 11th, 2005 03:47 AM

I don't know about WinMX b/c I use mac & there's no mac version of it. I use win LW purely for trouble-shooting. Sure some p2p apps (particularly those that use other nerdworks) are query frenzic! They send out query after query & repeat. But on the Gnutella network there's an agreement b/w the developers of the respectable p2p apps that they will develop their apps to run in a healthy manner on the network & not clog speeds due to traffic. ie: not sending out too many search queries. That's why it's very difficult to get earlier versions of LW, b/c to allow them to be still available would be irresponsible & not good for the network. There's some p2p apps out there who stick their thumbs (or finger) up at everybody & don't design responsible programs. So what would you prefer, a program that sends out query after query after query & wait half an hour or longer for it to finish & find your downlds suffer from heavy traffic speeds (which is what could potentially happen if the above isn't done), or would you prefer better downld speeds & accept a compromise in regards to finding sources. I'm sure the other members could word this better for they know a damned site more than me. By the way, I did use a mac program that works in a similar fashion to the other networks & this one also ran on another network.

gbildson March 11th, 2005 07:38 AM

Requerying every 10 minutes would destroy many positive features of the network. That type of activity would cause 90% or more of all query traffic to be requeries and reduce user initiated queries to 10% or less. Given that this would attempt to jam too many queries through the network, all queries would more quickly die off (from flow control) and the overall experience would get worse.

We have download meshes which connect sources for a file together directly. If new sources for the file become known, then these sources will show up in the download mesh and get propagated to new downloaders. This is a low cost way to get new sources other than through requerying.

If your download dies, it requires user intervention to restart. This is the best way to prevent excessive requerying. Any automated requerying is too much.

halo flow March 11th, 2005 08:21 AM

There should be an option to allow a third party app to scan downloaded files for viruses.

And please create a community-related interface (ex. soulseek).

gbildson March 11th, 2005 08:24 AM

Many virus checkers will detect that a file is being added to the disk and scan them without any integration. At least I see tat more and more.

massillonmarine March 13th, 2005 02:50 PM

Multiple Media Players
 
I was hoping we could have a way to pick what player is to be used on what file. In my instance if it doesn't work on WMP, I switch over to DivX to see if it plays. Also, maybe a person would have a 3rd media player. So I'm asking for a way to pick between as many as 3 media players to play a file.

Unreg4645uytg March 14th, 2005 01:18 AM

  • Ultrapeers should drop search results with -4 or worse rating on Bitzi, as determined by file hash.
  • There should be a way to rate files from right inside Limewire, right next to Block Host.
  • More general Bitzi integration?
  • Block host should (perhaps optionally) block every known source for a file, not just a random one of them.
  • Small files with only one source are harder to get than they probably should be. Shortest-job-first queueing might be nice. Also, files that can fit in a single network packet should be sent in lieu of busy signals or other just-as-big responses that just mean the file will be re-requested shortly.
  • It should be possible to save off a chunk of your pending-downloads list. It might be nice to have separate lists for results from separate searches, and to also have separate download directories for separate searches. Currently the only way to have that effect is to make multiple installs, one for each query, and switch among them. Nasty workaround, and a huge waste of disk space.
  • Distributed hashing?
  • BitTorrent capability? Large files you shared would automatically create and share a .torrent as well; compatible clients (i.e. with both gnutella and bittorrent capability) would display the two search results as one item and try to get the file from bittorrent.
  • Caching of small files on ultrapeers?
  • Cascading of small file downloads -- many jpegs on the same host tarred, sent as one transfer, and untarred transparently at the other end? Downside -- interrupted transfer might not be easily resumed, since only the exact same host is likely to have all of the same files.
  • Performance is (still) poor on 1.5GHz CPU, 1GB RAM, cable inet system.
  • What is with files of only 10-20K getting 3% done and then aborting spontaneously? Are there clients out there that can be put in a "leech without seeming to leech" mode in which they share thousands of files but cap uploads at 0.01kb/s and randomly drop connections? If so can these be punished somehow?
  • 4.8.1 exhibits frequent hangs. The UI won't redraw and there is 100% cpu use. Even if its priority is lowered and there's a lot of physical RAM free, other apps are slow and unresponsive. Left alone it eventually recovers, only to hang again some time later. 4.6 did not do this, but it did have some sluggishness issues all the same.
  • Duplicate file database. Every file that was downloaded successfully has its SHA1 added. Files with the same SHA1 are filtered from future search results. Downside: if you download a file and find it's been substituted with garbage (an ad, typically) you won't be able to try to get it again and hope to get the real McCoy. The file, when completely downloaded, must be rehashed and that hash put in the duplicate file database, so the original is still going to show up until you get it. This way you can also tell if the file has a misleading name or if the file should have been something else but a bad node substituted junk when you downloaded it.
  • Integrated previewer. Newly downloaded files are moved to a "New files" list for review. You preview them and can delete, move to library, etc. Turned off by default; advanced users can turn it on. When turned off, files are moved automatically, i.e. the current behavior.
  • Library organizer. Library tab should make it easy to create subfolders and move/rename files, to categorize stuff.
  • Any time a search turns up a file that is in your library, the search query is remembered in a database associated with that file, and Limewire will return that file as a hit for any search for that query done by someone else. When you first download the file, and it is moved to the library, the search query that led to your downloading the file is associated with it in this way, and others get added later on. (These same duplicate hits get weeded out of your search results.) Thus if your search for "trees" produced an opaquely-named file like "DSC00156.jpg" it will be returned by your machine as a hit for "trees". If you later search for "plants" and this same file (same SHA1) is a hit, you won't see the search result, but that file will now match both "trees" and "plants" when your node is searched.
  • More efficient sharing of a large library. Limewire gets slow and cranky with thousands of files shared, so how about having it share only one shared folder at a time, but change which one every so often; or making this an option. (A shared folder with only subdirectories won't count; one with files and subdirectories would have the files shared; the subdirectories would get rotated to eventually.)
  • Ultrapeers should not drop search results unless they are actually overloaded, no matter how many hits for one query there are. (How widely supported is OOB result returning now, anyway? There's really no need for results to be limited at all, or for them to go through the ultrapeers; they should be sent straight to the querying node, save if they must go through one intermediate host to get past firewalls, just like a download.)
  • Ultrapeers with dialup leaves should cache the smaller files on those leaves, and return (OOB) the cached copy of such a file as a hit where possible. This will take some of the burden off modem users, and make some of the files they host more consistently available. When a query matches a small (<500K) file on a modem leaf as determined by an ultrapeer, and that ultrapeer has cache space available, it should download the file itself, and pass on the file as it receives it to the requesting node. Subsequent requests for the file that reach that ultrapeer can return the cached file without the dialup host being bothered at all. The file expires eventually when not requested for more than some period of time.

Unregis8tered March 14th, 2005 02:00 AM

In the "Overwrite existing file" dialog, add options "Yes to all" and "No to all" in addition to "Yes" and "No".

Add checkbox "Don't show this again" to the startup dialog that tells you limewire pro exists.

Jijsdighdsop March 14th, 2005 05:04 PM

PLEASE- GET MORE PROGRAM's:
E.X.
ILLEGAL ACTIVITY
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Edited to comply with the House Rules.
Warez, copyright violation, or any other illegal activity may NOT be linked or expressed in any form.

xenophase March 14th, 2005 07:34 PM

It would be nice if a filter for minimum file sizes could be added, as that would allow the filtering of many bogus multimedia files under (example) 300 kb. I don't know the purpose of these files, but they pop up on nearly every search.

Unre3547468u March 14th, 2005 07:59 PM

Enable resume/find sources button with "Try Again" caption for files with the status es Complete and File Corrupt. In the latter case you want to reattempt getting it, preferably while the source is still online, and should not need to explicitly search for it. In the former case, the file might prove on examination to have been substituted with an ad or other junk, or otherwise damaged without the damage being detected resulting in File Corrupt status. In that case you want it to delete the file and attempt to get it again, but you might want to block the host that sent the bogus/substitute file so you have greater odds of getting the real McCoy next attempt. (There's some files I've been trying to get for ages that turn up frequently in search results but never seem to download right -- one I've gotten six or seven times and it's never shown a status of File Corrupt, but it's also been broken beyond use in every single instance!)

This brings me to another matter: finer grained detection of corruption. Really, each time a chunk of file arrives and the progress meter notches forward a bit, it should be possible to check that one chunk against some check bits tacked onto the end and rerequest just the one chunk if it's damaged. This will reduce accidental file corruption to nearly nil without having to reget entire files, only pieces. That leaves intentional corruption by hostile nodes that join the mesh for a file and send garbage or advertisements, corrupting and vandalizing the file. This is simple -- all files participating in a mesh need to have the same exact file, with the same SHA1. When downloading from a newly-discovered source begins, Limewire can request a random chunk of the file that it already has and compare it with the version it already has of that chunk. If the new chunk doesn't match and does have proper check bits, it's probably a hostile node trying to pollute the download, and should be dropped rather than downloaded from. Your node also won't refer other nodes to the hostile node. If it matches, it then requests chunks it does not have from that source in order to download part of the file from it. Downside is, if the first source to send any chunk of a file was hostile, it will download from only the bad actors! But at least the mesh for a file with bad nodes in it will get divided into two disjoint chunks, one sharing a bogus file and one the real file, and if you got the right one to begin with you will get the entire correct file and not a partially corrupt file.

This could also use Bitzi-like reputation management features, in which not only whole files but just chunks have reputations. The version of a chunk with majority representation in the mesh might rule; or volunteers can preview chunks (for some formats this should be possible) and vote them up/down.

Registered I am not March 15th, 2005 09:31 PM

When it comes to searching for music, there should be another search option for the decade that you are looking for. (e.g. 70's, 80's, 90's)

Boffo March 16th, 2005 09:18 PM

multiple playlists
 
It would be nice if you could have multiple playlists in the library like in kazaa, so if more than one person uses it, you don't have to sift through a massive list to find your favourite songs.

Thanks.

GooRoo March 21st, 2005 03:26 PM

Sort the "Blocked Hosts" list, or allow copy to clipboard,so that the list may be sorted there. Right now it is not possible to copy to the clipboard, which would be an interim solution to a problem.

larkspeed March 28th, 2005 07:29 AM

User definable connection speed

due to the fact that the given choices do not include anything that resembles my connection.

I am on 3mb Down and 364Kbs up

if I select any of the given choices I either end up seriously restricting my download speed from what it is capable of or choking my connection as to get decent down load the lowest I can possibly put the upload slider is still higher that the max my connection will allow.

yes I know there are unlimited settings but I like to hold back a certain amount of bandwidth so I can still surf and do other things on the net.

And since I share 35Gig+ of files in limewire and always leave it running yes this becomes a problem as there are always people getting stuff from me

The_Dodger March 28th, 2005 11:32 AM

Just a little tiny and probably amazingly easy feature request... this would cut down on the number of crap results of a search:

On start up generate a random 32 byte string (like MD5 encode the thread ID and systime or something). Do a search for it in the background. Automatically blacklist the IPs of anything that returns a result to that search. While running, preodically do this search again, and add any results to that blacklist. Optionally, also give the user the ability to add obviously BS results to this blacklist, and possibly even allow this blacklist to be auto-shared, so you can choose another user and import their blacklist if you want.

I'm hoping these features are significantly easier than what I really want, which are features that get you a beer whether there's any left or not, and make the cat not decide to take a really stinky crap every time you have a girl over. B^)

ElllisD April 3rd, 2005 06:04 AM

Hell, yeah!

Quote:

Originally posted by The_Dodger
Just a little tiny and probably amazingly easy feature request... this would cut down on the number of crap results of a search:

On start up generate a random 32 byte string (like MD5 encode the thread ID and systime or something). Do a search for it in the background. Automatically blacklist the IPs of anything that returns a result to that search. While running, preodically do this search again, and add any results to that blacklist. Optionally, also give the user the ability to add obviously BS results to this blacklist, and possibly even allow this blacklist to be auto-shared, so you can choose another user and import their blacklist if you want.

I'm hoping these features are significantly easier than what I really want, which are features that get you a beer whether there's any left or not, and make the cat not decide to take a really stinky crap every time you have a girl over. B^)


Night-Fire April 3rd, 2005 06:47 AM

Quote:

Originally posted by larkspeed
User definable connection speed

due to the fact that the given choices do not include anything that resembles my connection.

I am on 3mb Down and 364Kbs up

if I select any of the given choices I either end up seriously restricting my download speed from what it is capable of or choking my connection as to get decent down load the lowest I can possibly put the upload slider is still higher that the max my connection will allow.

yes I know there are unlimited settings but I like to hold back a certain amount of bandwidth so I can still surf and do other things on the net.

And since I share 35Gig+ of files in limewire and always leave it running yes this becomes a problem as there are always people getting stuff from me

yes i agree im going to finaly get broad band on monday the 4th (FINALY), and want to be able to throttle my Download & upload speeds so i may have a slight chance of playing the occasional Counter-Strike or H-L2 :P

Unre#5464 April 4th, 2005 01:52 AM

This is really a bug fix request. Two problems with the user interface are massive nuisances:
  • Making multiple selections is broken and has been for ages. Control and shift clicks are interpreted correctly much of the time, but a random fraction are treated as plain clicks, and clobber your elaborate half-built selection, which is evil and rude. Moreover, shift-clicks sometimes do not extend a range correctly. Clicking a file and then shift-clicking a file way below creates a range as expected (when it doesn't just change the selection to only the lower file; we'll assume it worked though) -- now if you shift-click the next file down, it will frequently leave you with just the bottom two files of the intended range selected, rather than everything from the first file clicked on to the final file. (Sometimes it will just select that last file, but again that's the shift key being ignored rather than incorrect range extension.) This is unfortunate, because needing to extend a range by one is very common and control-click is far more likely than shift-click to hit the "ignored modifier" bug. As for why needing to extend a range by one is very common:
  • Not only do the items move around constantly while trying to select from the list if there's a lot of activity happening, but the UI's response to your mouse clicks lags behind your input noticeably, and often enough for it to get the order of events wrong when the items shift. E.g. you click item A, shift click item C, and everything moves up one; but your shift-click is ignored until after the move, and you end up with A-D instead of A-C selected. If the shift-click happened before the move the consequences should be processed as occurring before the move goddammit.
  • Clicking of "resume" or "find sources" is sometimes, incorrectly, ignored. The item is not greyed, and animates sensibly, but nothing happens.
  • Recent versions of Limewire grey this button out sometimes. This makes sense for connecting and waiting in line, but I used to be able to select a download that had stalled and "resume" it; now it's necessary to make a larger selection that includes the download to prod a download into activity and even then it doesn't always work. Is it really intended that people no longer be able to resume stalled downloads unless they fail completely? Being able to prod a host that had apparently forgotten you were there with some kind of "keep alive" signal seems to be essential, since a download that slows down and stops is very likely to turn into a busy signal if you don't get it running again quickly, and since it is for some reason a very common occurrence for hosts to slow down sending a file to a trickle, and eventually stop altogether. (Often, when a host decides to start neglecting one of your downloads, the throughput starts dropping like a stone and reaches 0 without a single additional percentage point bein reached -- and usually the file will end up languishing as "busy" or "needs sources" for days, incomplete, if you don't get the rest of it straight away!) Maybe a better idea is to send a keepalive automatically if the throughput drops below, say, a quarter of the peak throughput observed for that file. So a file that has hovered around 3-4K/s that slows down will trigger an automatic keepalive signal (rerequesting the next chunk from the host? I don't know much about the details of the protocol I'm afraid) if it dips below 1K/s. Alternatively, send them if the throughput drops to a flat zero but not otherwise.
  • Related: stalled downloads waste a download slot at one end and an upload slot at the other end. Sometimes, if the download turns into a busy signal it will resume at a decent throughput almost immediately when it is reattempted. For these cases it would be nice to have a way to stop a download that doesn't remove it from the list entirely, but instead bumps it from "downloading" to "connecting" status. The original download connection is dropped and a new one is immediately started that attempts to resume a partial file, to the same host(s). This would be for if "keepalive" isn't prompting any response from the remote host. (All too common.)
  • Limewire developers can do little about most of the misbehaving clients that slow down and stop an upload and then let it languish, or suddenly interrupt one and send a busy signal, but they can do something about one such client: Limewire. Unfortunately, I frequently see this behavior from hosts identifying themselves as Limewires. Hosts that aren't misconfigured (exporting a 10.* or 192.168.* address) and with my own peer not firewalled, I might add.

The Black Flag April 4th, 2005 02:16 AM

Better detection of corrupt files. I often get files arriving that never generated the "Limewire has discovered a corruption in..." message, but which are nonfunctional -- images that won't render or render only partially, mp3z with distortion or which cut off, videos that won't work or only the audio works (ones in avi format seem to be especially prone to this, probably because errors completely destroy the ability to decompress any of an avi file, rather than just introducing distortion the way they usually do in mp3/mpeg format files).

On top of that, there are the substitutions -- files that aren't as advertised, such as deliberately-spoofed mp3z and jpegs whose content has been completely replaced with (rather than just painted over with) spam of some sort.

All of these have in common that the received file will have a different MD5 sum or SHA1 from the file that produced your search result. In principle, discovering that the file you got is either damaged or a fraud should be almost 100% accurate -- the odds of a hash collision being very remote. In practise, though I was sure Limewire uses SHA1 to detect these situations, it apparently doesn't because the majority of obviously corrupt/spoofed files do not get detected as corrupt at all -- perhaps one in eight get detected, if that.

(This is entirely separate from the issue of spoofed search results -- spoofed search results are easy to detect and avoid, since they always produce ridiculous numbers of supposed sources, claim to have a high speed connection and zillions of open upload slots, and the filename is just your query string, sometimes modified in one of a few ways (changing spaces to underscores, adding extra underscores, and changing capitalization, typicaly). Others have already suggested ways to exclude spoofed search results, by blocking all the hosts that respond to a random nonsensical query string automatically and rerunning on occasion since the b*stards seem to have several whole blocks of ip addresses sometimes. I'm talking about search results that are clearly genuine, but when downloaded, the downloaded file is either a) damaged, or b) a substitute. Killing that damned ipod spammer is going to take both solutions -- not only are a bunch of spoofed hits returned for every query with ipod spam, with this one spammer having several whole netblocks to judge by the hosts I've already identified and manually blocked, but the f*cker is also substituting his crap in responses to non-spoofed search results. I've gotten several valid search results I downloaded only to find that the ipod spammer had somehow intercepted the download request, I guess by participating in the file's mesh, and sent me his bullcrap. NOT ONE of these was discovered to be corrupt by Limewire, even though the ipod spam and the original, legitimate search result surely had different SHA1s. (The result was known to be legitimate in each of these cases due to having few sources, an honest Modem speed advertised, a queue, and the result's file name actually containing things besides underscores that weren't in my query string.))

Un345349ytd April 4th, 2005 02:29 AM

Another bug for ya -- searching for a specific file, I find that the search box malfunctions in a very specific way if you try to type in a query containing an underscore. The underscore doesn't appear and a noise is made. It almost looks as if it's being deliberately rejected; but that, of course, makes no sense as it's a common component of file names and therefore often needed to narrow down a query when a specific file is sought.

(The query language is also woefully simple -- it just seems to be an AND of the terms. Quoting a phrase will not result in an exact match being required, even -- the words in the phrase can still apparently match the query by occurring separately and in any order, and not just sequentially in the specified order. There's no OR facility, though you can kludge that by doing multiple searches. There's no apparent way to wild match "a single character or nothing" either -- it'd be nice if the query le?ann matched both leann and leeann and le*ann matched those and leighann as well, just as an example. Of course, with those and quoting, we'd need a way to match actual question marks, quote marks, and asterisks; say a backslash preceding any of those, or for a literal backslash, preceding a backslash. This would be nearly back-compatible since normal queries are just alphanumeric with some spaces anyway, but advanced users would be rewarded by the additional options when they had a tricky query.

A NOT function might be nice too, if most of the hits for something are turning out to be irrelevant. You can try to craft the query to reject the irrelevant results.

Anything that enables more narrowly targeted queries helps the network.

Google's search options should be your model here -- you can match on date or site (site is, admittedly, irrelevant here), as well as name and size, and the name can include exact phrases, "near", "not", and "or" words, and so forth. And this is without really getting into the "advanced search" options...

Limey_Addict April 13th, 2005 12:10 AM

VERY USEFUL FEATURE!
 
I think LimeWire should include an extractor - useful for when you are downloading .zip, .rar, etc. files, when they are done downloading, you are able to extract them to a folder on your computer using LimeWire :)

Night-Fire April 13th, 2005 01:41 AM

Yes Good idiea.. but you don't know how long it may take them to code it

ElllisD April 13th, 2005 01:39 PM

Re: VERY USEFUL FEATURE!
 
Quote:

Originally posted by Limey_Addict
I think LimeWire should include an extractor - useful for when you are downloading .zip, .rar, etc. files, when they are done downloading, you are able to extract them to a folder on your computer using LimeWire :)
I don't want to see that at all.
On my 700MHz machine, any task that takes cpu cycles away from LW causes transfers to crawl. LW uses enough cpu already.
Just because LW can transfer various filetypes does it mean it needs to work with them too?
I already think the mp3 player's useless. Most everyone already has one, & at least I always have mine playing in the background when I'm on the computer. When I preview an audio file, It's usually to see if it's been converted from say, 64 to 320, or from mp3 to flac anyway. If I play a track with LW, I'll wind up hearing both tracks at once & then I can't hear quality value.
Would you want LW's installer to get fat enough to include a text editor? A photo editor? An avi converter? No way.

gfox April 13th, 2005 08:31 PM

Re: Re: VERY USEFUL FEATURE!
 
Quote:

Originally posted by ElllisD
I don't want to see that at all.
On my 700MHz machine, any task that takes cpu cycles away from LW causes transfers to crawl. LW uses enough cpu already.
Just because LW can transfer various filetypes does it mean it needs to work with them too?
I already think the mp3 player's useless. Most everyone already has one, & at least I always have mine playing in the background when I'm on the computer. When I preview an audio file, It's usually to see if it's been converted from say, 64 to 320, or from mp3 to flac anyway. If I play a track with LW, I'll wind up hearing both tracks at once & then I can't hear quality value.
Would you want LW's installer to get fat enough to include a text editor? A photo editor? An avi converter? No way.

i agree, i dont want a swiss army knife. i have stuff it for that, and itunes for listening etc.

154654564 April 16th, 2005 07:57 AM

Is there an option on limewire that lets me sort my files by tittle. If not it would help a lot if there was such a thing its so hard keeping up with all the files because its not organized in any sort

GooRoo April 16th, 2005 04:25 PM

Quote:

Originally posted by 154654564
Is there an option on limewire that lets me sort my files by tittle. If not it would help a lot if there was such a thing its so hard keeping up with all the files because its not organized in any sort
For your own purposes (in LimeWire), it is only necessary to click on the 'filename' column, which will sort that column into ascending sequence. Click again, and it will go to descending sequence. Click yet again, and future entries will return to random sequence by entry time (or whatever other sort you choose).

You may also use your Windows (or Mac) options to sort your entire folder via (Windows) 'view'->by name.


All times are GMT -7. The time now is 10:45 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.
SEO by vBSEO 3.6.0 ©2011, Crawlability, Inc.

Copyright © 2020 Gnutella Forums.
All Rights Reserved.