Got a hit from an image search for not_its_real_name.jpg with user name not_the_real_username, IP not.the.real.ip, software Shareaza, and metadata (width 1600, height 2783). Double-clicked it and by the time I switched to the transfers tab it was showing Searching (No Sources) by not_its_real_name.jpg. Not enough time for a network timeout to have occurred. Network tab showed:
[00:43:14] Requesting download fragment (0-131071) of "not_its_real_name.jpg" from not.the.real.ip
[00:43:15] Download host not.the.real.ip responded with 404 (File Not Found).
OK, maybe the source deleted the file between sending out the query hit and receiving my request for the file.
Clear search tab, repeat ... the file appears again almost immediately: not_its_real_name.jpg, width 1600, height 2783, shared by not_the_real_username running Shareaza.
OK, maybe the source's DHCP lease ran out and he jumped to another IP than not.the.real.ip, while some other customer of the same IP, also running file-sharing software (or something that opened the same port) but not sharing not_its_real_name.jpg, got online at not.the.real.ip, so the query hit came from one machine and the request for the file went to a different one.
But no, the IP in the fresh search result is the same one, not.the.real.ip.
Just to be sure, I repeated this another time. Right now, that IP is consistently producing a hit with metadata and equally consistently rebuffing download requests for the self-same file with 404 errors.
Unless this is the first spammer/spoofer/etc. in the world to use normal-looking metadata on their bogus query hits, we have a buggy client out there that produces hits for files it's not sharing. And that client claims to be Shareaza.
(IP addresses, file names, and user names have been systematically replaced above, but unequal ones remain unequal.)