Opened 5 years ago

Last modified 3 years ago

#5552 new Enhancement

Additional filters like 'recently-active'

Reported by: eirnym Owned by: jordan
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.82+
Severity: Normal Keywords:
Cc:

Description

I want to share my patch for additional filters which I use for several years. This patch is for trunk, but easily adoptable for stable versions. I add patch only for libtransmission, because I don't use GUI and it doesn't need it.

Attachments (1)

rpc-sugar.diff (7.0 KB) - added by eirnym 5 years ago.
some sugar for command-line and RPC clients

Download all attachments as: .zip

Change History (7)

Changed 5 years ago by eirnym

some sugar for command-line and RPC clients

comment:1 Changed 5 years ago by cfpp2p

Thanks for sharing. Always good to sweeten things up a bit! Patch looks good and should prove useful.

comment:2 Changed 5 years ago by eirnym

No activity about this ticket. Is this patch not useful? I met here some enchantment tickets which has been opened for years and outdated with comments "very useful". If fate of this ticket will be same, I'll remove patch and close it.

comment:3 Changed 5 years ago by jordan

So there are two parts that need responding to.

One, the general lack of activity in trac is more about the developers all having more demanding day jobs now. This is no excuse for six months of silence, though; livings or I should have responded to the ticket sooner. Sorry about that.

Two, as to the ticket/patch itself.. I guess I'm unsure what problem these filters set out to solve?

The basic assumption for the 'recently active' filter is that the client app probably has all the torrents' static info and state info somewhere in the client app's memory, so a ping asking "hey, which torrents' states have changed lately?" is a simple way of periodically updating that state info without having to re-query /all/ the torrents.

If that model holds true, then the client app already knows which torrents are downloading, which are seeding, which are paused, etc -- so there's no point in a round trip to the daemon to ask for this info.

The other model I'm aware of is the single-shot client such as transmission-remote, where the user might well say something like "tell me what torrents are seeding, then exit." In this case, the RPC could call torrent-get with the relevant keys, then print out the ones whose states match the needed criteria. True, this requires that the single-shot client pull info for /all/ the torrents, but since we're talking about a single-shot I don't see much harm in this.

So that being said, I need help to understand the use case for these extra filters.

comment:4 Changed 5 years ago by eirnym

One, the general lack of activity in trac is more about the developers all having more demanding day jobs now.

I do same, everyone who make open source do.

Two, as to the ticket/patch itself.. I guess I'm unsure what problem these filters set out to solve?

Please, don't hesitate to ask. The silence is the worst way to ask questions.

About patch itself.

Little bit about background:

I don't use GUI/Web, because of security reasons and resource consumption. I have bunch of scripts which help me to output the results. This patch has been started when I tied to grep out states (firstly I needed "verify" tag). Then I've found that patched version gives results much faster than grepping them (also any client has much less information, than needed, later I'll share some patches).

This patch extend meta-tags of torrents which you want to see in the output.

Meta-tags description:

All of them are documented in code.

original:

"all" — all torrents at all. "recently-active" — all torrents which has activity in the last time

added:

"verify": all torrents in verify or waiting for verify state. “running”: all torrents which are marked as “active” (difference with recently-active is there’s may be no activity for hours/days/weeks) “paused”: I haven’t finished, and want to continue “done”: Torrent has been downloaded “stopped”: Torrent has been downloaded and stopped “idle”: Torrent is running but idle (no activity) “downloading”: Torrent is not finished and running. “leech”: I’m leech (l&s included) “seeding”: I’m seeder (l&s included) “error”: Torrent has error “gone”: Torrent permanently gone from tracker. “warn”: Torrent has warnings from server “healthy”: Fine torrents with no errors/warnings

comment:5 Changed 5 years ago by eirnym

I mentioned some dead useful patches I want to refresh up to the current Transmission version: #2175

comment:6 Changed 3 years ago by eirnym

Why I have create these patches and why I want to apply to Transmission.

In the beginning I wanted to filter several categories like ‘finished’, ‘not finished’, and ‘error’ to check if I moved files without notifying transmission-daemon and checking several statuses. Later I found that RPC works very slowly on fast computer and I wanted to move these checks into server. After this I found that several categories can’t be distinguished on client, but can be on server and protocol is sucks. I have some more patches to make protocol more robust and better, but I’ll push these patches after this one.

So there some technical details:

The Transmission RPC protocol doesn't give match to work with and it doesn’t give match of information. To emulate most of categories on client with current RPC protocol, I need:

  • I have to download current list with torrents summary
  • I have to download information about ALL torrents on server
  • I have to filter several fields from
  • I have to recalculate header and footer once again

This is really pain because:

  • not all information I need I can find in entire protocol
  • all sizes are converted to strings on server, like “100.0 MB” which is not strictly correct for 104878080 bytes file (sometimes I need it in this way)
  • all speeds are converted to strings like “2.9M/s"
  • some information you can find only in summary, some in detailed information about specified torrent
  • recalculation of footer (total line) is suboptimal because I have to make recalculation myself
Note: See TracTickets for help on using tickets.