Opened 13 years ago

Closed 10 years ago

Last modified 10 years ago

#3063 closed Bug (invalid)

Torrent ids change upon restart

Reported by: mechanic Owned by:
Priority: Normal Milestone: None Set
Component: Transmission Version: 1.92
Severity: Normal Keywords:


The torrent id can change when transmission is restarted. The torrent id appears to be an integer specifying the torrent count since transmission started. This can be problematic for users of the rpc interface.

Here's a scenario. If transmission has been running for a while and the number of torrents is at 500, but the oldest 100 have been removed, the remaining torrents have ids 101-500. I make a request to get information about torrent id 101. Transmission gets restarted and the torrents now have ids 1-400. I make a change to torrent id 101 using the information I retried before the restart, but the id now points to a different torrent.

I'm going to be using the torrent hash from now on, but either the docs need to warn about this, or ids should be persistent.

Change History (8)

comment:1 Changed 13 years ago by charles

This has been documented for a long time.

1077	/**
1078	 * @brief Returns this torrent's unique ID.
1079	 *
1080	 * IDs are good as simple lookup keys, but are not persistent
1081	 * between sessions.  If you need that, use tr_info.hash or
1082	 * tr_info.hashString.
1083	 */
1084	int tr_torrentId( const tr_torrent * torrent );

comment:2 Changed 13 years ago by charles

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

comment:3 Changed 13 years ago by mechanic

The source code is not documentation for people using the RPC interface. The spec should include the warning.

comment:4 Changed 13 years ago by charles

Note the `source' references in the spec that refer readers back to the details in transmission.h

comment:5 Changed 10 years ago by fguillen

But using the "tr_info.hash" or "tr_torrent.hashString" is not a solution because it can't be used them to "get" a torrent information due the "id" is the only way we can call the method "torrent-get".

As I said in the issue:

My application is trying to refresh the information of a torrent, let's say the torrent "101", but transmission is getting me back the information of another torrent because this "id" is now owned by other different torrent.

Using the "hash" or "hashString" would be a solution if the api methods are able to receive this values as the identifier of the desired torrent.

comment:6 Changed 10 years ago by fguillen

  • Resolution invalid deleted
  • Status changed from closed to reopened

I think this "ticket" should be "reopened", if we can't trust in the "id" as an UID for each torrent then all the commands those use this paramater as identifier become useless.


  • ID should be permanent and never repited
  • User another identifier for the API commands like the "hashString"

comment:7 Changed 10 years ago by jordan

  • Resolution set to invalid
  • Status changed from reopened to closed

See section 3.1 of the spec, using the hashString as an identifier has been supported forever.

comment:8 Changed 10 years ago by fguillen

You're completely wright, I misunderstood the documentation.

Note: See TracTickets for help on using tickets.