Re: Auto-Search

--- Turbo Fredriksson <turbo <at> bayour.com> wrote:

> Quoting "Edward J. Sheldrake" <ejs1920 <at> yahoo.co.uk>:
> 
> >> How do one tell if it's a multi-download? Is this specified
> globaly,
> >> or localy for each download?
> >> 
> >> Sometimes I got the question and selected multi. Can that be
> changed?
> >
> > File > Quick options > Download mode.
> > It is set when the download starts, from the option specified under
> > quick options (or from which button you press if it's set to "Ask")
> > It cannot be changed after the download has started.
> 
> 'after the download has started'. For this session, or at all?
> If I change the setting and restart Valknut. Will those particular
> downloads still be multi?
Multi or single download mode is saved in the download queue, so it
will be for all sessions. And the good news is I fixed the bug with
multi download mode in the latest version of dclib (20061030).

> 
> > A bug with TTHF download was recently fixed, (version 20061029),
> that
> > should fix the "File Not Available" errors.
> 
> I'll try that version. In the mean time I've been running my own
> version,
> with SOME of the latest patches.
> 
> The only patches I have NOT applied are the following. My version
> works
> perfectly. In two hours running, it downloaded 22 files (roughly a
> gig)
> with more than 14 concurrent inbout (i.e. me downloading) connections
> where as 20061017ejs didn't download ANY.
If 20061017ejs started the transfers, but they stalled after
downloading the first 1MB chunk, that is the bug I fixed with the
latest version (20061030). I think the bug only occurs if compressed
transfers are disabled in the remote DC++ client.

> 
> ----- s n i p -----
> dclib-0.3.7-autoconf-crap.patch
> dclib-0.3.7-change-ugetblock-handling.patch
> dclib-0.3.7-fix-downloading-files-from-search.patch
The above patch may be very important for you, since it removes the
"TTH:" prefix from TTH search results so they can be used properly in
TTHF requests. Otherwise, valknut will send an invalid TTH and get a
"File Not Available" error.

> dclib-0.3.7-optimize-chunk-downloading.patch
This patch isn't mine, but I've included it since it seems stable, and
I think it has been included in Debian's packages of dclib.

> 
> valknut-0.3.7-custom-commands-v1.patch
> valknut-0.3.7-custom-commands-v2.patch
> valknut-0.3.7-custom-commands-v2-to-v3.patch
> valknut-0.3.7-custom-menu-commands-v2.patch
> valknut-0.3.7-filebrowser-default-remote-encoding.patch    *1
> valknut-0.3.7-filebrowser-human-size-v2.patch              *1
> valknut-0.3.7-search-results-slot-sorting.patch            *1
> valknut-0.3.7-search-results-split-slots-column-v2.patch   *1
> valknut-0.3.7-search-spy-copy.patch                        *1
> valknut-0.3.7-search-spy-enhancements.patch                *1
> ----- s n i p -----
> (the patches marked *1 is those I have, but not the _exact_ same
> one).
> 
> And the custom commands patch(es) I have absolutly no interest/need
> for so I never added those...
> 
> > But multi download mode is
> > still very broken, and it unusable. Fixing multi download mode is
> > currently the priority.
> 
> Multi download mode...  I've always made sure that I had more than
> one source of a specific file (looking for clones with/without
> TTH). I can clearly see that it downloads from more than one source
> at a time. Isn't that multi download mode?
If you're sure valknut is downloading the same file from more than one
source simultaneously, then I think multi download mode must be
enabled. If valknut has more than one source but is in single mode
download, it will only use another source if one goes offline.

> 
> > As with disconnecting from hubs, there may be a problem with the
> hub
> > count in the tag, (you could try disabling the extended hub count
> so it
> > just says H:1 instead of H:1/0/0), someone else sent a patch, and
> I'll
> > add some extra sanity checking in a future release.
> 
> So it seems. Without extended hub count I see 'H:14' (which is STILL
> wrong - I'm connected to 17 hubs), but WITH the extended hub count
> ticked, I see 'H:9/5/2'.
The original H:14 hub count did not include hubs where you are an
operator. This was the intended behaviour, which I decided to keep for
compatibility. I've also noticed it takes some time for the extended
hub count to update. Otherwise I don't know why it's wrong, maybe one
of the hubs is slow to log in or something.

Please note that I can only do my testing running a hub and about two
client on localhost. As for actually using my modified version, I run a
slightly different version with a few local patches applied, and I
sucessfully upload large quantities of data with it, on a private hub
within a LAN. I do not, however, use it to download much.

> 
> I've been running with the extended hub count'er for quite some
> time now (before - ? - it was configurable) and it always worked
> fine...
> 
> But I've noticed that sometimes it reads 'Hub offline' when it
> actually
> 'meant' 'User offline' (a 'Try connect' - not 'Connect to Hub' -
> immediately switches from 'Hub offline' to 'User offline' without
> messing with the already connected hub window).
> 
> > Hope that helps, if you need a very stable version I would
> recommend
> > running standard valknut from your distribution's packages if
> possible,
> > although it will not be able to connect to recent DC++ versions.
> 
> That's why I'm trying patches until it breaks. I've been
> kicked/banned
> from basically all hubs because Valknut isn't 'up to snuff' (hub op's
> words, not mine :) so I MUST run a more resent version. And
> 'backtracking'
> the patches makes it easier to find WHAT broke it...
> 
> I'm going to add the missing dclib* patches one by one and see
> if it still works (AFTER I've tested you new version).
> 
> 
> BTW, isn't it time you took over the project? At least until Mathias
> get's back on his feet? The hubs are starting to whine quite loudly
> about DCGUI not being good enough for them (don't support stuff that
> is now required - the original DCGUI doesn't, but they don't have the
> consept of OpenSource - third party patches is the norm, not the
> exception :)
> 
> If you do, could you bump the version to 0.4? At least two of my
> favorite
> hubs require DCGUI v0.4 so I had to hack it myself :). But it would
> be
> nice to be able to run a TRUE 0.4...
This is probably the wrong solution. Presumably the hub set the allowed
valknut version to 0.4 to ban all valknut clients, because they don't
want them. I wouldn't be surprised if they kick you out if the notice
you're using valknut, regardless of what version of it you say you
have. Valknut is not your only option, there is also DC++ on wine,
LinuxDC++, DoldaConnnect, and dc-qt 0.2.0alpha.
> 
> 
> Mathias, if you're reading this. Could you _PLEASE_ (pretty please :)
> give Edward (write) access to all the projects files/directories?
> So that we don't have to mess with patches back and forth. He truly
> writes good code! And he's quick to respond to feature requests and
> bug reports :).
Yes, I'm interested in releasing an official version, probably 0.3.8
branched from 0.3.7 with my work applied. It's important to release a
new version for compatibility with DC++ >= 0.696, and we need an
official version to be released so the distributions can package it.
However, that is likely to be the last version of valknut since
eventually ADC will replace the NMDC protocol, which valknut has no
support for.

Send instant messages to your online friends http://uk.messenger.yahoo.com