Track “Unwanted Search Results”

I’d like to propose a feature for DC++ that would make working with search results easier. Basically the idea is to keep track of files which have already been downloaded, or that have been marked by the user as “unwanted”, and when searches return such unwanted files, display them in a visually distinctive manner, or optionally not at all. It would be similar to the way email clients display emails as unread or read. It would be easy to pick out the search results you’ve never seen before from the ones you’ve seen again and again.

This would help when you end up repeatedly search for the same or similarly named items, such as:
- searching for files which are parts of a series, especially ones being released over time, where you rerun the same search periodically.
- searching for general categories of files, such as “churchill speech” or “quantum mechanics pdf”.
- searching for files in topic areas where wildly different file names are used for the same content, making it difficult to realize you’ve already downloaded or excluded a TTH based on another filename you’ve seen it shared under. (In this case, if you are now sharing the file its search result can already be excluded using the “don’t show items in my share option”. However, you may not share some files you’ve downloaded because they were lousy or you’ve run out of space and moved them off to optical discs, say.)

I would generally refer to this as unwanted search results and it would basically be a stored list of unique TTHs. A TTH would become an unwanted search result in these situations:
- A file with that TTH is successfully downloaded.
- In the search dialog the user right click on a search result for that TTH and selected the “mark as unwanted” option.
- A file with that TTH is added to the user’s shared files list. (This would get the files you didn’t download through DC++.)
- An additional “Add File(s) to Unwanted Search Results” would allow the user to select a set of local files or folders to hash and add to the unwanted search results. This would let a user scan items they didn’t think want to share.

The TTH of each unwanted search result would be stored in a file, presumable an XML file similar to the Queue.xml file. When a search was performed, results that match any of the TTHs in the saved unwanted search results list would be displayed along with the other search matches, but in light gray text, like a disabled menu item. An option to not display unwanted results at all would also be available. If the user attempts to download search results including unwanted search results, a dialog box would inform the user that some/all of the results selected for download were marked as unwanted. The user would be asked to choose to either not download the unwanted results or to download them anyway.

The stored list of unwanted search results would need to have some management facilities. I think the ideal would be to allow the user to open their unwanted list in a similar way that the “Own Files” list or the Download Queue can be opened. The unwanted results could be organized in a hierarchical folder system (obviously not corresponding to any particular filesystem folders, just displayed within DC++.) The user should be able to create folders within the unwanted search result list, move folders and unwanted results into folders, delete unwanted results or folders, rename unwanted results or folders.

Along with the TTH and the filename, the size of the unwanted result and date/time it was marked unwanted, and reason marked unwanted (Downloaded, Shared, or Marked by User) should be saved. Users should be able to sort the unwanted results in a folder by any of this metadata. I would use such management features to organize the unwanted results based on the different domains the search results were coming from and purge entire domains when they were no longer of interest. Also it would help users examine the unwanted results to determine if they may have erroneously marked them as unwanted. The ADL search could also be applied to let users search for items.

A couple of years ago, I implemented a primitive version of a similar scheme for saving unwanted results for a different file-sharing client on another network. It was just a set of perl script that built a hash table indexed by the unwanted file hashes, then brute force scanned the client’s binary temp files looking for hash matches, and deleted the temp file if it hit a match. Over about 3 years, it built up to over 22,000 files, but despite that volume performance and resource use was no problem. I found it was a real help in navigating the chaotic filenaming that was typical of that network. DC++ shares are usually better organized than that particular network, but there’s still a lot of scope for this kind of feature to help people avoid downloading duplicate files and just making dealing with searches easier.