With stderr captured, I've noticed huge numbers of "CancelledKeyException" messages that started when I installed beta 4.9.0, and persisted with the update to 4.9.1. Is this normal or a sign of problems with the beta? Should I go back to 4.8.1?

The snapshot below shows the chunk count. After re-opening LW it verifies the file & then a corrupt messag asking whether to continue. It happened a little too fast for me to get the chunk count the 2nd time. Once the message window comes up & press yes, it drops off the downld window list.

BTW the 2nd example I gave earlier with the disk error was a different type of error to the others (& I cancelled it off the list.) The others have been identical in their behaviour. I had also earlier disabled sharing from finished downld Files.

Attached Thumbnails

 

Lord Of The Rings...
I've only seen this for very fast downloads (>1MB/s). Was anything putting any heavier load on your hard drive while you were downloading?

Beta 4.9.1 just locked up. Zero cpu use at normal priority, and nothing is preempting it. The UI is dead. There's a console open and the odd IO exception message appears, but there's no functioning user interface and, apparently, no network activity.

All I did was start it up, sort the downloads by Status, select the final queued item, and then surf elsewhere; when I came back to it it was like this.

What gives?

The LW UI going dead is not unusual; its going dead without 100% CPU activity is.

Here's a simpler way to improve search results at the ultrapeer level. Just make it prefer dropping sources for files with many sources in the results to dropping the only source for a file in the results. So if it would produce

63 foo.mp3
22 bar.mp3
1 baz.mp3

it should start by dropping some of the foo.mp3 results, and avoid dropping the sole baz.mp3 result.

The spoofed results come in big batches (40+) so they'll tend to be sacrificed first on the altar of bandwidth. And a legit file with many sources will have an active mesh. Even if a given client only gets told of one of the sources because all the others get dropped along the way, from that one source it should learn of the others anyway, if an attempt is made to get that particular file.

I was also downlding other material at high speeds (total of 27 KB/s on a 256 kbps service.) I haven't used video processing over the past 4 days whilst this was happening. I have had other graphic manipulation programs running but they arguably don't demand that much of the cpu, or HDD. The corruption has occured to both (2x) dmg's & (3x) mp3's including 2 smallish (5-10 MB mp3 file.) I don't normally get corrupt downlds. And for this to happen over just 3-4 days it's a concern, but might just be the particular selected files.

re: the one file that came up with a disk error within LW. Not sure whether that was me or them at fault. Doesn't sound healthy. Certainly hope my HDD wasn't at fault. My graphic programs do use scratch disks allocated to various partitions. But for graphic man. the one LW downlds to is the last (4rth) on the list. Likewise for video it's about 3rd on list. I only sometimes do heavy video processing whilst LW is open. Otherwise for rendering & conversion it takes twice as long!

Sklenarikova there's a New Features Request section more appropriate for your post!

Here's a more serious problem. After I killed the hung limewire process earlier and reran it ... nothing. As in, no downloads. No message saying it couldn't restart them either. Closing and restarting didn't fix it, despite the half a meg downloads.dat in the incomplete directory and the downloads.bak for it to fall back upon.

Losing the downloads that resulted from searches isn't a big deal, since they'll turn up again eventually with the same searches. But ones that resulted from host browsing may be difficult to find again indeed.

This needs to stop happening. Limewire hasn't been reliable about preserving your downloads across sessions since version 2.something. The 3.somethings were especially bad for losing data in this manner, but the 4.somethings are only somewhat better...

Schweitzer, you have too many downloads in your queue. That causes your downloads.dat file to become corrupted very frequently.

LOTR, I do have a patch that solved the problem for me. I'm going to send it to LimeWire...

Well, if the downloads would download instead of stopping at 47% and "awaiting sources" all the bloody time maybe I'd have less of them in my queue. In any case, Limewire writing invalid data to the downloads.dat file is a bug any way you slice it. It simply shouldn't, and it shouldn't care how big the thing is as long as there's sufficient disk space either. What ever happened to scalability?

Keep Moore's Law in mind -- people are downloading hundreds or even thousands of files a day and are storing tens of thousands. By 2010, they'll be downloading thousands and storing hundreds of thousands.

Will Limewire scale to function well for these people, granted that they will have 5 and 6 GHz CPUs and several GB of RAM and a TB or more of hard drive space at that point? If it won't, everyone currently using Limewire will switch to something else by 2010.

give me thumbs up