Opened 11 years ago

Closed 4 years ago

Last modified 4 years ago

#2581 closed Enhancement (fixed)

RPC extended to manage tracker lists

Reported by: Grug Owned by: Longinus00
Priority: Normal Milestone: 2.10
Component: libtransmission Version: 1.76
Severity: Normal Keywords:
Cc: ian@…, elsdoerfer@…

Description

The RPC should be extended to manage the list of trackers for each torrent as can be seen in the GTK client.

This would be extremely useful for mass updating via scripting the remote.

Having taken a look at it, the GTK code takes the list of trackers after editing and runs them through tr_torrentSetAnnounceList() which checks for invalid trackers (bad URL's and duplicates) erroring if necessary.

I see two ways to implement this:

  1. Add an "announceList" argument to the "torrent-set" RPC command, sending the entire updated list of trackers from the remote client via the RPC (exactly as is done by the GTK client).

Pros:

  • Minimal changes to the RPC

Cons:

  • Each client needs to manage an add and remove command and parse the list which the daemon does already
  • The entire list of trackers needs to be transmitted to the RPC. Seems like overkill.
  1. Add "announceAdd" and "announceRem" arguments to the "torrent-set" RPC command.

Pros:

  • All the "work" done in the daemon
  • Less possibility of clients getting out of sync

Cons:

  • Additional commands and parsing inside the RPC code.
  • More possibility of sending error messages back and forth (errors not trapped client-side)

Personally, I'm tending towards the first option (and have started a patch), but I'm interested in people's opinions.

Attachments (2)

tracker-edit-rpc.patch (1.7 KB) - added by Elbandi 11 years ago.
implement the option 1
tr_rpcTracker.patch (10.0 KB) - added by Longinus00 10 years ago.
new draft

Download all attachments as: .zip

Change History (24)

comment:1 Changed 11 years ago by charles

  • Version changed from 1.76+ to 1.76

comment:2 Changed 11 years ago by Elbandi

Vote to option 2.

But charles is the judge ;)

comment:3 follow-up: Changed 11 years ago by shiki

Not sure if I'm writing this into the right place. I'd like to add a vote for this 'feature'. More precisely, I want to have a 'chance' to edit the tracker list from the web client. (Sorry if I wrote this to a totally different place, but I didnt want to open a duplicate report. Just delete my 'comment' if its a bother. Ty.)

comment:4 in reply to: ↑ 3 Changed 11 years ago by Grug

Replying to shiki:

I want to have a 'chance' to edit the tracker list from the web client.

I have recently been working on the web client and was wanting to add this feature (although for myself, more importantly to the remote client for scripting). However, before it can be put into any remote client, there needs to be an interface in the RPC to connect to.

So yes, it will arrive in the remote clients, but only after the backend is coded, and that won't be until after 1.80 (at this stage).

comment:5 Changed 11 years ago by shiki

Anyway, thanks for the reply. Then it will be added soooome time later. That's already good enough. :) I'll wait for that feature... and.. keep up the good work. Ty again.

Changed 11 years ago by Elbandi

implement the option 1

comment:6 Changed 11 years ago by charles

  • Component changed from Transmission to Daemon
  • Owner set to charles
  • Status changed from new to assigned

comment:7 Changed 10 years ago by Longinus00

I prefer option 2. I also think there should be rpc calls for renaming a tracker and setting its tier.

comment:8 Changed 10 years ago by Elbandi

trackers[i].tier = trackers[i-1].tier + 1;

This will crash, if the torrent hasnt tracker yet (all tracker is removed). Second. some tracker link may have the same tier. (eg, ballanced tracker: tr1.domain.com, tr2.domain.com)

comment:9 Changed 10 years ago by Longinus00

Yup, I realized that not long after I uploaded it but was too tired to fix it. :(

comment:10 Changed 10 years ago by charles

charles * r10826 libtransmission/torrent.c: (trunk libT) #2581 "RPC extended to manage tracker lists" -- add safeguards in tr_torrentSetAnnounceList() to handle the case of tracker arrays not being sorted by tier.

comment:11 Changed 10 years ago by Longinus00

  • Component changed from Daemon to libtransmission
  • Milestone changed from None Set to 2.10
  • Owner changed from charles to Longinus00
  • Status changed from assigned to new

Changed 10 years ago by Longinus00

new draft

comment:12 Changed 10 years ago by Longinus00

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

Fixed by r10906.

Last edited 10 years ago by Longinus00 (previous) (diff)

comment:13 Changed 10 years ago by elsdoerfer

  • Cc elsdoerfer@… added
  • Resolution fixed deleted
  • Status changed from closed to reopened

I'd also like to see the ability to edit the tracker list through the web interface, and I'd be willing to implement this. However, I prefer the ability to paste a custom list of announce urls, like I can do in the GTK app (I also believe that this is the superior interface: this is a feature for advanced users who will have no problem editing a list of urls, and it seems to me that requiring three buttons in the GUI (add, edit, delete) not only increases implementation cost, but also makes using the UI less efficient if multiple changes are necessary. In other words, the GTK client gets the UI exactly right).

As such, I'm not happy with how this API turned out, and I hope I'm not breaking protocol by reopening the ticket. As it stands now, implementing an "edit tracker list" feature requires any client to diff the existing tracker list with the new one provided by the user, and send the proper trackerAdd/trackerRemove requests. That's a lot of work considering that the backend has tr_torrentSetAnnounceList ready for use.

Why not keep the current API for those clients which prefer to use them, and provide a trackerSetList option as well, for clients which prefer to go with an UI similar to the GTK client. I wouldn't see this as duplication, but as two distinct pieces of functionality to change the same piece of data - the latter having at least the same validity as the former (again, I would point to the GTK interface - someone must have made a conscious design decision to go with a single "Edit Trackers" button instead of separate Add/Edit/Remove? buttons, and, as I've already stated, I believe it was the right one).

comment:14 Changed 10 years ago by Longinus00

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

There isn't a current API, the gtk client messes around with the internals of transmission.

To accomplish what you want just delete the whole tracker list and send over a new one. (This is exactly what the gtk client does btw.)

Last edited 10 years ago by Longinus00 (previous) (diff)

comment:15 follow-up: Changed 10 years ago by charles

Longinus00: it reads to me that elsdoerfer is referring to tr_torrentSetAnnounceList(), which might be useful over RPC. I think that would belong in a new ticket rather than this one. Also I don't know what "messes with the internals" refers to.

comment:16 in reply to: ↑ 15 Changed 10 years ago by Longinus00

Replying to charles:

Longinus00: it reads to me that elsdoerfer is referring to tr_torrentSetAnnounceList(), which might be useful over RPC. I think that would belong in a new ticket rather than this one. Also I don't know what "messes with the internals" refers to.

By "messes with the internals" I mean it interacts with libtransmission directly rather than through something like rpc calls. I don't see the advantage of exposing tr_torrentSetAnnounceList when removing and adding trackers does the same thing.

In regards to replicating the gtk client's current method of editing trackers, I don't see any real benefit to it vs. the interface used in the mac/qt client. The only current benefit is that it's easy to add multiple trackers at once but that can be done in the qt interface if the add dialog used a multi-line textfield.

comment:17 Changed 10 years ago by elsdoerfer

I didn't realize that trackerAdd/trackerRemove both allow making multiple changes in one call. While completely replacing the list that way smells a bit like a hack to me, it's probably good enough™.

Something that's maybe worth mentioning though: the "backup tracker" functionality (which I have never used, and have to guess the purpose of), which apparently is not available through RPC at this point. An API backed by tr_torrentSetAnnounceList would make it available by sending a properly formatted list of trackers.

comment:18 Changed 10 years ago by Longinus00

Being able to designate tiers and backup was originally in the rpc calls but was removed because they have very limited purpose.

comment:19 follow-up: Changed 4 years ago by Bachsau

  • Resolution fixed deleted
  • Status changed from closed to reopened

Will this ever be implemented? I can see all trackers in web interface but I still can't find any way to edit them.

comment:20 in reply to: ↑ 19 Changed 4 years ago by mike.dld

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

Replying to Bachsau:

Will this ever be implemented? I can see all trackers in web interface but I still can't find any way to edit them.

This ticket is about RPC, not web interface, and it has been fixed. Create a new ticket if you want to add something to web interface. Better yet, provide a patch which does what you need.

comment:21 follow-up: Changed 4 years ago by Bachsau

Ok. Didn't know its in RPC yet. I think I will be able to add it to the web interface then and send you a patch.

comment:22 in reply to: ↑ 21 Changed 4 years ago by x190

Replying to Bachsau:

Ok. Didn't know its in RPC yet. I think I will be able to add it to the web interface then and send you a patch.

Here's the ticket for that.

https://trac.transmissionbt.com/ticket/3652

Note: See TracTickets for help on using tickets.