Maximum - + Minimum file size filter
 

-Maximum - + Minimum file size filter-
i just saw a stupid file with the size of only 851,7KB calling up itself in every search, i would sure be nice to search/download files withouth clicking that file and get a virus on my pc!!!!

download albums
 

allow user to download entire albums easily (egon slsk where you can download containing folder

I'm not sure to what extent the LW devs can help with these problems with bugfixes/features/changes, but here goes.

My modus operandi when using Limewire is as follows: I share a select few files from one directory and download to another. I keep an Explorer window open to the download directory. Every so often I examine these and delete any bad/unacceptable files (spoofed, spam, damaged, or mislabeled and contains something horrible). Also, less often I move the files out and categorize them, adding some to the shared files, etc. -- and replace them with zero length files of the same name, so I'll get overwrite prompts for these files and not redownload ones I already have.

Here're the problems. First, the icons in results lists don't accurately reflect which files I already have. Files with a green check don't always produce an overwrite prompt (and in the new beta, sometimes produce neither an overwrite prompt nor the "this file is the same as..." one -- if the green check doesn't mean the file name exists in the download dir already, and doesn't even mean the file's content is duplicated elsewhere on your hard drive, then what the heck does it mean?) and files often show stars that are downloading or downloaded, or torn paper, or show four stars but don't download quickly or at all -- in general, the icon system is a mess and doesn't seem to be very accurate at all. Of course, to compound this the overwrite prompt does not have a "No to all" button...

Next problem is that deleting a spam or other bad file causes Explorer to hang the next time a file is downloaded. Also, the Windows picture previewer takes forever to preview files from the download directory. It sits at "generating preview..." for ages. The odd thing is, if I browse on inside the previewer, it takes almost no time "generating preview" for the subsequent images -- it's only the first one viewed that takes forever to generate a preview. It seems to me that this has gotten worse with time, as well. The only difference between that directory and others as far as statistics and permissions and such are concerned is that it has tens of thousands of files in it. The previewer's preview generation should scale with the size of the file, not the whole directory, however, and should be the same for every file previewed... Since these seem to be Exploder bugs I'm not sure what you can do about them, though perhaps someone knows of workarounds. Googling didn't turn up any. Disabling all non-MS shell extensions didn't fix the problems, nor did disabling the image capture service. (WinXP home SP2)

The ideal solution with Limewire would be to make the following additions/changes:

• You can designate directory trees for file matching that are not shared. This would obviate the need for the zero length files I use -- I could match against all my downloads without needing them and without sharing everything downloaded. Sharing everything downloaded caused huge performance problems, crashes etc. once the number of files got much above 10,000 back in the day -- even with only a few upload slots. Somehow shared files you weren't actively uploading contributed to memory/CPU use? It also stopped me deleting spam etc. and moving and categorizing files without exiting limewire first because the files would be "in use".
• The icons accurately reflect the file status. A four star result really is on a non-busy host with a good connection. A green checked file really does have the same MD5 sum as a file in the above proposed directory tree somewhere. And so on.
• Performance is improved all around. The new beta seems to perform much worse than 4.8.1, and apparently it's linked to how many files are in your download directory -- even if they aren't being shared. But I must have as many files in the download directory as I've ever downloaded, or else I won't be able to avoid downloading files I've already downloaded! You see my problem... A better way to reliably weed out files that match files (not necessarily shared) you already downloaded is needed, and it has to scale to hundreds of thousands of files, given that it's already tens of thousands and will only keep growing, especially as disks and computers get bigger.
• Performance of Limewire doesn't seem to improve by adding RAM to the machine. I've gone from 256MB to 512 and then 1GB on this machine over the past several years and every other performance-heavy app I use has shown big jumps in performance both times. Not Limewire. This is very peculiar.
• If you can, duplicate Explorer's previewing functionality in the Library tab and make the Library tab much saner in terms of performance. At a guess, it currently loads something into RAM for every file shared (whether currently uploading or not), every incomplete file (whether currently downloading or not), and every file in the download directory. This stuff should be accessed from a random access DB on disk, rather than data structures in memory, with the operating system's disk caching taking care of keeping frequently used records in the DB in RAM. This would vastly improve memory performance, which is currently horrible especially if you have numerous files in any one of those three categories. Also, duplicating Explorer's previewing functionality would obviate the need to have an Explorer window open on the download directory to view and, sometimes, move or delete new files -- hopefully avoiding the Explorer crash described above. (Which is really nasty by the way. The window locks hard and Explorer goes to 100% CPU use. On top of the high CPU use from Limewire. Which usually means Limewire hangs, half of everything else hangs, and the system direly needs a reboot. It's a struggle just to save everything you had unsaved changes in because of the CPU use!)

Hope someone can help here.

need undelete button
 

Hi I have 3 kids and they all use the computer and one day one of them deleted a movie file i waited for 3 days to download I can't find it anywhere it didn't go to the recycle bin as i expected and its gone lol

Re: Requeries and zero length files
 

Hi Mandelbrot,

Searching for File Hashes doesn't scale well in the current Gnutella Network, which means they waste lots of bandwidth for all Users.
(Check http://gnufu.net - Query Routing Protocol for more information )

To do this, LW would have to run two seperate networks: One for Hashes (with a completely different organisation) and one for normal searches (for which the current Gnutella Net is strongly optimized).

Well then implement that separate network. As things stand, requeries are nearly useless (and the recent betas only made them worse) and you often end up with most of the files you want languishing "awaiting sources" -- lots of them after downloading 50% and then deciding that the file no longer existed anywhere on the internet anymore. :P

for movies, i highly suggest using bittorrent. i really only consider using gnutella for files under 100MB. BUT the files that i do download from bittorrent i do share on the gnutella network. IMO this helps adds more content to the network.

Most of the files I'm downloading are under 100k. :P

Image dimensions should be one of the column choices for media searches -- and should replace the useless Bitrate column as the default rightmost column for image searches.

The ipod spams would be easier to avoid this way, since the jpegs are all the same dimensions. They come in several file sizes (anyone have a clue why?) and they don't ALWAYS seem to show huge numbers of sources, a T1 speed, and a name that contains all the query terms, in order, and no other words. They OFTEN do, but not always, not by a long shot. The wmvs are all soo small in file size to be legit, which makes those easy to avoid. The jpegs that do fit the pattern described above are equally easy to avoid. But the "stealth ipods", jpegs with a couple of modem and cable sources and a random name that isn't just your query string slightly modified, continue to be a massive nuisance -- especially because every time I delete some from my download directory, the next time Limewire successfully downloads a file Explorer wedges and I have to reboot.

Split the hosts filter to a seperate file…
 

…instead of sticking it in the middle of limewire.props as a line of text.

I'd like to be able to provide you folks with a half decent filter. Editing the limewire.props file works, but this is clearly beyond the abilities of the average user.

If I could just provide a standalone file with simple instructions on where to put it, a lot of people would enjoy the benefit of being able to block most of the spammers and hostiles out there.

See "The LimeWire Fullsize Hosts Filter!" for details on how to install and use it.

Alternate link (If the forum moves to it's new address before you see this): "The LimeWire Fullsize Hosts Filter!"

Split the hosts filter to a separate file…
 

…instead of sticking it in the middle of limewire.props as a line of text.

I'd like to be able to provide you folks with a half decent filter. Editing the limewire.props file works, but this is clearly beyond the abilities of the average user.

If I could just provide a standalone file with simple instructions on where to put it, a lot of people would enjoy the benefit of being able to block most of the spammers and hostiles out there.

See "The LimeWire Fullsize Hosts Filter!" for details on how to install and use it.

Alternate link (If the forum moves to it's new address before you see this): "The LimeWire Fullsize Hosts Filter!"

Re: Split the hosts filter to a separate file…
 

Won't work. I spent a couple months using "block host" on the fake ipod search results whenever I saw them. After that time I hadn't made a dent in how many of them showed up. Whoever's behind it has apparently got multiple host machines in multiple regions, each of them connected through an ordinary ISP, rather than using a central server farm on a commercial connection. The result being they come from a dozen or more machines each of which has a dynamic IP address in a different range from the others. Unless you block whole swaths of the Internet, you can't keep out the damn ipod spams. And to top it off, not only is it much harder to block because they are running their scam from a handful of ordinary office computers on ordinary home user broadband connections, it's probably also actually cheaper than if they had a "proper" commercial server farm and a "proper" commercial network connection with a stable IP for each machine, too. :P

RIAA snoops are also impossible to keep out. They'll all have connections at home with various IPs that change from time to time, and you can bet they'll use those or even resort to cyber cafe surfing if they can't get the goods on illegal sharers from their work connections.

Other spammers besides the ipod spammer don't even rely on spoofed search results but instead distribute mislabeled or mutilated files the ordinary way. There's no way even in principle to distinguish those from legitimate sharing, except file fingerprints, and Limewire doesn't have a way to block certain file fingerprints for some brainless reason, it can only block by host or by keywords in the file name.

Even the ipod spammer doesn't rely entirely upon spoofed search results. I avoid them -- they're really quite obvious -- but I still get the odd ipod JPEG that must have come from a seemingly "normal" search result and I still see (but avoid) the odd abnormally small WMV that doesn't have a zillion T1 sources and a filename identical to my search. Apparently there's a second method of dissemination, probably by simply configuring each of their machines to not only generate spoofed search results, but also to have a handful of spams that are shared "normally", i.e. they are simply given various names that will match popular searches and stuck in a shared folder.

And since the jpegs (unlike the wmvs) are a perfectly typical size for legitimate files of the same type, there's no way to avoid them, short of the brilliant suggestion someone posted earlier in this thread of showing dimensions instead of bitrate for the right hand column when doing an image search. All the ipod jpegs are the same odd size, 356x598. I've never seen an image that size that wasn't bogus. (Even file fingerprinting won't keep them out. There seem to be dozens of different versions with slightly different sizes and even sometimes different host names in the spam -- all no doubt aliases of the same server somewhere run by whatever fly-by-night somehow has the resources to operate physical assets in multiple cities. No doubt the multitude of variations is precisely to defeat attempts at filtering them out by hash. Unfortunately, this means they would probably start varying the image dimensions too if 356x598 jpegs started routinely being filtered out by the major p2p clients.)

Host filtering simply is not a viable solution to the problem of bad actors. Snoops can only be dealt with by some sort of secure anonymization scheme. I don't see that coming to gnutella anytime soon. If you want that use freenet or something -- it actually doesn't perform any worse than limewire. They're both huge bloated java apps that consume hundreds of megs of ram and are sluggish and semi-broken. :) Bad actors whose misbehavior is in what they try to push on you rather than what they try to catch you doing are a simpler matter. Their bogus files are as easy to vary as their IP addresses, however, so the only ultimate solution is better Bitzi integration. We need to be able to preview media files of all kinds (not just music) inside Limewire and right from in the previewer, delete and vote down files we consider to have been misleading. Not go to some slow and cranky Web site to do so, or to check whether a search result is ok. Nobody is going to do the Bitzi lookup menu thing for every single search result before downloading it -- not when every such lookup involves a sluggish web browser startup (during which LW doesn't respond) and then a slow page load, usually resulting in a "Bitzi fingerprint unknown" at the end, along with the usual assortment of annoying flashing banners and popups that were the chief culprit in making the whole process so slow and are utterly pointless since everybody completely ignores such trash now anyway. The rating should be indicated as part of the result quality. In fact, as far as I can tell the current result quality indicators are meaningless and can go to hell anyway. I've seen four star results languish forever in queue or "awaiting sources", had a whole bunch of intriguing one star results download in seconds so rapidly that Explorer crashed trying to redraw the download folder's window while it was in the middle of redrawing already, and the "new" icons? Forgeddaboudit. If I select a bunch of files and hit Download, limewire's UI freezes for a bit and when it recovers, half of them are now folder icons, half are still stars, and half are torn paper. All of the latter two category are sitting, intact, in my download folder (yes I have broadband), so where are the green checks? Green checks meanwhile frequently appear beside files I not only don't have, but have never heard of, and turn out upon downloading not to be duplicates under unfamiliar names either. Torn paper appears beside files that were corrupt, files that downloaded successfully, files I just plain don't have, and files that are in progress. Folders are likewise inaccurate -- maybe half are files downloading or queued; the others are files I already successfully downloaded but whose icons didnt change to green checks. And if anything the recent beta makes them even more inaccurate. If they can't be gotten right, best to trash the whole lot and replace them with Bitzi rating information. I suggest a faux-digital-readout bar as long as the current four-star icon, dark red at the left end, through yellow to dark green at the right, and the bars light up from left to right based on the file's rating. If it's deeply in the red it's probably bad as it's had a lot of negative votes. If it's well into the green, it's probably good. A ? icon can appear for files with an "unknown bitprint". And you can be encouraged to download the file and then rate it from the previewer I suggested above, so that when the spammers change their files to try to evade filtering, the new version of their spew has a strongly negative rating instead of a ? in a matter of hours. (Actually, it's likely to start out with a small positive rating. You don't think they won't try to stuff the ballot box do you? But there's only a few of them, and many of us, and even if they have access to a shockingly large number of unique IPs, we have access to ALL OF THEM and can therefore still outvote them. Unless they subscribe an account at every ISP in the world and hook up one computer to each, which would surely bankrupt them, their votes can never outshout ours as long as we can make ours quickly and easily the moment we are pleased -- or displeased -- with a file. And if they have the resources to actually operate a branch spamming office in every city in the world, each with a dozen or so PCs, one for each local provider, then we're screwed any way you slice it, since they're obviously the government or the Illuminati or the aliens from War of the Worlds or something of the sort.)

Re: Split the hosts filter to a separate file…
 

Wrong and wrong again. Neither of those links works. The first one just spins "looking up host" and the second goes to some full-page ad, which I assume is not what is supposed to be there.

You did remember to wait until after your site was up at the new url before taking the copy at the old one down, right?

Right?

Time to lock this thread
 

Time to lock this thread O Moderator -- it's the end of the line anyway. This just in from the changelog: future released versions of Limewire will nag you for every file you click to download that doesn't have some kind of TPM in it, like a WMV or itunes file does, or some other sort of accompanying license info.

In other words, for all the files you download, save maybe one in a million, and, in particular, for any media file that might actually work in an open source media player.

I saw this mentioned somewhere else and didn't believe they'd sell out and do this to us. Then I checked their feature history page. It's true -- every word of it. They are shoving itunes and windows media down our throats. Linux and FreeBSD users can take a hike, or put up with endless nagging, or download files they can't use -- their choice. Anyone who downloads nearly anything in fact can apparently go hang.

So much for Limewire. It was nice while it lasted.

I wonder how long it will be before the flood of posts hits from pro users demanding their money back? I wavered myself, but now I'm extraordinarily glad I never plunked down hard earned money for what's now clearly about to become horribly crippled to serve the needs of some legal eagle who wouldn't know "usability" if the entire membership of the Nielsen-Norman Group sat on him simultaneously and is far more concerned about avoiding an RIAA lawsuit than he is with the company actually continuing to make so much as a dime.

The only feature request that now seems sensible to make is "Add a button to the Limewire Pro startup screen that says 'Uninstall and mail me a cheque'. And that actually works."

And since I just made it, that may as well be the end of this thread -- it's certainly the end of its usefulness.

So long.

hehe--it only shows once (unless you want it to show every time), and is a good idea.

I'd like the copyright cartels to set up a database of their files, somewhat like the Bitzi lookup. They don't deserve the free publicity and benefits of having their files popularized.

Nice move LW--this should help the Boycott RIAA folks. Perhaps the dialog could also add a link to the Boycott RIAA page, or any other group protesting the copyright cartel's tactics, and get the word out more effectively to the millions.

Oh--could you make the checkbox so that the warning dialog is only forgotten each session? I would like to be reminded once per session to avoid any cartel crap.

Re: Time to lock this thread
 

Or maybe not.

I guess they changed it. Since they didn't change the version number, my guess is this thing could be turned off all along but they didn't originally say so for some reason. And, not reassured that they couldn't avoid repeated prompts, some people didn't try the beta but did alert other people to the problem they perceived existed.

(I assume if they had tried the beta they'd have found out it could be made to not nag you, so they wouldn't have posted a warning about it. Since they did, they evidently didn't try the beta. As for why they didn't try the beta, they probably didn't dare, because if it couldn't be made to not nag them they'd have to go back to an older version. Going back to an older version, for those who don't know, loses your incomplete downloads and other settings -- perhaps if it didn't, people would have tried the beta despite the changelog suggesting they'd end up nagged into going back to 4.8.1? Also, weren't there earlier betas? You can still download 4.8.1, but if someone had 4.9.0 and wanted to go back to that rather than 4.8.1 after trying 4.9.2 they'd be SOL.)

Let's hope there are no more misunderstandings of this magnitude. I saw a post the other day complaining of a changelog not having been updated -- perhaps this is a symptom of it having been a rush job when it eventually was updated ... but a stitch in time saves nine, and that rush job might have cost more time than it saved in putting out some kind of political brushfire.

Re: Split the hosts filter to a separate file…
 

Thanks--I like the idea.

Perhaps rather than only blocking, the hostilefile could optionally be used to flag hosts/results with a different colour? Like amber, for a warning light, say.

(btw--your links are still working)

Import/Export
 

I'm going thru the pain staking task of searching for any filesizes of 399.0, 765.5, & 851.7 KB. As I come across new filenames I add them to the Keyword Filter. I'd like to be able to import & export (.txt files) to keywords & Host IPs under Tools/Options/Filter setup screen.

As the HOST IP and Keyword lists become larger it's harder to manage. To address I'd like to be able to 1. see more of the data on the screen to scroll thru and 2. I'd like to be able to sort the lists.

Thanks, Rick

Pointless. Better Bitzi integration is what we need, not more and more manual filtering on filenames and hosts. The spammers keep moving hosts and they keep changing their filenames. They even keep changing the files, so they come in different sizes and such. The only reason they stick to 356x598 image dimensions is because nobody as yet has the capability to filter on image dimensions. Once they do, the spammers will start varying that, too.

In fact, they will keep dodging every filtering method and forcing you to run a treadmill of keeping your filtering up to date. That is why the filtering has to use file hashes, and why the process of flagging a file as bad, disseminating this information, and generally staying up to date has to be integrated as smoothly as possible and made as automatic as possible, while still resistant to spoofing attacks.

Any filtering method not based on file hashes will cause false positives. As time passes and the number of names, hosts, etc. they've moved to has grown the proportion of false positives would get worse and worse. But the file hash of a spam is still the file hash of a spam, even if the spams they're sending now have different hashes. It'll be a very long time before the first legitimate file turns up that has a hash identical to one previously seen on a spam. Hashes can therefore pretty much eliminate false positives, and they're already used throughout the network anyway, so they are the ideal filter criterion. There is even already a way to rate them -- Bitzi. The problem is that as of yet it is too hard to use effectively -- you have to surf to some web site, look up your search results manually, and probably register and sign up for a load of spam to actually vote on files and not just use the ratings. Spam, of course, being precisely what we are all trying to AVOID here.

Voting especially must be made easier. We need a preview feature that works for non-music media files and lets you delete files, delete-and-vote-bad files, and start-sharing-and-vote-good files you've downloaded. We also need to be able to vote files good without automatically sharing them, at least so long as Limewire continues to scale really poorly to sharing large numbers of files. (500 -- ok. 1000 -- sluggish and unresponsive. 2000 -- it starts crashing. 10000 -- it basically no longer works.) As for looking up files -- the search results should show ratings by each file in some graphical format. The current equvialent is to right click every file in turn, hit "Bitzi lookup", and wait for a browser to spend ages (during which your whole system is unresponsive) starting up and more ages loading a slow, gratuitously graphics-encrufted Web page. Once for EACH RESULT, mind you. That is simply unacceptable. Nobody will bother. It takes less time to just view the files and delete the bad ones in Explorer -- or rather it would, save for the niggling problem that if you delete anything from Limewire's download directory, the next time it gets a file Explorer locks up solid with 100% cpu use and makes you reboot. Microsoft's fault, of course, rather than Limewire's, but it makes it just as slow to weed out bad files by testing and deleting as it does to weed them out before downloading them using the Bitzi lookup. Which means the Bitzi lookup is just too damn slow and manual. The rating info needs to be fetched for each file automatically and displayed to the left, replacing the current worthless crop of "quality" indicators, whose uselessness was driven home by the large series of sequentially-numbered interesting four-star results I saw earlier this evening, not one of which downloaded. All went to "need more sources" nearly immediately. Requerying them didn't result in anything but a five minute wait, then "awaiting sources". Four stars means about as much as a politician's campaign promises, as near as I can tell; possibly slightly less. Every other icon there is equally useless. Green checks mean you have the file, or a different file with the same content, or no file like it at all. At best they are probabilistic indications that you already have the file. Yellow folders mean you have the file, or it's downloading. Torn paper means you have the file, don't have the file, the file is downloading, the file was corrupt, or the file started downloading and then got interrupted - - i.e. that particular one doesn't tell you a damn thing. And any number of stars means you have the file, the file's downloading, you don't have the file but should be able to get it quickly (even one star), you don't have the file and shouldn't hold your breath (even four stars), etc. etc. you get the picture. Every revision to the system has left it at least as broken as before, despite frequent claims that "THIS time for SURE!"; it increasingly looks like it is not actually technially possible to make the things reliable, and any further attempts are doomed to the same sorts of failures we've seen in the past. So let's replace them with bitzi lookup info. That should be technically feasible and actually very useful.

But the most critical thing is to make participating in rating files easier. Make it possible from within Limewire, along with deleting/organizing/deciding whether to share new arrivals. Only if it's sufficiently easy will votes by legitimate people be sure to outshout the spurious votes the spammers put into the ballot box. Although they don't seem to as yet, they will once filtering by bitzi lookup is easy enough it's routinely done by everyone. And then the lookup results will become worthless unless actually voting becomes correspondingly easier for everyone.

In the meantime, here's a proposed fix for the limewire scaling problem with sharing big numbers of files (present since at least 3.something). A file with a huge number of sources elsewhere on the network doesn't need your help. Limewire can detect this through the mesh, I believe, and if so, it can, each session, share only those "shared" files that are sufficiently rare -- say the 500 rarest, in terms of the number of other hosts online sharing each file. If there's under 500 files, it shares them all. If there's over 500 files that don't exist anywhere else on the network, it picks 500 of these and rotates each session, so as to eventually cover them all. Or even rotates every hour or something.

Change the bouncing back and forth pseudo progress meter behind "loading old downloads" to a real progress meter. It just goes by number of files loaded vs. total number in list. On my computer at least it's fairly slow to do that, and an actual idea of how fast it's going and how soon it will finish would be nice. Not everyone has a quad opteron with a 500MHz bus you know. :)

Re: Re: Split the hosts filter to a separate file…
 

Apparently you haven't looked at it very closely. There are almost 175,000 IP addresses and ranges in there, and the many lists I use are updated very frequently. You may get one or two of the most sophisticated spammers sneaking through but the vast majority of spammers and hostiles are stopped cold.

Re: Re: Split the hosts filter to a separate file…
 

Try again: http://www.technutopia.com/forum/showthread.php?t=324

Blocking out tens of thousands of commercial ranges goes a long way towards cutting spam down to reasonable levels, and blocking tens of thousands more of their residential (static and dynamic) addresses every week or so keeps them from making that approach profitable too. Of course, this filter works better and better with each additional ultrapeer that loads and uses it.

Each person that uses one enjoys a greater degree of freedom from spammers, fake files and even trojans, saving them a lot of time and frustration. More importantly, this large list effectively shuts out all of the huge server farms, saving the individual user a lot of wasted bandwidth.

BearShare has 160 of the worst bandwidth abusers blocked by default where LimeWire has precisely zero. I just might throw together such a short list and submit it to the developers to include with all future releases, since the biggest offenders rarely move their massive farms to new addresses.

Hosts filters are not the total solution to wasted bandwidth and spam but you haven't even started solving the problem until you do this first vital step. Once you knock off +90% of them, you can concentrate on the rest more effectively.

Keep an eye out for more of these filters. I expire and replace them frequently to stay ahead of these critters. They are named like "LimeWire.fullsize.hostiles.list.-.July.12.2005.-.(DELETE..ALL..PREVIOUS..LISTS!!!).zip" and always have a date on them. Search for zips named "Fullsize hostiles list" to find them. There are versions for BearShare and Shareaza too, and I'll add more servents as I learn how to accomodate them.

Remember, keyword filters are easy to sneak around with a little stroking of the keyboard but avoiding host filters takes a lot more intelligence, effort, time and money and spammers are notoriously stupid, lazy, impatient and cheap. :D

Re: Re: Split the hosts filter to a separate file…
 

As far as I'm concerned they are perfectly welcome to snoop to their hearts content, as long as they don't waste network resources to do so. I have no intention to track down individual nodes which perform that perfectly acceptable and legal task.

I don't share anything I don't have permission for and I advise everybody to avoid sharing huge collections in any case. This sharing network is far better served by the few who share original content than by the many who have huge collections of the same old commercial product as hundreds or thousands of others.

Re: Re: Re: Split the hosts filter to a separate file…
 

There's no way to "look at it" at all, apparently, save downloading a rather large zip file. Is the content even human-readable?

And the vast majority of legitimate sharers, no doubt. Most of those address ranges have probably got 1 spammer and 255 legitimate users sharing a dynamically-allocated pool of addresses. The spammers are unfortunately too clever to use static IPs on normal commercial accounts -- too easy to filter them there.

Re: Re: Re: Split the hosts filter to a separate file…
 

The vast majority of maybe half a dozen professional spammers on Gnutella?? I don't think so. Anyway, there will be a proper spam filter for LimeWire in the not so distant future, one that works similar to those eMail filters.

Re: Re: Re: Re: Split the hosts filter to a separate file…
 

Obviously you haven't looked, or even thought about it much. Yes, it is readable, and if you download the BearShare version it it even more so. The ranges are commercial rack space and the individual addresses are on dynamically allocated ranges.

Don't assume too much cleverness on the part of spammers. They are into this business because they are lazy. The vast majority of them still park their P2P nodes with their websites on their commercial accounts.

You also apparently think this list is static, and haven't noticed that I have been releasing the BearShare version frequently. This is just the first LimeWire release.

This list is much more than antispam protection. Blocking all possible commercial rack space effectively blocks all the giant bandwidth wasters that spoof the network with fake files and troll the network for other commercial purposes like marketing.

Also, let's not forget those waves of trojans and those massive fake farms that spread themselves out into dynamic address spaces too. Frequent updates tend to hold them back too, but if you want 100% protection uninstall LimeWire and you should be "safe". For the rest of us, having this list block over 95% of the parasites that burden the network actually improves our experience. :rolleyes:

Anyway, I have been using this thing on BearShare constantly for over a year now and I don't see it blocking thousands upon thousands of legitimate users. In fact, I don't see it blocking any of them. Even though LimeWire cloaks most of the actual online activity, BearShare doesn't, and I see what happens to each and every source in realtime. Remember, the odds on the dynamic IP address of a spammer or hostile going to an innocent internet account are already low in most areas (few are so saturated), and the odds of one actually going to a legit P2P user on gnutella are roughly 1 in 2000 at the very worst. The fact that this list is updated every 1-2 weeks [from sources that are updated as frequently as daily] effectively rules out that minute possibility altogether because even the one or two individuals accidentally blocked won't be blocked long enough for even them to notice.

Re: Re: Re: Re: Split the hosts filter to a separate file…
 

This list does a lot more than block the vast majority of spam. That's the least of it's effects. Try to download some fake files and see what happens. Pretty slow eh? Plenty of time to check Bitzi before you waste much bandwidth. :D


Even that half dozen "Pro" spammers of yours would be out of luck if everybody had the short list that all BearShare nodes have by default. Have you ever wondered why all of them use LimeWire? It isn't just that they could hack LimeWire. :p

Anyway, this is a features request thread, not a forum of it's own.
If you want to continue talking about blocking the bad guys for good (or not), do it here:
The LimeWire Fullsize Hostiles List.

Not every 356x598 jpeg is bogus. I just saw a legitimate one -- a picture of Leah Remini. 356x598, 44.0KB, looks a lot like the ipod spams from those numbers but it's legit!

burning cds as audio also
 

i would like to be able to burn cds on llime wirs library instead of draging it to windows media, or roxio or any other device that your able to burn cds, (audio, mp3s etc.)Now that would be even faster to make your cds and youll be able to keep searching whatever it is that your searching for.

Burning CDs while running something CPU-intensive is likely to result in coasters. Limewire is very CPU-intensive.

Here's a feature request: Limewire doesn't write unmovable files.

Every batch of downloads seems to contain a subset that Explorer won't let me move or organize -- trying to produces a message saying the file name is "too long or invalid", which is nonsense since if the file name was really too long or invalid it couldn't have ended up with that name in the first place -- Limewire would have been unable to save the file with that name in the first place.

Nonetheless, there's something Explorer (but not the underlying filesystem) finds objectionable about a certain percentage of Limewire-originated files -- and no other files. I've never seen this happen with a file created by myself, installed from a disk, or downloaded via anything else -- only with files downloaded via Limewire.

Whatever it is, presumably Limewire is responsible. (Odd file permissions? Something of the sort?) And therefore, presumably a future version can avoid doing it. Files downloaded in the Firefox Web browser never exhibit this problem, so it's clearly possible to make an application that downloads files and avoids leaving them in a state where they can't be moved.

The funny thing is that renaming them in Explorer does make the files movable. It seems there's some weird length limit that applies to moving files but not to creating them in the first place, not that that makes any sense, but since when does anything that came from Microsoft make sense? If that is indeed the case, the solution is just to truncate names at, say, 60 characters -- all the files exhibiting the problem have had names considerably longer than that. (It still begs the question of why the OS would permit the files to be given such a name in the first place but then refuse to allow them to be moved...)

There's indeed a path length limit (MAX_PATH C macro, on most modern systems 1024 byte/char).

That doesn't explain why the length limit stops a file that exceeds it being moved, but doesn't stop the file being created with the long name in the first place -- shouldn't Limewire get an exception thrown or something?

The JVM throws on Mac OS X a "FileNotFoundException: <very long path> (File name too long)" exception. The Finder on the other hand seems to use relative paths in one direction (I can create paths beyond 1024 byte and I can copy files into such directories) but as soon as I try to copy/move a File back to the Desktop it refuses the operation (i.e. relative destination path and absolute source path).

Btw, MAX_PATH is 260 chars on Windows XP (modern system -- so much for that). Check if your file's path is >=260 chars...!?

A more advanced Magnet "creator".

So I can set like fallback URL (&xs=http://server.to/file.zip),
define a download name (&dn=What+ever+I+want.smile),

...and so one...

Would be REALL neat if LimeWire could add urn:kzhash in addition to urn:sha1...

Make UI more responsive
 

Limewire currently hangs a lot. It recovers -- usually -- but frequently the UI completely stops responding, sometimes for minutes at a time.

When a file completes downloading or if you select some downloads and cancel them or "clear inactive" downloads, Limewire hangs with 100% CPU use, often for a substantial amount of time and interfering with using other applications on your computer with the excessive CPU use. Clearing inactive downloads makes it hang potentially for half an hour or more -- but it slows down and becomes unstable if you don't every so often, so you're stuck between a rock and a hard place there.

SOMETIMES when you launch a search or change tabs in the search area, but not always, it hangs for about half a minute with zero CPU use. This seems to be a different type of hang. I think this hang is caused by the displaying of a new/different search tab causing it to "think" an inordinate amount and in the main event handling thread to boot -- but since there's no cpu use, it looks like it's blocking on I/O or something in this case. The other, more severe hangs seem caused by the removal, either via completion or cancellation, of items from the download list. It seems to last a time proportional to the number of items removed. In this case it's apparently pure number crunching in the main event handling thread, rather than waiting for some disk or network event in that thread.

Slow sort algorithms perhaps?

Here's a feature request for you: please remove the popup from the Limewire Web site and promise not to try to spam me, or anyone else, again.

Thank God I never go anywhere with IE but Winblows Update, and use Firefox for everything else...

Seeing as there is no popup on our website, I would have to presume that you have some form of spyware or bundled software running on your computer. They like to pop ads when they detect a browser navigation to sites like ours.

Impossible. I scan religiously with both Ad-Aware and Spybot S&D. Plus, I haven't installed anything in the last 48 hours and I didn't get a popup block notification then when browsing your site.

I have Limewire PRO 4.8.1 and theres this annoying problem that happens randomly. Like if i play a song, about 5 seconds in the song stops. Could u maybe fix this glitch.

I can understand if you cannot fix this but is there a slight change of you to have a AntiVirus scanner to scan the whole network (which I know is a LOT!!!) or maybe part of it and automatically delete infected files. This would be a BIG plus but I can understand if this is too much.

They definitely can't scan for and delete files on any criterion. If they could, they'd be forced to use it on mp3s by the RIAA and such, and the network would generally be susceptible to coercive censorship, something it was designed to resist.

OTOH, they could make file Bitzi ratings, or detected virus signatures, or similar information visible in the UI in the search results and let users decide whether or not to download the file...

this bug happens to me all the time too... im just waiting for a better mp3/m4a player.

Is it possible for limewire to search for sources while downloading?
It really annoying that it cant do this, as it says "Awaiting Sources" and i know that there are plently of sources still....

We could but then we would overload the network with searches and no search by the user would ever work. Message traffic from all the searches would be exponential based on the number of users.

Thus, we require users to take action if they want to generate a search. If you do search then you will pick up new sources.

Automated queries or requeries have and would again blow up the network. Nice in theory. Very bad in practice.

Ah i see. Well thank you for your quick reply :-)

Re: Feature Requests
 

Re: Re: Feature Requests
 

It would be great if there was a way to print the playlist or the download request file

In addition to the following request:

- Browse host to display results with directory structure like in the library

I'd like to see directory/folder as one of the search items (in addition to images, music, documents, etc).

Further, some additional advanced search capabilities such as:

- max and min file size
- max number of words in a filename
- exclude words.

In fact just implement BearShare's search filtering capabilities.. :)

This would greatly help filter out all the spam crap.