headers
Ulf Magnusson | 4 Apr 16:44
Picon

FreeBSD transfer and shutdown trouble

Valknut is acting weird on my FreeBSD system. Transfers randomly
disappear from the Transfer list. Using "Try Connect" to resume them
works fine, but of course is a major hassle. This happens on all hubs
I'm on. Also, Valknut frequently crashes on shutdown, never
terminating properly and using up 100% CPU until you kill it. The
console messages from a complete such session follows:

Checking xml version ...
Compiled for '20618' using '20618'
Using Valknut: '0.3.7'
Checking dclib version ...
Using DCLib: '0.3.7'
Checking Qt (TM) version ...
Compiled for '3.3.4' using '3.3.4'
Checking Qt (TM) privates ...
private test ok !
I/O warning : failed to load external entity "/home/ulf/.dc//emoticons.xml"
CListenManager: start listen
listen on socket
I/O warning : failed to load external entity "/home/ulf/.dc/dcfriendlist.cfg"
CHTTP: HOST : '-server-:80'
CHTTP: URL  : '/update.xml'
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
FreeDiscSpace: No such file or directory
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mathias Küster | 4 Apr 18:07
Picon

Re: FreeBSD transfer and shutdown trouble

Hello,

set your download folder in the options.

Mathias

Ulf Magnusson wrote:
> Valknut is acting weird on my FreeBSD system. Transfers randomly
> disappear from the Transfer list. Using "Try Connect" to resume them
> works fine, but of course is a major hassle. This happens on all hubs
> I'm on. Also, Valknut frequently crashes on shutdown, never
> terminating properly and using up 100% CPU until you kill it. The
> console messages from a complete such session follows:
> 
> Checking xml version ...
> Compiled for '20618' using '20618'
> Using Valknut: '0.3.7'
> Checking dclib version ...
> Using DCLib: '0.3.7'
> Checking Qt (TM) version ...
> Compiled for '3.3.4' using '3.3.4'
> Checking Qt (TM) privates ...
> private test ok !
> I/O warning : failed to load external entity "/home/ulf/.dc//emoticons.xml"
> CListenManager: start listen
> listen on socket
> I/O warning : failed to load external entity "/home/ulf/.dc/dcfriendlist.cfg"
> CHTTP: HOST : '-server-:80'
> CHTTP: URL  : '/update.xml'
> FreeDiscSpace: No such file or directory
(Continue reading)

Permalink | Reply | 0 comments |
headers
hypostasis | 9 Apr 13:16
Favicon

Description Tag Hub Connections Like DC++ ?

Is there a way to make the description tag show a hub listing similar to DC++?
Current in Valknut v0.3.7: <...,H:0,...>, To: <...,H:0/0/0,...>

Quoting the DC++ Readme:
     <++ V:x,M:x,H:x/y/z,S:x[,O:x]> where
     H: x = number of hubs connected to where you're not a registered user
        y = number of hubs you're registered in
        z = number of hubs you're registered as op

I tried looking through the code and CConnectionManager class. It looks like 
it is only capable of getting a single number for total connected hubs rather 
than the more fine grained count in DC++. So this may possibly be reduced 
down to a feature request. However, since I'm not a programmer, I could be 
completely off here. Thanks.
Permalink | Reply | 0 comments |
headers
tudor tatar | 11 Apr 14:49
Picon

no hub names, only ip numbers: and no dload

Hi!

I'm having this problem for some time now, for the last couple of
versions. So here goes: when searching on all public hubs the results
have ip no instead of names, and I cannot dload from any all these
results. I can though dload from the few results (usualy about 5% of all
results) the have hub names. The same happens with a search on connected
hubs: results come up with ip no instead of hub name. 

Am I the only one with this type of problem? I'm running valknut 0.3.7
on a debian unstable, compiled it myself.

Thanx so much for your time
--

-- 
tudor tatar <tudor.tatar <at> tin.it>
Permalink | Reply | 0 comments |
headers
Kevin Borgnis | 11 Apr 20:29
Picon

Continuously Reconnecting to remote host.

I have posted this problem in the Bugs forum located on Valknut's
website, but I have only gotten responses from other people having
this problem.  The following is a description of the bug as witnessed
by myself with addition comments by me added in []'s:

"When downloading from a remote user (using a DC++ client, but may
affect others as well)[I have since confirmed that it even affects
versions of Valknut though the behavior observed is slightly
different.  In stead of continuously reconnecting, it appears as if
the bitrate is drastically changing every second or so], the remote
user sees the local (valnut version 0.3.5) user [This problem occurs
in versions 0.3.4 to 0.3.7.  I have not tried the latest from CVS
though I would assume this problem has been purposely corrected it
exists in the CVS head] disconnect and reconnect very frequently. This
ultimately slows down the download speed because a new connection has
to be establis[hed] for each chunk downloaded..."

I have been poking around the 0.3.4 dclib code trying to find the
source of this bug, but I have been thusfar unsuccessful.  I had
originally thought it might have been introduced when adding support
for ZBlocks, but it seems now that this was false. (My new assumption
about this may also be a mistake though, so don't hold it in too high
of a regard.)

I understand that the devs are busy, so I am perfectly willing to take
on this task of bughunting, but I would like some help from the more
experienced devs.  If you could give me some possible locations I
could look at that might narrow down my search, it would be greatly
appreciated.  Of course if this problem has been eliminated in CVS,
then there is no need to continue.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andreas Marqvardsen | 24 Apr 08:00
Picon
Favicon

Error when downloading files

Hi,

If I tend to download files wich contains the "non-international" letters, ØÆÅ 
og can forget it. Then I just get Error/2 (2 is the priority). I have done 
some search for a fix, but cant seem to find an solution. 
Running SuSE 9.2, my console works fine with "ØÆÅ" and KDE also works fine 
with those letters
Running DCGUI 0.3.7

I've had this problem for a while now, and it has become quite a pain in the 
neck. 

Regards
Andreas M
Permalink | Reply | 1 comment |
headers
Christopher Cowart | 24 Apr 09:09
Picon
Favicon

valknut/memory usage

I've been using valknut for several months. I appreciate the work you guys do 
to maintain a dc client for linux.

When I start valknut, it takes at least 2 minutes. During this time, memory 
usage jumps by over 100MB. Is this typical?

I have a share on an external USB harddrive. Recreating the share (70GB) can 
take around 10+ hours. Is this typical?

I'm using fluxbox and was wondering if there was a way to prevent the icon 
from attaching to the tray? Perhaps attach to the wm slit? or not at all?

I'm running gentoo, so everything was compiled from source, though I had the 
same problems running Fedora Core 3. valknut is version 0.3.3. My computer is 
a Dell laptop with a Pentium M 1.2GHz, 384MB.

Thanks for your help,
Chris

--

-- 
Christopher Cowart
PGP Public Key: http://hal.rescomp.berkeley.edu/~ccowart/pubkey.asc
Permalink | Reply | 1 comment |
headers
Andrew Greig | 24 Apr 18:37

Re: valknut/memory usage

On 24/04/05 17:09, Christopher Cowart wrote:
> I've been using valknut for several months. I appreciate the work you guys do 
> to maintain a dc client for linux.
> 
> When I start valknut, it takes at least 2 minutes. During this time, memory 
> usage jumps by over 100MB. Is this typical?

That sounds abnormally long.  My guess is that your share is being 
recreated on startup, which is responsible for the long delay and memory 
usage.  There is a configuration option to disable this.  Also, I recall 
there was a memory leak that occured during sharelist updates, that has 
been fixed in recent versions of Valknut.

> I have a share on an external USB harddrive. Recreating the share (70GB) can 
> take around 10+ hours. Is this typical?

Is it a USB 2 harddrive and host controller?  I have often kept most of 
my share on external USB drives, and found it intolerable at USB 1.1 
speeds.  Also, having your downloads/incomplete downloads on an external 
drive makes for bad performance, due to the regular small writes.  I 
prefer to download to an internal drive, and move things over manually in 
quiet times.

Recent versions of Valknut introduced file hashes, which have several 
benefits, but with the drawback of requiring a lot of processor time and 
disk usage to generate them.  Thankfully, once the hash has been 
calculated for a file, it shouldn't have to be done again.  From a blank 
configuration, a couple of hours to create the initial batch of hashes 
wouldn't be unusual.  10+ hours seems excessive, there is obviously an 
I/O bottleneck on your system.  If it takes this long every time you
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Greig | 24 Apr 18:51

Re: Error when downloading files

On 24/04/05 16:00, Andreas Marqvardsen wrote:
> Hi,
> 
> If I tend to download files wich contains the "non-international" letters, ØÆÅ 
> og can forget it. Then I just get Error/2 (2 is the priority). I have done 
> some search for a fix, but cant seem to find an solution. 
> Running SuSE 9.2, my console works fine with "ØÆÅ" and KDE also works fine 
> with those letters
> Running DCGUI 0.3.7
> 
> 
> I've had this problem for a while now, and it has become quite a pain in the 
> neck. 
> 
> Regards
> Andreas M

Hello,

You are not alone, many others are having similar hassles.  If you look 
in the 'Log' tab of the transfer list window, you will likely see lots of 
"Error: File not available" messages.  The DC protocol doesn't handle 
text encoding at all, so if the remote end has a different langage 
setting to you (they usually do) the text like ØÆÅ gets garbled, and the 
filenames don't match.

Until we are saved by a better protocol, there is a way to mostly work 
around this problem.  When you get a users sharelist, try changing the 
option beside 'Remote' (in the top right corner of the file list window). 
  The idea is to guess what text encoding their client is expecting.  I
(Continue reading)

Permalink | Reply | 0 comments |

Gmane