NEW: net/transmission 0.5 (BT client)

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
Description:
  Transmission is a free, lightweight BitTorrent client.  It features
  a simple, intuitive interface on top on an efficient, cross-platform
  back-end.

There are independent command line and GUI clients, which I split
off into separate subpackages.  I also added a pseudo flavor to
skip building the GUI client, because Transmission is a lightweight
client (written in C) and GTK+2 is a fairly heavyweight dependency.

Lightly tested on sparc64.

--
Christian "naddy" Weisgerber                          [hidden email]

transmission.tgz (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Jasper Lievisse Adriaanse
On Sat, 22 Apr 2006 04:45:35 +0200
Christian Weisgerber <[hidden email]> wrote:

> Description:
>   Transmission is a free, lightweight BitTorrent client.  It features
>   a simple, intuitive interface on top on an efficient, cross-platform
>   back-end.
>
> There are independent command line and GUI clients, which I split
> off into separate subpackages.  I also added a pseudo flavor to
> skip building the GUI client, because Transmission is a lightweight
> client (written in C) and GTK+2 is a fairly heavyweight dependency.
>
> Lightly tested on sparc64.
Nice port! Tested -gui on macppc and sparc64. And I have tested -cli on
alpha, macppc, sgi and sparc64.

Though alpha, needs the following patch, since lrintf() isn't recognized by
gcc2.x. (I have succesfully rebuilt transmission on sparc64 with this patch
to make sure it didn't break transmission on other archs.)

--- libtransmission/choking.c.orig Sat Feb 11 17:37:11 2006
+++ libtransmission/choking.c Sat Apr 22 14:07:23 2006
@@ -74,7 +74,7 @@
             20  KB/s -> 6  * 3.33 KB/s
             50  KB/s -> 10 * 5.00 KB/s
             100 KB/s -> 14 * 7.14 KB/s */
-        c->slots = lrintf( sqrt( 2 * limit ) );
+        c->slots = (int)sqrt( 2 * limit );
     tr_lockUnlock( &c->lock );
 }
 

Cheers,
Jasper

> --
> Christian "naddy" Weisgerber                          [hidden email]
>

--
Humppa is a serious thing!

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

steven mestdagh
Jasper Lievisse Adriaanse [2006-04-22, 14:24:04]:

> On Sat, 22 Apr 2006 04:45:35 +0200
> Christian Weisgerber <[hidden email]> wrote:
>
> > Description:
> >   Transmission is a free, lightweight BitTorrent client.  It features
> >   a simple, intuitive interface on top on an efficient, cross-platform
> >   back-end.
> >
> > There are independent command line and GUI clients, which I split
> > off into separate subpackages.  I also added a pseudo flavor to
> > skip building the GUI client, because Transmission is a lightweight
> > client (written in C) and GTK+2 is a fairly heavyweight dependency.
> >
> > Lightly tested on sparc64.
> Nice port! Tested -gui on macppc and sparc64. And I have tested -cli on
> alpha, macppc, sgi and sparc64.
>
> Though alpha, needs the following patch, since lrintf() isn't recognized by

error message?

> gcc2.x. (I have succesfully rebuilt transmission on sparc64 with this patch
> to make sure it didn't break transmission on other archs.)
>
> --- libtransmission/choking.c.orig Sat Feb 11 17:37:11 2006
> +++ libtransmission/choking.c Sat Apr 22 14:07:23 2006
> @@ -74,7 +74,7 @@
>              20  KB/s -> 6  * 3.33 KB/s
>              50  KB/s -> 10 * 5.00 KB/s
>              100 KB/s -> 14 * 7.14 KB/s */
> -        c->slots = lrintf( sqrt( 2 * limit ) );
> +        c->slots = (int)sqrt( 2 * limit );
>      tr_lockUnlock( &c->lock );
>  }

i don't get any error.  is your system -current ?

btw, this looks like it needs NO_REGRESS=Yes .

>
> Cheers,
> Jasper
>
> > --
> > Christian "naddy" Weisgerber                          [hidden email]
> >
>
> --
> Humppa is a serious thing!


Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Deanna Phillips-2
In reply to this post by Christian Weisgerber
Christian Weisgerber <[hidden email]> writes:

> Description:
>   Transmission is a free, lightweight BitTorrent client.  It features
>   a simple, intuitive interface on top on an efficient, cross-platform
>   back-end.
>
> There are independent command line and GUI clients, which I split
> off into separate subpackages.  I also added a pseudo flavor to
> skip building the GUI client, because Transmission is a lightweight
> client (written in C) and GTK+2 is a fairly heavyweight dependency.

This is a nice program I've tested a bit in the past.  Just
tested your port on i386, and the cli works fine .. resume and
md5 checking of the torrent passed.

The gtk frontend still needs a bit of work, I think.  It dumped
core on me when I tried to start in a directory I didn't have
write permission to, and continued to do so even after I'd
restarted it in a writable directory.  The fix was to remove my
.transmission/gtk-state file.


--
deanna at sdf

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Jasper Lievisse Adriaanse
In reply to this post by steven mestdagh
On Sat, 22 Apr 2006 14:57:01 +0200
steven mestdagh <[hidden email]> wrote:

> Jasper Lievisse Adriaanse [2006-04-22, 14:24:04]:
> > On Sat, 22 Apr 2006 04:45:35 +0200
> > Christian Weisgerber <[hidden email]> wrote:
> >
> > > Description:
> > >   Transmission is a free, lightweight BitTorrent client.  It features
> > >   a simple, intuitive interface on top on an efficient, cross-platform
> > >   back-end.
> > >
> > > There are independent command line and GUI clients, which I split
> > > off into separate subpackages.  I also added a pseudo flavor to
> > > skip building the GUI client, because Transmission is a lightweight
> > > client (written in C) and GTK+2 is a fairly heavyweight dependency.
> > >
> > > Lightly tested on sparc64.
> > Nice port! Tested -gui on macppc and sparc64. And I have tested -cli on
> > alpha, macppc, sgi and sparc64.
> >
> > Though alpha, needs the following patch, since lrintf() isn't recognized by
>
> error message?
>
> > gcc2.x. (I have succesfully rebuilt transmission on sparc64 with this patch
> > to make sure it didn't break transmission on other archs.)
> >
> > --- libtransmission/choking.c.orig Sat Feb 11 17:37:11 2006
> > +++ libtransmission/choking.c Sat Apr 22 14:07:23 2006
> > @@ -74,7 +74,7 @@
> >              20  KB/s -> 6  * 3.33 KB/s
> >              50  KB/s -> 10 * 5.00 KB/s
> >              100 KB/s -> 14 * 7.14 KB/s */
> > -        c->slots = lrintf( sqrt( 2 * limit ) );
> > +        c->slots = (int)sqrt( 2 * limit );
> >      tr_lockUnlock( &c->lock );
> >  }
>
> i don't get any error.  is your system -current ?
The particular system I tested it not, I mixed up IP-addresses :-(
It works ok on alpha/-current.

> btw, this looks like it needs NO_REGRESS=Yes .
>
> >
> > Cheers,
> > Jasper
> >
> > > --
> > > Christian "naddy" Weisgerber                          [hidden email]
> > >
> >
> > --
> > Humppa is a serious thing!
>
>
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>

--
Humppa is a serious thing!

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Deanna Phillips-2
In reply to this post by Christian Weisgerber
Here's an attempt at a manual entry for the cli.  I've submitted
it to the transmission team who'll commit it when they get
around to it.

Note that this manpage corrects some errors in the usage
statement.



--
deanna at sdf

transmissioncli.1 (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Deanna Phillips-2
Deanna Phillips <[hidden email]> writes:

> Here's an attempt at a manual entry for the cli.  I've submitted
> it to the transmission team who'll commit it when they get
> around to it.
>
> Note that this manpage corrects some errors in the usage
> statement.

Argh.

Please also note that the previously attached manpage contained
errors.

The corrected version is at :

http://deanna.freeshell.org/transmissioncli.1


--
deanna at sdf

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
Deanna Phillips <[hidden email]> wrote:

> The corrected version is at :
> http://deanna.freeshell.org/transmissioncli.1

Great, thanks.
I think it will be easiest to include this in the files/ directory
of the port--or does anyone have a strong opinion in favor of
fetching it as a distfile?

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
In reply to this post by Deanna Phillips-2
Deanna Phillips <[hidden email]> wrote:

> Note that this manpage corrects some errors in the usage
> statement.

Actually, the synopsis in the man page is wrong.  It doesn't allow
plain

$ transmissioncli foo.torrent

The -i and -s switches do not take an extra argument, they modify
the behavior with the mandatory torrent file argument.

Check transmissioncli.c:parseCommandLine().

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Jasper Lievisse Adriaanse
In reply to this post by Jasper Lievisse Adriaanse
On Sat, 22 Apr 2006 14:24:04 +0200
Jasper Lievisse Adriaanse <[hidden email]> wrote:

> On Sat, 22 Apr 2006 04:45:35 +0200
> Christian Weisgerber <[hidden email]> wrote:
>
> > Description:
> >   Transmission is a free, lightweight BitTorrent client.  It features
> >   a simple, intuitive interface on top on an efficient, cross-platform
> >   back-end.
> >
> > There are independent command line and GUI clients, which I split
> > off into separate subpackages.  I also added a pseudo flavor to
> > skip building the GUI client, because Transmission is a lightweight
> > client (written in C) and GTK+2 is a fairly heavyweight dependency.
> >
> > Lightly tested on sparc64.
> Nice port! Tested -gui on macppc and sparc64. And I have tested -cli on
> alpha, macppc, sgi and sparc64.
-cli works fine on sparc too.

> Cheers,
> Jasper
>
> > --
> > Christian "naddy" Weisgerber                          [hidden email]

--
Humppa is a serious thing!

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Deanna Phillips-2
In reply to this post by Christian Weisgerber
[hidden email] (Christian Weisgerber) writes:

> Deanna Phillips <[hidden email]> wrote:
>
>> Note that this manpage corrects some errors in the usage
>> statement.
>
> Actually, the synopsis in the man page is wrong.  It doesn't allow
> plain
>
> $ transmissioncli foo.torrent
>
> The -i and -s switches do not take an extra argument, they modify
> the behavior with the mandatory torrent file argument.

Thanks for the feedback.

The -i and -s arguments are mutually exclusive, and anything
will work with -v.  I wasn't sure how to handle this in a manual
page, so please take a look at my updated version and comment.

http://deanna.freeshell.org/transmissioncli.1

I thought this was a one-off, so I didn't put it under any
version control.

--
deanna at sdf

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Lars Hansson
In reply to this post by Christian Weisgerber
I have some problems with the gui. I have a couple of unfinished torrent from
BitTorrent that i successfully added to Transmission. It checks the existing
files just fine and then it starts to download. The problem comes if I quit
Transmission and start it again because then it hangs before even showing the
ui. It works fine with one file added but if you add more something with the
resume goes wrong when you start the gui client.

---
Lars Hansson

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
In reply to this post by Deanna Phillips-2
Deanna Phillips <[hidden email]> wrote:

> The -i and -s arguments are mutually exclusive, and anything
> will work with -v.  I wasn't sure how to handle this in a manual
> page, so please take a look at my updated version and comment.

I think you are trying too hard.  The simplist synopsis printed by
"transmissioncli -h" is less confusing.  However, if you insist on
going for perfection, I suggest you try to involve jmc@, our man
page perfectionist.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
In reply to this post by Lars Hansson
Lars Hansson <[hidden email]> wrote:

> I have some problems with the gui. I have a couple of unfinished torrent from
> BitTorrent that i successfully added to Transmission. It checks the existing
> files just fine and then it starts to download. The problem comes if I quit
> Transmission and start it again because then it hangs before even showing the
> ui. It works fine with one file added but if you add more something with the
> resume goes wrong when you start the gui client.

I have an eight-file torrent here, with four complete files and
four incomplete ones, which I've moved back and forth between
BitTorrent and Transmission.  No hang here.

Curiously, Transmission claims the torrent is 1/3 finished, while
BitTorrent says 2/3.  I concur with BitTorrent, so I don't know how
Transmission arrives at its estimate and if this is merely a cosmetic
issue that will correct itself or if this points to a problem.
We'll see.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
In reply to this post by Christian Weisgerber
Has anybody else run across the situation yet where transmission*
keeps spewing "Tracker: no dictionary in answer" errors?

I looked at the tracker responses, and they seemed fine.  (Not that
I know the details of the protocol.)  I suspect transmission just
fails to parse them.  It keeps hammering away at the tracker for a
"correct" response, which looks like a fairly serious bug.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
Christian Weisgerber <[hidden email]> wrote:

> I looked at the tracker responses, and they seemed fine.  (Not that
> I know the details of the protocol.)  I suspect transmission just
> fails to parse them.  It keeps hammering away at the tracker for a
> "correct" response, which looks like a fairly serious bug.

This corresponds to changeset 230 from the upstream SVN, which
introduces a less haphazard tracker response parsing.

Please test.


Index: Makefile
===================================================================
RCS file: /cvs/ports/net/transmission/Makefile,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 Makefile
--- Makefile 26 Apr 2006 20:05:06 -0000 1.1.1.1
+++ Makefile 26 Apr 2006 21:36:57 -0000
@@ -4,8 +4,8 @@
 COMMENT-gui= "lightweight BitTorrent client with graphical interface"
 
 DISTNAME= Transmission-0.5
-PKGNAME= ${DISTNAME:L}
-PKGNAME-gui= ${DISTNAME:L:S/-/-gui-/}
+PKGNAME= ${DISTNAME:L}p0
+PKGNAME-gui= ${DISTNAME:L:S/-/-gui-/}p0
 CATEGORIES= net
 HOMEPAGE= http://transmission.m0k.org/
 
Index: patches/patch-libtransmission_tracker_c
===================================================================
RCS file: patches/patch-libtransmission_tracker_c
diff -N patches/patch-libtransmission_tracker_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-libtransmission_tracker_c 26 Apr 2006 21:36:57 -0000
@@ -0,0 +1,175 @@
+$OpenBSD$
+--- libtransmission/tracker.c.orig Sat Feb 11 17:37:11 2006
++++ libtransmission/tracker.c Wed Apr 26 23:21:07 2006
+@@ -45,6 +45,11 @@ struct tr_tracker_s
+ #define TC_STATUS_RECV    4
+     char           status;
+
++#define TC_ATTEMPT_NOREACH 1
++#define TC_ATTEMPT_ERROR   2
++#define TC_ATTEMPT_OK      4
++    char           lastAttempt;
++
+     int            socket;
+     uint8_t      * buf;
+     int            size;
+@@ -67,10 +72,12 @@ tr_tracker_t * tr_trackerInit( tr_handle
+
+     tc->started  = 1;
+
++    tc->interval = 300;
+     tc->seeders  = -1;
+     tc->leechers = -1;
+
+     tc->status   = TC_STATUS_IDLE;
++    tc->lastAttempt = TC_ATTEMPT_NOREACH;
+     tc->size     = 1024;
+     tc->buf      = malloc( tc->size );
+
+@@ -84,12 +91,22 @@ static int shouldConnect( tr_tracker_t *
+ {
+     uint64_t now = tr_date();
+
+-    /* In any case, always wait 5 seconds between two requests */
+-    if( now < tc->dateTry + 5000 )
++    /* Unreachable tracker, try 10 seconds before trying again */
++    if( tc->lastAttempt == TC_ATTEMPT_NOREACH &&
++        now < tc->dateTry + 10000 )
+     {
+         return 0;
+     }
+
++    /* The tracker rejected us (like 4XX code, unauthorized IP...),
++       don't hammer it - we'll probably get the same answer next time
++       anyway */
++    if( tc->lastAttempt == TC_ATTEMPT_ERROR &&
++        now < tc->dateTry + 1000 * tc->interval )
++    {
++        return 0;
++    }
++
+     /* Do we need to send an event? */
+     if( tc->started || tc->completed || tc->stopped || 0 < tc->newPort )
+     {
+@@ -310,6 +327,8 @@ static void recvAnswer( tr_tracker_t * t
+     int i;
+     benc_val_t   beAll;
+     benc_val_t * bePeers, * beFoo;
++    uint8_t * body;
++    int bodylen;
+
+     if( tc->pos == tc->size )
+     {
+@@ -338,34 +357,70 @@ static void recvAnswer( tr_tracker_t * t
+     tc->status  = TC_STATUS_IDLE;
+     tc->dateTry = tr_date();
+
+-    if( tc->pos < 1 )
++    if( tc->pos < 12 || ( 0 != memcmp( tc->buf, "HTTP/1.0 ", 9 ) &&
++                          0 != memcmp( tc->buf, "HTTP/1.1 ", 9 ) ) )
+     {
+-        /* We got nothing */
++        /* We don't have a complete HTTP status line */
++        tr_inf( "Tracker: incomplete HTTP status line" );
++        tc->lastAttempt = TC_ATTEMPT_NOREACH;
+         return;
+     }
+
++    if( '2' != tc->buf[9] )
++    {
++        /* we didn't get a 2xx status code */
++        tr_err( "Tracker: invalid HTTP status code: %c%c%c",
++                tc->buf[9], tc->buf[10], tc->buf[11] );
++        tc->lastAttempt = TC_ATTEMPT_ERROR;
++        return;
++    }
++
++    /* find the end of the http headers */
++    body = tr_memmem( tc->buf, tc->pos, "\015\012\015\012", 4 );
++    if( NULL != body )
++    {
++        body += 4;
++    }
++    /* hooray for trackers that violate the HTTP spec */
++    else if( NULL != ( body = tr_memmem( tc->buf, tc->pos, "\015\015", 2 ) ) ||
++             NULL != ( body = tr_memmem( tc->buf, tc->pos, "\012\012", 2 ) ) )
++    {
++        body += 2;
++    }
++    else
++    {
++        tr_err( "Tracker: could not find end of HTTP headers" );
++        tc->lastAttempt = TC_ATTEMPT_NOREACH;
++        return;
++    }
++    bodylen = tc->pos - (body - tc->buf);
++
+     /* Find the beginning of the dictionary */
+-    for( i = 0; i < tc->pos - 18; i++ )
++    for( i = 0; i < bodylen; i++ )
+     {
+-        /* Hem */
+-        if( !memcmp( &tc->buf[i], "d8:interval", 11 ) ||
+-            !memcmp( &tc->buf[i], "d8:complete", 11 ) ||
+-            !memcmp( &tc->buf[i], "d14:failure reason", 18 ) )
++        if( body[i] == 'd' )
+         {
++            /* This must be it */
+             break;
+         }
+     }
+
+-    if( i >= tc->pos - 18 )
++    if( i >= bodylen )
+     {
++        if( tc->stopped || 0 < tc->newPort )
++        {
++            tc->lastAttempt = TC_ATTEMPT_OK;
++            goto nodict;
++        }
+         tr_err( "Tracker: no dictionary in answer" );
+-        // printf( "%s\n", tc->buf );
++        tc->lastAttempt = TC_ATTEMPT_ERROR;
+         return;
+     }
+
+-    if( tr_bencLoad( &tc->buf[i], &beAll, NULL ) )
++    if( tr_bencLoad( &body[i], &beAll, NULL ) )
+     {
+         tr_err( "Tracker: error parsing bencoded data" );
++        tc->lastAttempt = TC_ATTEMPT_ERROR;
+         return;
+     }
+
+@@ -377,10 +432,12 @@ static void recvAnswer( tr_tracker_t * t
+         tor->status |= TR_TRACKER_ERROR;
+         snprintf( tor->error, sizeof( tor->error ),
+                   "%s", bePeers->val.s.s );
++        tc->lastAttempt = TC_ATTEMPT_ERROR;
+         goto cleanup;
+     }
+
+     tor->status &= ~TR_TRACKER_ERROR;
++    tc->lastAttempt = TC_ATTEMPT_OK;
+
+     if( !tc->interval )
+     {
+@@ -417,6 +474,10 @@ static void recvAnswer( tr_tracker_t * t
+
+     if( !( bePeers = tr_bencDictFind( &beAll, "peers" ) ) )
+     {
++        if( tc->stopped || 0 < tc->newPort )
++        {
++            goto nodict;
++        }
+         tr_err( "Tracker: no \"peers\" field" );
+         goto cleanup;
+     }
+@@ -477,6 +538,7 @@ static void recvAnswer( tr_tracker_t * t
+         }
+     }
+
++nodict:
+     /* Success */
+     tc->started   = 0;
+     tc->completed = 0;
Index: patches/patch-libtransmission_utils_c
===================================================================
RCS file: patches/patch-libtransmission_utils_c
diff -N patches/patch-libtransmission_utils_c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-libtransmission_utils_c 26 Apr 2006 21:36:57 -0000
@@ -0,0 +1,37 @@
+$OpenBSD$
+--- libtransmission/utils.c.orig Sat Feb 11 17:37:11 2006
++++ libtransmission/utils.c Wed Apr 26 23:18:43 2006
+@@ -61,3 +61,33 @@ int tr_rand( int sup )
+     }
+     return rand() % sup;
+ }
++
++void * tr_memmem( const void *vbig, size_t big_len,
++                  const void *vlittle, size_t little_len )
++{
++    const char *big = vbig;
++    const char *little = vlittle;
++    size_t ii, jj;
++
++    if( 0 == big_len || 0 == little_len )
++    {
++        return NULL;
++    }
++
++    for( ii = 0; ii + little_len <= big_len; ii++ )
++    {
++        for( jj = 0; jj < little_len; jj++ )
++        {
++            if( big[ii + jj] != little[jj] )
++            {
++                break;
++            }
++        }
++        if( jj == little_len )
++        {
++            return (char*)big + ii;
++        }
++    }
++
++    return NULL;
++}
Index: patches/patch-libtransmission_utils_h
===================================================================
RCS file: patches/patch-libtransmission_utils_h
diff -N patches/patch-libtransmission_utils_h
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ patches/patch-libtransmission_utils_h 26 Apr 2006 21:36:57 -0000
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libtransmission/utils.h.orig Sat Feb 11 17:37:11 2006
++++ libtransmission/utils.h Wed Apr 26 23:18:43 2006
+@@ -33,6 +33,8 @@ void tr_msg  ( int level, char * msg, ..
+
+ int  tr_rand ( int );
+
++void * tr_memmem( const void *, size_t, const void *, size_t );
++
+ /***********************************************************************
+  * tr_date
+  ***********************************************************************
--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Lars Hansson
In reply to this post by Christian Weisgerber
On Thursday 27 April 2006 04:29, Christian Weisgerber wrote:
> I have an eight-file torrent here, with four complete files and
> four incomplete ones, which I've moved back and forth between
> BitTorrent and Transmission.  No hang here.

But my problem is when you have more then one concurrent torrent, ie you "Add"
more than one torrentfile.

---
Lars Hansson

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
Lars Hansson <[hidden email]> wrote:

> > I have an eight-file torrent here, with four complete files and
> > four incomplete ones, which I've moved back and forth between
> > BitTorrent and Transmission.  No hang here.
>
> But my problem is when you have more then one concurrent torrent, ie you "Add"
> more than one torrentfile.

I haven't managed to reproduce that yet, maybe there are some
additional conditions involved.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Christian Weisgerber
In reply to this post by Christian Weisgerber
Christian Weisgerber <[hidden email]> wrote:

> Curiously, Transmission claims the torrent is 1/3 finished, while
> BitTorrent says 2/3.  I concur with BitTorrent, so I don't know how
> Transmission arrives at its estimate and if this is merely a cosmetic
> issue that will correct itself or if this points to a problem.

A word of caution:  Say you have a torrent that includes several
files in a folder.  You already have some of them from a different
source, say #1, #3, and #4, so you put them all in the folder and
start Transmission.  It will pick up #1 and continue downloading
from there.  It will *not* pick up #3 and #4 and in fact clobber
them eventually.

This is a bug in 0.5.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NEW: net/transmission 0.5 (BT client)

Maxim Bourmistrov
In reply to this post by Christian Weisgerber

GTK-frontend works fine here (i386)
Even with more than one torrent file.
Thanks for your work.

On Saturday 22 April 2006 04:45, Christian Weisgerber wrote:

> Description:
>   Transmission is a free, lightweight BitTorrent client.  It features
>   a simple, intuitive interface on top on an efficient, cross-platform
>   back-end.
>
> There are independent command line and GUI clients, which I split
> off into separate subpackages.  I also added a pseudo flavor to
> skip building the GUI client, because Transmission is a lightweight
> client (written in C) and GTK+2 is a fairly heavyweight dependency.
>
> Lightly tested on sparc64.
>

//maxim