– Shareaza should allow to do a search by exact size, like eMule does. Sometimes I want to find a file with a very precise, byte-accurate size, so as to check a file I already have, or to do a more thorough comparison in a case where several versions of the same file are available (in an attempt to determine which one is the original / flawless / uncorrupted one, as I mentioned here), in which case, to get both uncluttered and as thorough as possible search results (since the file name can vary a great deal no combination of keywords can be both specific enough and thorough enough, i.e. catch all matching files), in eMule, I typically type the extension only as a keyword, and the exact expected size both in the “min. size” and “max. size” fields (for instance “736851968B” which means “736851968 bytes”). [*]
– Currently (as of v. 2.7.10.2), the “Search” button is active when no search is in progress, then greyed out when a search is in progress, whereas the button on the right switches from “Clear” to “Stop”, and it is necessary to first stop a search in progress before one can run a new search. This makes it easy to instantly wipe the former search results by mistake (with no confirmation). It should not be necessary to click on “Stop” before being able to run a new search, and it would be both more convenient and more logical if the “Search” button instead switched to “Stop” when a search is in progress, so as to stay clear from the “Clear” button. Usually I do not want to clear past results as it's currently the most convenient way to keep track of specific users known as a source for a specific file (since after a while it's not possible to keep all interesting user browsing tabs open).
– (Related) There should be a confirmation (optional at least) when clearing results.
– (Related) It should be possible to clear specific results (or groups of results), rather than clearing the whole tab at once.
– When a 32 bytes string is entered as a keyword, it gets automatically converted as a special “urn” search syntax, effectively performing a search by ED2K hash rather than by keywords (same for Bittorrent hashes, possibly others). That is a very useful feature (eMule can't do that as far as I know), but it should be possible to disable it, or to specify it only when it is needed, as it can happen that a file name contains a 32 bytes string and that is what should be searched instead. (Perhaps there should be a box or drop-down menu to specify that one wants to perform a keyword search or a hash search.)
– Sometimes the search results are puzzling and don't seem to fit any obvious logic. For instance, once I typed “jaxel” as a keyword, and had a single result with a name containing the word “axel” but not “jaxel” (specifically it was “Wonder Woman XXX An Axel Braun Parody” — not quite what I was looking for !); in another instance (actually the same day — I took screenshots for both), I typed “bilan psy”, and got five porn videos with names containing the acronym “MILF” — definitely not what I was looking for ! that one is even more puzzling as none of the file names or descriptive fields, as far as I can remember, contained anything remotely close to either of the specified keywords, let alone both of them).
[*] As an example, I had a 736851968 bytes AVI / Divx conversion of the 2002 movie Ali, found on a HDD I had purchased used, I wanted to check if that file was on the ED2K network before deleting it, so I did a search in eMule with “avi” in the keywords field (in that case “ali” should have worked too as it's the only known title for that movie, but you never know, some schmuck could have renamed it “The story of Cassius Clay” or “Tarzan f##ks a zebra”), with min. size and max. size “736851968B”, and I found two different files: the one I had (based on its ED2K checksum identified with either fsum or HashTab) had 2 sources, 50% complete, and the other one had 7 sources, 71% complete. Logically, the one I had should have been the corrupted one, but upon thorough analysis (with methods described in that thread), it turned out that the file I had was the good one and the file with the most sources had several small corruptions, resulting in quite conspicuous glitches. I didn't care to re-share the file I had and report that the other one was corrupted, as this is a lousy quality conversion anyway by today's standards (also with eMule one has to keep a file shared so that the comment remains available, and even then it often happens that a comment I added doesn't appear when I search the corresponding file again later on — at least with Shareaza and its “ghost files” feature it is possible to leave a comment for a corrupted file then delete it, and the comment should remain accessible in new searches), but it goes to show that the number of sources is not a reliable indicator of a file's integrity.
Regarding the Search area:
– Shareaza should allow to do a search by exact size, like eMule does. Sometimes I want to find a file with a very precise, byte-accurate size, so as to check a file I already have, or to do a more thorough comparison in a case where several versions of the same file are available (in an attempt to determine which one is the original / flawless / uncorrupted one, as I mentioned here), in which case, to get both uncluttered and as thorough as possible search results (since the file name can vary a great deal no combination of keywords can be both specific enough and thorough enough, i.e. catch all matching files), in eMule, I typically type the extension only as a keyword, and the exact expected size both in the “min. size” and “max. size” fields (for instance “736851968B” which means “736851968 bytes”). [*]
– Currently (as of v. 2.7.10.2), the “Search” button is active when no search is in progress, then greyed out when a search is in progress, whereas the button on the right switches from “Clear” to “Stop”, and it is necessary to first stop a search in progress before one can run a new search. This makes it easy to instantly wipe the former search results by mistake (with no confirmation). It should not be necessary to click on “Stop” before being able to run a new search, and it would be both more convenient and more logical if the “Search” button instead switched to “Stop” when a search is in progress, so as to stay clear from the “Clear” button. Usually I do not want to clear past results as it's currently the most convenient way to keep track of specific users known as a source for a specific file (since after a while it's not possible to keep all interesting user browsing tabs open). – (Related) There should be a confirmation (optional at least) when clearing results. – (Related) It should be possible to clear specific results (or groups of results), rather than clearing the whole tab at once.
– When a 32 bytes string is entered as a keyword, it gets automatically converted as a special “urn” search syntax, effectively performing a search by ED2K hash rather than by keywords (same for Bittorrent hashes, possibly others). That is a very useful feature (eMule can't do that as far as I know), but it should be possible to disable it, or to specify it only when it is needed, as it can happen that a file name contains a 32 bytes string and that is what should be searched instead. (Perhaps there should be a box or drop-down menu to specify that one wants to perform a keyword search or a hash search.)
– Sometimes the search results are puzzling and don't seem to fit any obvious logic. For instance, once I typed “jaxel” as a keyword, and had a single result with a name containing the word “axel” but not “jaxel” (specifically it was “Wonder Woman XXX An Axel Braun Parody” — not quite what I was looking for !); in another instance (actually the same day — I took screenshots for both), I typed “bilan psy”, and got five porn videos with names containing the acronym “MILF” — definitely not what I was looking for ! that one is even more puzzling as none of the file names or descriptive fields, as far as I can remember, contained anything remotely close to either of the specified keywords, let alone both of them).
[*] As an example, I had a 736851968 bytes AVI / Divx conversion of the 2002 movie Ali, found on a HDD I had purchased used, I wanted to check if that file was on the ED2K network before deleting it, so I did a search in eMule with “avi” in the keywords field (in that case “ali” should have worked too as it's the only known title for that movie, but you never know, some schmuck could have renamed it “The story of Cassius Clay” or “Tarzan f##ks a zebra”), with min. size and max. size “736851968B”, and I found two different files: the one I had (based on its ED2K checksum identified with either fsum or HashTab) had 2 sources, 50% complete, and the other one had 7 sources, 71% complete. Logically, the one I had should have been the corrupted one, but upon thorough analysis (with methods described in that thread), it turned out that the file I had was the good one and the file with the most sources had several small corruptions, resulting in quite conspicuous glitches. I didn't care to re-share the file I had and report that the other one was corrupted, as this is a lousy quality conversion anyway by today's standards (also with eMule one has to keep a file shared so that the comment remains available, and even then it often happens that a comment I added doesn't appear when I search the corresponding file again later on — at least with Shareaza and its “ghost files” feature it is possible to leave a comment for a corrupted file then delete it, and the comment should remain accessible in new searches), but it goes to show that the number of sources is not a reliable indicator of a file's integrity.