As of right now rTorrent and from_rTorrent make the custom1, custom2, ..., custom5 rTorrent fields available for setting and returning. However, these rTorrent fields are fairly limited. Because of that... they are pretty much always already used by rTorrent plugins or ruTorrent (for example ruTorrent already uses all of these fields!). So while having them available for retrieving and setting is helpful, they can't really be used for an end user's custom purposes.

However, rTorrent has come up with a solution to that problem by introducing named custom attributes. The named custom attributes can be set and retrieved as described in the documentation here.

So I was thinking it would be super helpful to be able to set and retrieve named custom attributes to give flexget and rTorrent the most flexibility.

I was thinking something along the lines of the following:

• The plugin structure/options would not change from its current state other than adding new attributes for the rTorrent plugin (for setting the new named custom attributes)
• if a field starts with namedCustom- then the backend code would treat this as a named custom attribute and handle it accordingly.

For example, if on the from_rTorrent plugin I provide a field entry with the value of namedCustom-mySuperSpecialAttribute, the backend code would call the following rTorrent method to get the value:

d.custom=mySuperSpecialAttribute

and make that available via a jinja substitution just like any other rTorrent field: {{namedCustom-mySuperSpecialAttribute}}

Additionally, the rTorrent plugin could set the named custom attribute with the following rTorrent code:

d.custom.set=mySuperSpecialAttribute,foo

The only thing I am not sure of is if flexget allows for "wildcard" options. Basically say any option to the rTorrent plugin that starts with namedCustom- The the rTorrent plugin could just take in named custom fields directly like any other option:

rTorrent:
  uri: scgi://localhost:5000
  namedCustom-mySuperSpecialAttribute: foo