Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4427 closed Bug (worksforme)

No download after remove/add torrent

Reported by: trtrmitya Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.33
Severity: Normal Keywords:



I am using transmission-2.33 on FreeBSD-7.2 (compiled from FreeBSD ports). I am trying to transfer a file from computer M1 to computer M2. Both run the same software and are connected to the same switch (no ports are filtered between them). They share the same settings.json (attached).

First I create torrent file: transmission-create -o test.torrent some_test_file.tar I do not specify tracker URL, because I rely on local peer discovery feature. Then I copy some_test_file.tar into Transmission's Download/ folder and add torrent on computer M1: transmission-remote -a test.torrent

M1 starts seeding.

Then I copy the same test.torrent to machine M2 and execute transmission-remote -a test.torrent

Machine M2 finds peer M1 using Local Peer Discovery (I see multicast packets on port 6771 using tcpdump) and downloads file.

Everything is OK till now.

After that I connect to M2 via Web interface and select "Trash Data and remove from list". M2 deletes that torrent from list and removes file from disk.

After that I add the same torrent back on M2: transmission-remote -a test.torrent

M2 does NOT download that torrent second time, everything stops: M2 shows "downloading from 0 of 0 peers" indefinitely.

Why torrent is downloaded fine for the first time and download does not happen if I remove/add the same torrent back?

Thanks in advance!

Attachments (1)

settings.json (1.9 KB) - added by trtrmitya 11 years ago.
My config file

Download all attachments as: .zip

Change History (5)

Changed 11 years ago by trtrmitya

My config file

comment:1 Changed 11 years ago by x190

trtrmitya: What does tcpdump say about LPD packets on the second attempt? How might this be a Transmission bug? This sounds like an issue that should be discussed in the forum.

comment:2 Changed 11 years ago by x190

Since there has been no additional info from the OP, IMO, this ticket can be closed--unless, of course, someone has already tested this and has an idea of what the problem is...

Last edited 11 years ago by x190 (previous) (diff)

comment:3 Changed 11 years ago by livings124

  • Resolution set to worksforme
  • Status changed from new to closed

I have not been able to reproduce this either. Adding/re-adding works fine. Please reopen with the info x190 suggested.

comment:4 Changed 11 years ago by x190

static int
getDefaultShelfLife( uint8_t from )
    /* in general, peers obtained from firsthand contact
     * are better than those from secondhand, etc etc */
    switch( from )
        case TR_PEER_FROM_INCOMING : return 60 * 60 * 6;
        case TR_PEER_FROM_LTEP     : return 60 * 60 * 6;
        case TR_PEER_FROM_TRACKER  : return 60 * 60 * 3;
        case TR_PEER_FROM_DHT      : return 60 * 60 * 3;
        case TR_PEER_FROM_PEX      : return 60 * 60 * 2;
        case TR_PEER_FROM_RESUME   : return 60 * 60;
        case TR_PEER_FROM_LPD      : return 10 * 60;
        default                    : return 60 * 60;

LPD peers do have a short shelf life, whatever effect that might have?

Note: See TracTickets for help on using tickets.