The 4.9 series has a new way of finding out if a host is available or not without actually connecting to them. So even if it did "make an honest attempt to connect" it would still fail.

Then that "new way of finding out if a host is available" obviously is broken. Used to be you'd see a bunch of files you liked, hit to download them, get a few, and the rest would "need more sources". You'd resume them, and get some, and the rest would "await sources". You'd resume them, get some, and a smaller number would "await sources". And so on. Now, however, in the exact same situation you get only a fraction as many of the files, because you get the same number the first time, the same number the second time, and then zero, until you restart Limewire.

This is NOT a change for the better. The same logic that was making it decide a file was "awaiting sources" that was in fact available and would download at the tap of the Resume button is evidently making it give up before it can even try. That logic is in error.

Of course, the real problem is that it prematurely gives up on a file that will actually download given another resume attempt or three. But at least before you could manually resume it when it decided to give up. Now once it decides to give up you have to restart.

it uses udp (a connectionless protocol).. this is also how the FW2FW protocol works. and the first person to respond will be your first download canidate.

It has never been possible to resume a download in the "Need more sources" state. The only thing you could do is press "Find more sources", which would put the download in "Awaiting sources".

Do you mean before you were able to hit resume on a download that was "Awaiting sources" and it would start downloading? I doubt that.

YES. That is exactly what I mean. You'd find a bunch of files you wanted and hit download. You'd get maybe three of them. The rest would "need more sources". You'd hit find sources. It would find a few more (usually three) and download them. The rest would end up "awaiting sources". If you selected them and hit resume, you'd usually get some more -- again, frequently, three. (Three seems to be a common number of upload slots, along with five, for whatever reason.) Wash, rinse, repeat, eventually get them all, or most of them. Now, the later stages of this method for getting the rest of the files Doesn't Work. You have to keep restarting Limewire, which is pointless and which people shouldn't be being encouraged to do, whether explicitly or by the program's behavior.

It is clear from what you say that "awaiting sources" is never supposed to appear for a file with known sources online; it is equally clear from what I have observed that files with known sources do erroneously end up in that state, despite being resumable. Except that in most of the 4.9 betas it doesn't work anymore, and as a result when you find a big cluster of co-hosted files you can only ever get a handful of them without restarting Limewire, which didn't used to be the case if you knew what you were doing. (It worked for some of the betas, around 4.9.10 or maybe 4.9.7, though...)

The proof is in the pudding -- if you find a batch of such files now and get a few and the rest end up awaiting sources, and you restart your client and it promptly downloads some of them (or does so shortly after you do another "find sources"), this is a sure sign that the host with those files never actually went offline, and the supposedly "awaiting sources" files were actually still available and should have shown "waiting for busy hosts".

Let me guess -- your new udp thingie cannot distinguish between an offline host and a busy host, while the old system could? And moreover, once it decides a host is offline it actually forgets about the host entirely, whereas the old system still remembered the potential source and if it became available again then resume would work, but now it won't because even if the source is available again it forgets it ever existed? Considering how common it is for hosts to be intermittently busy, in yo-yo mode, or have flaky connections, this is a recipe for disaster.

We could not reproduce this behavior. Starting several downloads from the same host would result in the first three being started, and the rest would either become waiting for busy or need more sources depending on what the remote host replied (or failed to reply) in response.

The difference is in what happens next. Find more sources would tend to get some more, and the rest would await sources.

In 4.8.1 and some of the 4.9 betas, resuming those would get some more. In 4.9.17 and other 4.9 betas, it has no effect -- it doesn't even show "connecting..." status however briefly. It seems to actually discard its knowledge of the source as soon as that source fails to respond even once -- which is bad, because failure to respond is often intermittent rather than indicating the host has become long-term unavailable.

Are you usually not firewalled when this happens? If so, could you try and reproduce this behavior when firewalled? Let me know if you need help making Limewire think its firewalled.

Ok, the fact that older versions were making an attempt to download the file even while "awaiting for sources" was unintentional and as we changed that code the side effect dissapeared.

However, as it appears to be useful and helpful in getting the downloads done, we're going to restore it explicitly. Will be in the next version.

The email addy for submitting bug reports, bugs@limewire.com doesnt work, i keep getting delivery failed emails back.