How can I re-download from a search result

[hopalong]

for example, if I accidentally deleted the file already downloaded, if I test the download repeatedly, or any other reason ? There is no download menu item, if I already downloaded one time the file from the search result.
As I see, it's not the filename downloaded, but the sha1 downloaded, what changes the icon (to what ? the new icon is a book ? ) before the Name, and that's why I can't download.

[hopalong]

Hm, nobody wants or knows to reply.

[Aaron.Walkhouse]

Are still seeing it in the Library anywhere? Locate it on disk.

[hopalong]

Thanks Aaron, I try to formulate my question again:

After the download finished, LW5 changes the icon in the Name field, before the text and I can't download the file again (for example testing how the download speed changes, or from any reason), because the download menu item doesn't work - it's color is not black but light grey. This remains in that manner, even if I remove the file from My Library (to where LW5 added it automatically) and delete the file in XP.

I can research for the file, but in many cases I don't get it as a result, even if the user in online.

In Lw4 I can download it repeatedly from the original search.

The question is, why is the download forbidden from the same search, after a successful download. Am I doing something in a bad way ? Can you change this in LW5 ?

Thanks

This download prohibition is based - I think - on the hash value. When the virus filtering didn't work fully, I downloaded one suspicious to check with AVG or other way, left it in my Library, and if with any name I got the virus in a search result, LW5 showed that icon, and the download was forbidden - that's way I knew, what is a virus. In this case the download prohibition was very usable.

[meverett]

Yes the Library icon in search results shows based on file hash. If you already have the file and the same hash shows in a search result you won't be able to redownload. The idea being that if you have the file already there is no reason to download it again.

It looks like there is a bug in the search results not being updated once a file is removed from My Library. If you remove it from My Library or you delete it from within LimeWire you should be able to redownload it without having to perform a new search.

Currently what won't work is if you remove the file from disk yourself. LimeWire will not be aware of the changes till you restart. Once we readd the libray refresh option, refreshing the library would then remove the file in this case and you could then redownload.

I'll add this one to our bug reports.

[hopalong]

Yes the Library icon in search results shows based on file hash. If you already have the file and the same hash shows in a search result you won't be able to redownload. The idea being that if you have the file already there is no reason to download it again.

It looks like there is a bug in the search results not being updated once a file is removed from My Library. If you remove it from My Library or you delete it from within LimeWire you should be able to redownload it without having to perform a new search.

Currently what won't work is if you remove the file from disk yourself. LimeWire will not be aware of the changes till you restart. Once we readd the libray refresh option, refreshing the library would then remove the file in this case and you could then redownload.

I'll add this one to our bug reports.

Maybe I don't understand you perfectly or I don't speak enough clearly:

As I see from my test, the problem exists not only, when I manually - outside of LW5 - remove the file from the download folder, but when in

My Library I click to "Remove from Library" - LW5 then removes the file really from the Library, but it has to automatically refresh the search results, and change the icon back to normal, and let file again downloadable, but doesn't do this.

You say "If you remove it from My Library or you delete it from within LimeWire you should be able to redownload it without having to perform a new search" - unfortunately this is not true.
This is the second bug. At least here, in my tests , it seems.