> If you have the option "watch for alternate
> sources" active (default), then gtkg will automatically watch all
> results routed through your node (not only those displayed in searches)
> for other files with the hash S and those will be automatically added to
> the download queue. When the file is completely downloaded, the entry
> will be removed from fileinfo and gtkg will no longer collect alternate
1) it will still be displayed in searches, and I'd prefer not to see those
results which I'm already downloading in the search box. That's why I
use a composite rule (download + do not display) instead of DOWNLOAD all
2) the only other option for SHA1s is to not display the file, when what
I'd like to do instead is to not display + not download, since a later
rule may trigger downloading. From time to time, spam does appear with
SHA1 values (and blocking all results without SHA1s will prevent some
> > What strikes me is I suspect that preventing
> > modifications to SHA1 rules had to be *explicitly* added to the
> > code. Why?
> Because it was easier to lock editing, then to prevent people from
> entering invalid SHA1 values.
Other than the potential for not getting the file you want (and, rarely,
getting a file you don't), is this any more problematic than an invalid
filename or, for that matter, regex?
If it's not going to cause other problems I'll go ahead and patch. Is
there a common repository for user-contributed patches which are not
going to be part of the main development branch? I know at least two
other people who have expressed interest in modifyable SHA1 searches,
so people may be interested.
> > Whenever a new rule is added to a filter, or an old one deleted, or
> > a modification made, the display position is reset to the beginning.
> > This is fine if I have 10 rules, but very annoying if I have 100+.
> This is a bug in GtkCList. It will not be fixed.
Hmm. Does GtkCList have a method for changing currency, and is control
ceded to the caller (via callback or return) after list changes? If so
that would allow for a workaround, albeit a somewhat kludgey one.
> But if you have 100+ rules in a chain, I think you may be relying on
> filters too much.
See next message. Also, given that a specific source can be (and often
is) digitized by multiple people (thus leading to different filenames,
SHA1 values, and sizes), and that for any original source there will
often be numerous truncated versions thereof, exclusionary filters are
your friend. Perhaps less so if searching for one specific thing, but
more so if one is looking for a category (e.g., an entire season of
> > It would be really helpful to see file size in bytes rather than KB
> I agree, that might be helpful sometimes. On the other hand I live very
> well with my "drop all results without SHA1" rule.
That would be nice, but it does reduce one's chances of finding things
> Look at the archives of devel. I remember Raphael once posted a script
> to calculate SHA1 from the files. I know there is some script around
> here which takes all files in a directory and adds them to the "ignore"
> database of gtkg.
Can this be done while gtkg is running?
> I hope that information helps.
Yes, greatly, thank you.