Opened 8 years ago

Last modified 8 years ago

#5391 new Bug

Seeders -

Reported by: SomeBloke Owned by: jordan
Priority: Low Milestone: None Set
Component: libtransmission Version: 2.80
Severity: Trivial Keywords: seeder, leecher, upload, speed
Cc:

Description

For what it's worth, I'm using Transmission 2.80 (14103) on a early 2008 MacBook? Pro, running mac OS X 10.6.8, build 10k549.

I am seeding (as opposed to downloading, so can't comment on whether a similar situation is occurring on that front) a number of torrents, the line at the bottom of the torrent reads -

Seeding to 0 of 2 peers - UL: 30.0KB/s

when the 0 should be at least 1.

Double clicking on the torrent, and going to the seeders section shows two leechers, neither of which is shown as having anything uploaded to them - the UL column is blank. Going to the activity section, the Uploaded value is going up at about the speed I would expect. On a torrent with only 1 leecher, the situation is the same.

Change History (27)

comment:1 Changed 8 years ago by livings124

  • Component changed from Mac Client to libtransmission
  • Owner changed from livings124 to jordan

comment:2 Changed 8 years ago by SomeBloke

Looking again this morning, one of the torrents being seeded has two leechers, one of whom is getting an upload figure in the UL column of the peers section of the torrent inspector. Both leechers are using the same version of the same torrent client as each other (BitTorrent? 7.8.0).

comment:3 Changed 8 years ago by SomeBloke

Additional information.

One of the seeding torrents is now showing the leechers correctly, and another torrent (with two leechers) is showing one of the leechers correctly.

comment:4 Changed 8 years ago by REReader

I'm seeing the same bug. I'm uploading, but the main window shows me seeding to 0 of 1 peer, and the info window doesn't show anything uploading, but the uploaded value is going up.

comment:5 follow-up: Changed 8 years ago by x190

Is this 10.6.8 specific? REReader, are you using 10.6.8?

https://forum.transmissionbt.com/viewtopic.php?f=4&t=14894#p65266

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

comment:6 in reply to: ↑ 5 ; follow-up: Changed 8 years ago by REReader

Replying to x190:

Is this 10.6.8 specific? REReader, are you using 10.6.8?

https://forum.transmissionbt.com/viewtopic.php?f=4&t=14894#p65266

I don't know if it's 10.6.8 specific, but yes, I am running OS 10.6.8.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 8 years ago by x190

Replying to REReader:

Replying to x190:

Is this 10.6.8 specific? REReader, are you using 10.6.8?

I don't know if it's 10.6.8 specific, but yes, I am running OS 10.6.8.

So far all reporters are on 10.6.8. livings, do you see this on 10.8 as well?

Can anyone reporting this issue find any relevant Console.app log messages?

comment:8 Changed 8 years ago by rb07

Its not Mac specific, its all over (a.k.a. libtransmission).

I'm looking at it on Linux, the status reported is idle while upload is not idle.

It happens to several torrents at a time, a subset of the active ones (from zero to less than all), and randomly changes from false info, to true info on a single torrent.

Also, perhaps related, I'm seeing "Seeding to 0 peer", when it should say "Seeding to 0 of 1 connected peers"; again not in all torrents, just some of them.

Anyone has bisected the nightly builds to see where the regression appeared?

-- Also may be related: after starting the daemon everything is fine, it takes a few minutes, and maybe a few additions/deletions to start misreporting.

Last edited 8 years ago by rb07 (previous) (diff)

comment:9 Changed 8 years ago by x190

#5393 may be related?

comment:10 follow-up: Changed 8 years ago by rb07

Doesn't look related.

  • The daemon doesn't get "stuck" at any time.
  • The seeders & leachers count is there, the wrong part is in the number of peers leaching for instance, it shows zero, when there are say 3, and active.

So the details on that report don't match.

I've tried reverting changesets, or just checking visually, no luck with 14079, 14080, 14081, 14083, 14088, 14089.

comment:11 in reply to: ↑ 10 Changed 8 years ago by x190

Replying to rb07:

I've tried reverting changesets, or just checking visually, no luck with 14079, 14080, 14081, 14083, 14088, 14089.

What do you mean, "no luck"? Do they exhibit this issue, or not? That is, do we need to go back before 14079?

comment:12 Changed 8 years ago by rb07

It meant "no luck finding the bug", and no, you don't have to go back to anything, just revert the changes (a job best suited for the developers since it is a repository operation, or what I'm doing, reversing the change).

So far, it seems that changeset 10483, introduced by the fix on #5294, contains the problem.

I haven't found where exactly, but reverting that changeset (and only that changeset) does fix the symptoms (test duration: 1h:48m).

A better clue for the developers: it seems that the peer flags are getting the wrong value, specifically I see peers downloading from me and their flags include the "u" flag: "they are interested but not downloading", the last part is not true.

Problem is that some peers have the correct flags, some don't. If all the peers connected to a torrent have the wrong flag, then the torrent appears as "idle", when its not.

comment:13 Changed 8 years ago by x190

Well, for one thing, Line 2495 in peer-msgs.c, looks a bit odd.

In webseed.c we have:

static const struct tr_peer_virtual_funcs my_funcs =
{
  .destruct = webseed_destruct,
  .is_transferring_pieces = webseed_is_transferring_pieces
};

while in peer-msgs.c we have:

static const struct tr_peer_virtual_funcs my_funcs =
{
  .destruct = peermsgs_destruct,
  .is_transferring_pieces = peermsgs_is_transferring_pieces,
};

Note the syntax difference (commas).

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

comment:14 Changed 8 years ago by rb07

That's just a harmless typo.

comment:15 follow-up: Changed 8 years ago by jordan

That's C's feature of designated initializers, not a typo :)

comment:16 Changed 8 years ago by x190

So your addition of the comma after "peermsgs_is_transferring_pieces" in r14083, line 2498 of peer-msgs.c, was a ('harmless'?) error?

Thanks for providing the technical term designated initializers .

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

comment:17 in reply to: ↑ 15 Changed 8 years ago by rb07

Replying to jordan:

That's C's feature of designated initializers, not a typo :)

The last comma is a typo, the notation is designated initializer but that was not the point.

comment:18 in reply to: ↑ 7 Changed 8 years ago by ranxerox

Replying to x190:

Replying to REReader:

Replying to x190:

Is this 10.6.8 specific? REReader, are you using 10.6.8?

I don't know if it's 10.6.8 specific, but yes, I am running OS 10.6.8.

So far all reporters are on 10.6.8. livings, do you see this on 10.8 as well?

Can anyone reporting this issue find any relevant Console.app log messages?

FWIW, I'm on 10.8.4, experiencing same issue (GUI reports e.g. seeding to 0 of 1 peer - UL: 90KB/s), no console messages. Only happens on some torrents. Peer responsible for bandwidth appears in inspector window.

comment:19 follow-up: Changed 8 years ago by jordan

Does this bug persist after r14108 ?

comment:20 in reply to: ↑ 19 Changed 8 years ago by rb07

Replying to jordan:

Does this bug persist after r14108 ?

No, looks good after some testing.

You may want to add a couple of prototypes to avoid these build messages:

  CC       peer-mgr.o
peer-mgr.c: In function 'tr_peerMgrOnTorrentGotMetainfo':
peer-mgr.c:2526:7: warning: implicit declaration of function 'tr_peerMsgsUpdateActive'
peer-mgr.c:2526:7: warning: nested extern declaration of 'tr_peerMsgsUpdateActive'
peer-mgr.c: In function 'tr_peerMgrPeerStats':
peer-mgr.c:2721:7: warning: implicit declaration of function 'tr_peerMsgsIsActive'
peer-mgr.c:2721:7: warning: nested extern declaration of 'tr_peerMsgsIsActive'
  CC       peer-msgs.o
peer-msgs.c:724:1: warning: no previous declaration for 'tr_peerMsgsIsActive'
peer-msgs.c:754:1: warning: no previous declaration for 'tr_peerMsgsUpdateActive'

comment:21 follow-up: Changed 8 years ago by jordan

rb07: I'm not seeing those warnings, and r14108 should already have those prototyped:

Could you check whether this is a local build hiccup on your end, or whether it's some issue in the repo that needs to be fixed?

comment:22 in reply to: ↑ 21 Changed 8 years ago by rb07

Replying to jordan:

Could you check whether this is a local build hiccup on your end, or whether it's some issue in the repo that needs to be fixed?

Oops! my mistake, I didn't replace those .h files, just everything else.

But you are right, I got the list of changed files from subversion, and the update didn't list those 2 headers... strange... and the files are not changed.

Last edited 8 years ago by rb07 (previous) (diff)

comment:23 Changed 8 years ago by rb07

It looks like an "issue with the repo that needs to be fixed".

I've just updated my copy, now at revision 14112, and those 2 headers have not changed.

Last edited 8 years ago by rb07 (previous) (diff)

comment:24 follow-up: Changed 8 years ago by rb07

The problem is on my side, since I reverted 14083 (on the release files, not the repository) that changed those headers.

Sorry for the noise.

Last edited 8 years ago by rb07 (previous) (diff)

comment:25 in reply to: ↑ 24 Changed 8 years ago by jordan

Replying to rb07:

Sorry for the noise.

I've been guilty of that so many times -- I've got no room to complain! :)

comment:26 Changed 8 years ago by REReader

FWIW, I thought this was fixed with the update to 2.81 (14128), but it happened again this afternoon--not on all torrents or all seeders, but some of them.

comment:27 Changed 8 years ago by x190

See also: #5428

Note: See TracTickets for help on using tickets.