Gnutella Forums - Corrupt images.

I mainly download images with Limewire. Since updating to version 4.0.6 I've had increasingly severe problems with corrupt images.

What has changed: Instead of getting the occasional file damaged in transit, now frequently if I go to download a bunch of related images, some will arrive normal but a sizable fraction, sometimes even almost all of them, will instead arrive as often-truncated copies of a single image promoting some "Sara18" site. By which I mean, there's an image of a semi-naked woman with text promoting a Sara18 site and either it, or a version of it that breaks up into colored rectangles or chanegs to grey partway down (typical of a jpeg format image that's cut short in transit), gets substituted for the file I selected to download. Note that this only began to happen after I switched to 4.0.6.

But it varies in severity over time in a seemingly-random way and this is superimposed on a gradual worsening trend, which makes me suspect it's not the 4.0.6 download code that's broken, but the upload code. Over time, the mix of clients connected to the network varies, including the proportion of 4.0.6s. On the other hand as more Limewire users adopt the 4.0.6 upgrade this proportion increases on average over time. This fits with the problem appearing shortly after 4.0.6 did, worsening rapidly at first, and now worsening more slowly, with fluctuations.

In addition, I'm seeing way more downloads that change into busy signals when only half-finished, way more partial files that don't resume at all, and way more corrupt and damaged files in general, although the effects seem confined mainly to images. Video and audio files seem to be damaged at no greater rate than prior to the appearance of LW 4.0.6 on the net.

The obvious thing to suspect at first would be that some spammer type got online, made that sara18 site, and is flooding the network with bad images under enticing filenames. But that fails to explain all the other broken, interrupted, and damaged downloads without substituted content being on the rise. It also doesn't explain why a single batch of search results, all obviously related and all appearing consecutively and showing the same speed and quality, suggesting they're from the same host, would come in as a mixture of intact images with the correct subject matter, damaged images with the correct subject matter, and (usually damaged) Sara18 images. One particular group of three files all downloaded concurrently and all were purportedly of the same subject matter. Two of them appeared as what I expected, but the third was a truncated Sara18 image!

Accompanying this shockingly abrupt downturn in the quality and intactness of my downloads is a rise in other disturbing and strange events too -- downloads that show a blank vendor/version, images that Windows Explorer refuses to preview at all saying simply "drawing failed" and giving no more detailed or informative explanation, and downloads that continue after reaching 100%, sometimes reaching as hgih as 178% and especially likely to be damaged, substituted with Sara18, or both.

My questions are:

What do I do to return to the user experience I was having just before updating to 4.0.6? If, as I suspect, it's the upload code that's causing the problems, going back to 4.0.5 myself won't help (much); everyone else using 4.0.6 would have to do likewise!
Therefore I must do something different -- filter anything from 4.0.6 sources? What? I have a right to know, since I have a right to continue to enjoy the same user experience I had a couple weeks ago before this sudden decline in its quality started. I have not done anything wrong, and therefore I expect not to be punished. Having been punished I expect that once I call attention to the fact that I should not be experiencing this new unpleasantness having done nothing to bring it down on myself, the problem will go away or I'll be informed how to make it go away. So someone -- please inform me!

Also, what can I do to prevent similar things from happening in the future? I want the proportion of damaged or incorrect-content files I observe to drop back to the level it had before, if not further, and I want it to STAY that low, or even keep decreasing, and never to increase. What must I do to accomplish that goal? Keep in mind that this is MY software on MY computer so I damn well BETTER be able to control the quality of user experience it gives me in such a fashion!

Lastly, when is the performance/stability bug someone was ranting about on the windows support forum going to be fixed? I use XP too, and I notice it too. If I share 1000 files Limewire 4 is reasonably stable and well-behaved; if I share 10,000 it becomes very unstable and basically the same symptoms occur that that poor fella was complaining about: spurious out of memory errors, LW refusing to resume old downloads on session start, network hiccups, dropped connections, excessive CPU use, even the same weird it-spawns-loads-of-threads thing he mentioned, now that I know what to look for in task manager. The curious thing is that the process size can get huge -- well over 120 megs -- without problems if I share 1000 files, but LW starts becoming very cranky and unstable at 100 megs process size and complains of low memory if I share 10,000. Apparently, if I share 10,000, it thinks I have a lot less memory in the machine than if I share 1000 since the same process size makes it complain of low memory only in the latter case. Are the files it's sharing adding to memory use but not appearing as part of the Limewire process size? The "Commit Charge" can be very low compared to my installed RAM (over 1GB) and it can still complain of low memory, but only with huge numbers of shared files, which suggests that sharing more files adds to a hidden memory use that doesn't show in the Limewire process' virtual memory size or even in the commit charge! Any gurus have any clues about this odd behavior? Is "out of memory" being used as a catchall for "can't happen" errors in the programming code perhaps? It seems unlikely that they genuinely indicate failed allocations on a multi-gigabyte machine with a commit charge in the 6-700 meg range.