Opened 6 years ago

Last modified 6 years ago

#5942 new Bug

Double reports under Transmission 2.7x 2.8x

Reported by: howl Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 2.84
Severity: Normal Keywords:
Cc:

Description

I have seen Transmission reporting badly sometimes some years ago but now a days is more easy to find someone who reports wrong.

First of all I thought that this way happening under embedded devices but at least one member is using Ubuntu 12.04 LTS.

This is one of the summaries I have generated:

63..  	30/Apr/2015:19:05:11 >	    0min · 3c10be7b  	started  0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
64..  	30/Apr/2015:19:32:58 >	   27min · 14438225  	         0 B          0 B ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
65..  	30/Apr/2015:19:35:20 >	    2min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
66..  	30/Apr/2015:20:04:11 >	   28min · 14438225  	         0 B          0 B ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
67..  	30/Apr/2015:20:05:15 >	    1min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
68..  	30/Apr/2015:20:33:11 >	   27min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
69..  	30/Apr/2015:20:34:11 >	    1min · 14438225  	         0 B     1.60 MiB ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
70..  	30/Apr/2015:21:03:11 >	   29min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
71..  	30/Apr/2015:21:06:32 >	    3min · 14438225  	         0 B    15.89 MiB ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
72..  	30/Apr/2015:21:32:59 >	   26min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
73..  	30/Apr/2015:21:36:18 >	    3min · 14438225  	         0 B    15.89 MiB ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
74..  	30/Apr/2015:22:02:17 >	   25min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
75..  	30/Apr/2015:22:07:15 >	    4min · 14438225  	         0 B    15.92 MiB ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
76..  	30/Apr/2015:22:30:01 >	   22min · 3c10be7b  	         0 B          0 B ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82
77..  	30/Apr/2015:22:38:42 >	    8min · 14438225  	         0 B    15.92 MiB ↑       0 B ↓ -TR2820-szkovpsuzw1z 	Transmission/2.82
78..  	30/Apr/2015:22:59:43 >	   21min · 3c10be7b  	         0 B    14.15 MiB ↑       0 B ↓ -TR2820-esfj1jul8w4p 	Transmission/2.82

As you can see there are two key and peer_id, one reports, then the other one... IP and port is the same, and also there is only one Transmission launched (don't know if more than one process spawns). If you need more info I will try to forward people who reports badly here.

It's not something usual, as it happens only sometimes in a small portion of the tracker members and the fix normally is closing and opening the Transmission but sometimes at least on embedded devices a complete restart is required.

I have only seen this over Transmission 2.7x and Transmission 2.8x.

Change History (11)

comment:1 Changed 6 years ago by howl

As you can see the key value and peer_id change all the time, the reports in the ticket description are from one with a NAS, so it seems that the embedded system could spawn two instances (could be an issue external to Transmission).

The reports from the member with Ubuntu 12.04 LTS are similar, but the key value remains the same all the time so the same Transmission instance is reporting twice in that case (this issue is internal to Transmission).

I will add the reports from Ubuntu 12.04 LTS as soon as possible.

comment:2 Changed 6 years ago by OlafS

Any updates?

comment:3 Changed 6 years ago by mike.dld

If it's not deliberate but accidental start of two daemons/clients then it could be dealt with (programmatically) by locking the config directory one way or another to prevent two instances from using the same settings/torrents. If OTOH the user starts two instances of daemon/client with different config directories, but then downloads torrents from same private tracker (with same access credentials) in both of them... that's an issue (from tracker point of view) I'm not sure how to resolve, or whether we need to.

As for the comment:1 update regarding Ubuntu, I'd very much appreciate more information.

comment:4 Changed 6 years ago by howl

Sorry, I was busy the days after the report and I forget about it. I have the issued torrent file that had the member inside transmission config and a newer downloaded one, have to check the differences between them, I hve to ask the member if removing and readding the torrent solved the issue as the offending torrent always reported bad even stopping it and closing reopening Transmission.

comment:5 follow-ups: Changed 6 years ago by howl

Here is the summary of the reports from Ubuntu:

04/May/2015:07:06:22 >	    0min · 97f5f6e  	started  0 B          0 B ↑       0 B ↓ -TR2840-blvyo3ycuaph 	Transmission/2.84
04/May/2015:07:06:22 >	    0min · 97f5f6e  	started  0 B          0 B ↑       0 B ↓ -TR2840-bsi20jgah3e6 	Transmission/2.84
04/May/2015:07:06:22 >	    0min · 97f5f6e  	started  0 B          0 B ↑       0 B ↓ -TR2840-um78sxysy1r0 	Transmission/2.84
04/May/2015:07:06:26 >	    0min · 97f5f6e  	started  0 B          0 B ↑       0 B ↓ -TR2840-cn5oa0on6z3f 	Transmission/2.84
04/May/2015:07:06:27 >	    0min · 97f5f6e  	started  0 B          0 B ↑       0 B ↓ -TR2840-m6926math8ez 	Transmission/2.84
04/May/2015:07:06:27 >	    0min · 97f5f6e  	started  0 B          0 B ↑       0 B ↓ -TR2840-ob045pmqn1gn 	Transmission/2.84
04/May/2015:07:36:07 >	   29min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-ob045pmqn1gn 	Transmission/2.84
04/May/2015:07:36:07 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-cn5oa0on6z3f 	Transmission/2.84
04/May/2015:07:37:26 >	    1min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-bsi20jgah3e6 	Transmission/2.84
04/May/2015:07:37:43 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-m6926math8ez 	Transmission/2.84
04/May/2015:07:38:37 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-um78sxysy1r0 	Transmission/2.84
04/May/2015:07:38:53 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-blvyo3ycuaph 	Transmission/2.84
04/May/2015:08:06:07 >	   27min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-ob045pmqn1gn 	Transmission/2.84
04/May/2015:08:06:20 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-bsi20jgah3e6 	Transmission/2.84
04/May/2015:08:06:51 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-um78sxysy1r0 	Transmission/2.84
04/May/2015:08:07:19 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-blvyo3ycuaph 	Transmission/2.84
04/May/2015:08:08:13 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-cn5oa0on6z3f 	Transmission/2.84
04/May/2015:08:09:29 >	    1min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-m6926math8ez 	Transmission/2.84
04/May/2015:08:34:52 >	   25min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-bsi20jgah3e6 	Transmission/2.84
04/May/2015:08:35:25 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-blvyo3ycuaph 	Transmission/2.84
04/May/2015:08:36:10 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-cn5oa0on6z3f 	Transmission/2.84
04/May/2015:08:36:38 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-um78sxysy1r0 	Transmission/2.84
04/May/2015:08:36:39 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-ob045pmqn1gn 	Transmission/2.84
04/May/2015:08:41:18 >	    4min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-m6926math8ez 	Transmission/2.84
04/May/2015:09:04:21 >	   23min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-blvyo3ycuaph 	Transmission/2.84
04/May/2015:09:04:56 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-ob045pmqn1gn 	Transmission/2.84
04/May/2015:09:05:05 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-um78sxysy1r0 	Transmission/2.84
04/May/2015:09:05:18 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-bsi20jgah3e6 	Transmission/2.84
04/May/2015:09:07:55 >	    2min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-cn5oa0on6z3f 	Transmission/2.84
04/May/2015:09:12:54 >	    4min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-m6926math8ez 	Transmission/2.84
04/May/2015:09:32:30 >	   19min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-ob045pmqn1gn 	Transmission/2.84
04/May/2015:09:33:26 >	    0min · 97f5f6e  	         0 B          0 B ↑       0 B ↓ -TR2840-um78sxysy1r0 	Transmission/2.84

As you can see the key remains always the same but the peer_id rotates between various values. Also the reports are done six times every 30 minutes aproximate. The tracker send a report time of 30 minutes and a little variation up and down for every torrent to prevent overload with member with hundreds of torrents.

Stopping and restarting the torrent didn't solved this, also closing and opening Transmission again didn't resolve this. The only way to solve it was deleting the torrent and adding it again.

The md5 hash of the .torrent file inside configuration directory of Transmission before removing it and the new one after adding it again are the same.

Edited: Sorry I cropped all the start events except one, now are all the start events.

One more edit: The stop events wasn't send ever when this happened before fixing it it by readding the torrent.

Last edited 6 years ago by howl (previous) (diff)

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

Replying to howl:

I have only seen this over Transmission 2.7x and Transmission 2.8x.

As you can see the key remains always the same but the peer_id rotates between various values. Also the reports are done six times every 30 minutes aproximate. The tracker send a report time of 30 minutes and a little variation up and down for every torrent to prevent overload with member with hundreds of torrents.

There was r13933 which took place 2.77. I honestly don't see how this could cause or affect what you are seeing. I'm assuming we are dealing with private torrents here? Anyway, r13933 should only affect public torrents by default every six hours.

But could you try as an experiment creating in the config's settings.json new values for, like

  • "peer-id-ttl-hours": 1,

plus as another experiment

  • "peer-id-ttl-hours": 100,

Then we can see if we are at all on the right track with any correlation with r13933 for leading to resolving the issue. I'd be much interested in seeing the results here, if you can.

.

.

The md5 hash of the .torrent file inside configuration directory of Transmission before removing it and the new one after adding it again are the same.

It might be that it's what is in the torrents .resume file is the cause. The individual keys' values and such would need to be analyzed for discrepancies. md5 hash won't work on the .resume file. It can change for various reasons. The problem also might be in running transmission's internal variables and therefore not accessible to the user. A restart of transmission would clear those.

...also closing and opening Transmission again didn't resolve this. The only way to solve it was deleting the torrent and adding it again.

This indicates to me it's got to be in the .resume file.

The stop events wasn't send ever when this happened before fixing it it by readding the torrent.

Are you saying that when an offending torrent is paused/stopped no stopped event is ever sent?

The reports from the member with Ubuntu 12.04 LTS are similar,...

Is Ubuntu 12.04 LTS installed or run from the cd? I wonder if that could make a difference.

Last edited 6 years ago by cfpp2p (previous) (diff)

comment:7 Changed 6 years ago by OlafS

How does the client distinguish between public and private trackers? Via the private flag in the .torrent?

comment:8 in reply to: ↑ 5 Changed 6 years ago by mike.dld

Replying to howl:

As you can see the key remains always the same but the peer_id rotates between various values. Also the reports are done six times every 30 minutes aproximate. The tracker send a report time of 30 minutes and a little variation up and down for every torrent to prevent overload with member with hundreds of torrents.

I see Transmission having 6 torrents, with each torrent having its own peer ID, announcing periodically. What exactly is wrong with the log provided?..

comment:9 in reply to: ↑ 6 Changed 6 years ago by howl

Replying to cfpp2p:

Will try to do the test by myself as it's going to be more difficult if i'm an intermediate between this ticket and another person.

Replying to mike.dld:

Replying to howl:

As you can see the key remains always the same but the peer_id rotates between various values. Also the reports are done six times every 30 minutes aproximate. The tracker send a report time of 30 minutes and a little variation up and down for every torrent to prevent overload with member with hundreds of torrents.

I see Transmission having 6 torrents, with each torrent having its own peer ID, announcing periodically. What exactly is wrong with the log provided?..

I don't know how you can see Transmission having 6 torrents as I haven't publish the announce url because it's a private torrent. The announce url is the same for all the reports, only one Transmission instance, only one entry for that particular torrent but multiple reports for the same torrent take place. So yes that it's wrong, but not the log, Transmission reporting.

There is no bug in the tracker related to this because this log has been recreated grepping the Web server's access log to discard that possibility.

Last edited 6 years ago by howl (previous) (diff)

comment:10 Changed 6 years ago by x190

"only one entry for that particular torrent but multiple reports for the same torrent take place."

How do you know that the user is not running multiple instances of the daemon, either purposely or due to a misconfigured system?

comment:11 Changed 6 years ago by howl

The problem persisted between program close, machine reboots... until the removal and readd of the particular torrent. Only one torrent did that kind of reports while the other torrents added in Transmission where reporting right all the time.

My fault not to have asked for the pstree output to the Ubuntu member (the pstree output I have is from an embedded device that's why in that situation I know is kind a problem with the firmware perhaps with the init script not related to Transmission itself), I only asked for screenshots of the information and trackers tabs to discard multiple announce lines.

The way he launch Transmission is with the Ubuntu's shortcut, so I doubt about configuration or multiple instances, at least if that would happen only one time.

Note: See TracTickets for help on using tickets.