1,3x: Session Transfer Vs Actual Download (Fixed in 1.40)

[3kot]

bump

[Clayton]

Same problem here, I had to switch back to 1.22.

I'm still on Tiger.

[jeeepeee]

Same problem here, for me the problem mainly is visible on really large torrents, 1Gb>
Hope you find the reason of this problem.

Regards, Jan

[Toby]

*bump*

Any news on this bug?

It doesn't look like it's in the trac system, should I submit it? Because the How to Report a Bug topic mentions no such thing.

[Toby]

Ok, I submitted it to trac:
http://trac.transmissionbt.com/ticket/1305

Hopefully it gets fixed by the next release! This has been bothering me for a while now.

[alison87]

Thanks Toby!

I decided to try test out this problem again, sacrificing a chunk of my 10GB/month bandwidth!

It looks like the symptoms are:

1. Download speed "appears" normal (e.g. 40kB/s on my 512kbps connection)
2. Estimated time of completion is estimated based on the current download speed
3. Actual time of completion is much, much later (the estimated time keeps readjusting backwards)
4. Session download increases as expected, but torrents themselves don't appear to be getting the expected data
5. This isn't getting listed as discarded pieces on the torrent ("Failed DL") or even in the "Downloaded" or "Have" lists ("verified" or otherwise)

E.g. today, i've downloaded 1 gig according to the session transfer, but in total the two torrents i had going are only at 600 meg combined.

Possible causes:

1. The session transfer is being reported incorrectly (as far as i can tell, not the case because i am downloading that much according to my ISP's count)
2. The have or downloaded total is being reported incorrectly (clearly not the case or the files would be on my hard disk and not still downloading)
3. The discarded total is being reported incorrectly (this is POSSIBLE, but i find it hard to believe that suddenly tens of thousands of peers are sharing bad data)
4. The background protocol traffic has dramatically increased in the last few months (again, seems very hard to believe)
5. Somehow Transmission is throwing away data that it shouldn't be.

Number 5 is what we think is happening. My best guess is that somehow it's downloading duplicate pieces from different clients and then throwing the duplicates away when it realizes it already has it. Though surely that should at least be reported in the discarded total?

[alison87]

See also here: http://forum.transmissionbt.com/viewtop ... f=4&t=6085 and here: http://forum.transmissionbt.com/viewtop ... f=4&t=5946

This isn't just an isolated problem any more. It doesn't happen on Vuze so it's not a poisoned torrent issue. Somehow Transmission is downloading data it shouldn't be, or throwing away data it shouldn't be. I've blown my limit for the month trying to figure this out, i've had the debug log on for several torrents and it's not showing anything interesting. In the log i see stuff like:

2008-10-01 08:22:37 +1000 inout.c:275 [Debug] XXXXXXXX: piece 642 hash check: OK
2008-10-01 08:21:33 +1000 inout.c:275 [Debug] XXXXXXXX: piece 180 hash check: OK
2008-10-01 08:19:37 +1000 inout.c:275 [Debug] XXXXXXXX: piece 548 hash check: OK
2008-10-01 08:19:04 +1000 inout.c:275 [Debug] XXXXXXXX: piece 540 hash check: OK
2008-10-01 08:17:50 +1000 inout.c:275 [Debug] XXXXXXXX: piece 604 hash check: OK

I've tried sorting the log by message and it's not showing the same pieces getting checked twice, so whatever the problem is must be happening before this message gets printed out.

[McFly3]

Same here for me. There are no piece checksum error either.

[DESERTmonkey]

I've been getting all the same issues...

I just noticed I'm connected to a large number of people that I'm downloading from at a speed of 0.0k - obviously this connection is still being managed so maybe its an issue of connecting to peers and wasting bandwidth sustaining the connection with them when we're not actually downloading off them. Which if the Session Transfer includes the data used in the protocols to transfer between peers it would explain why it's reporting such a high number and why we're not getting the files we want in a timely fashion.

[sickmate]

I hadn't noticed this, but testing just now I'm getting the same issue.
Upload transfer seems to update correctly, but download transfer increases more than it should.

[leolun]

I'm having the same issue, I've tried almost everything, updating block list, prefering encrypted files, reducing the ammount of peers conected. This issue its pretty annoying. I left my computer over the night to download a 100Mb torrent, and by the morning it was at 70% and the session said it downloaded almost 700Mb. Its pretty rediculous, Im not even bothering with bigger torrents. Vuze sucks btw lol

[Darrin]

I've also registered to add a 'me too' to this issue

I'm running 1.34 (6770)

I just finished a 1.37GB download, which my ISP has me downloading 6GB . . .

Going back to 1.22

[kazee]

Hey all, this is indeed a bug. Nothing is wrong with your connection or you Mac. I realised this sometime ago with torrents taking much longer to download than expected despite coming in at full speed. Reverting to 1.22 fixed those issues for me.

[nwatts88]

Hey gang. I'm having the same issue everyone else is. Quick question though: a few of you said you reinstalled version 1.22. Can I also do this whilst I'm in the middle of a 4gb transfer? Or will my progress be lost? Thanks.

[Toby]

You can downgrade safely, your progress shouldn't be lost. I downgraded from 1.33 to 1.22, back to 1.34 (to see if this bug was fixed,) and then back again to 1.22, and my data is fine.