Hi betatester48486,

I too am seeing this problem, even with 4.9.23. For me, this is only occurring when new search results are coming in at the same time as when I click.

I'm investigating further... in the meantime, please let me know if this is your experience as well.

Justin

Hmmmm, actually might this just be a case of ctrl-click-and-drag?

No, this is with plain control-clicking. Where would I be trying to drag them, anyway? Dragging from Limewire doesn't do anything, after all.

i think he means clicking-and-draging over multiple files to make multiple selections.

Bug in beta 4.9.24
 

Minor (semi-cosmetic) but not unnoticeable: I just had a search where the lime stopped spinning well before all the results were in -- the number in the search result tab kept climbing for quite a while after the search was supposedly finished. It seems to me that that spinning lime indicator has never been 100% accurate though...

Not what I was doing. I control click individual files to add/remove them from the selection. Removing does not work correctly (the file tends to stay selected) and adding also does not work correctly (it's inconsistent, but about 1/3 of the time the file is added to the selection and about 2/3 of the time the file becomes the selection, i.e. everything else is deselected). This behavior is inconsistent with every other gui app with multi-select listboxes I use, and the behavior is even inconsistent over time, since control click adding DOES work correctly SOME times...

It doesn't just send out a query once and wait for responses to trickle in, but does something more active? I always figured the time was based on the HTL times the timeout (likely the HTL in minutes then), at which time the query has propagated to as many hosts as it ever will.

Of course, if that is what's happening and some hosts are slow in responding...but the timeout means a maximum additional minute.

Should I therefore wait 1 minute past when the lime stops spinning to be sure of having received all the results that are going to be received?

Or is it in fact more complex than that?

I do notice that some searches seem to quit unusually early ... which if Limewire does take an active role until that point would be cause for concern, since it means the horizon will effectively be closer for such searches, which will make it harder to find rare content in such cases. Add to that that if a single host has hundreds of matches you only seem to see a couple dozen. And add to that that the frigging ipod spammer's 50-odd bogus results seem to compete with real results for limited bandwidth, causing 50 or so legitimate results to get dropped on the floor...

Any suggestions on how to make results more balanced? I'd rather get one or two sources each for dozens of files (with the remaining sources still discoverable via the mesh, or Find Sources) than results like these, which are all too common:

169 Common File 1.xyz
44 Common File 2.xyz
36 Another Fricking Spam.wmv
12 Another file.xyz
1 Rare File 1.xyz
1 Rare File 2.xyz

and nothing else. :P

Of course if I know of some naming pattern to some of the rare files I can snag a lot of them with a narrower query, but some miscellaneous rare files might potentially elude searches for years, with daily searching!