Persistent d.views Double-Nesting Issue (e.g., [[string]] instead of [string])

[ranirahn]

I am experiencing a persistent and unusual bug in rTorrent's view management, where view names appear as [[string]] (a list containing a list with a string) instead of the expected [string] (a list containing a string).

Problem Description:
When querying d.views (or similar view-related commands), view entries are incorrectly nested. For example, instead of [rat_0], the output consistently shows [[rat_0]]. This affects the usability of various view-dependent functions and the rutorrent.

Context & Reproduction History:
This issue first appeared after I enabled and used the extratio plugin in rutorrent. The extratio plugin uses view.set_visible and d.views.push_back_unique (or similar commands) to manage custom ratio views like "rat_0", "rat_1", etc.

Key Observations:

The bug appears to stem from rTorrent's internal handling of adding a single string (representing a view name) to a list. It incorrectly wraps the string in an additional list.

Even after disabling and completely deleting the extratio plugin directory, manually correcting all affected session files (by editing the bencode to remove the double nesting), and recompiling rTorrent from source, the problem reappears.

This suggests that once a view name (like "rat_0") has been introduced via the problematic path, rTorrent's own internal initialization or view recreation logic subsequently re-introduces the double-nesting every time it processes these views upon startup or torrent loading.

Hypothesized Root Cause:
The issue likely lies within rTorrent's core C++ code for handling Object types, specifically when a TYPE_STRING is intended to be added directly to a TYPE_LIST (such as d.views). It appears an insert_back or similar list manipulation function might be incorrectly treating a singular string as if it were already a list to be nested, or it's implicitly creating an extra list layer around the string.

Potentially Relevant Source Files (from user's observations and prior debugging attempts):

object.h (specifically Object::insert_back, TYPE_STRING, TYPE_LIST definitions and their interactions)

download_wrapper.h

download_constructor.h

common.h

option_strings.h

Impact:
The persistence of this error, despite thorough user-side troubleshooting (plugin removal, session file correction, recompilation), indicates a fundamental bug in rTorrent's view management that currently has no user-side workaround.

If anyone have any idea what I can do about this problem?

[rakshasa]

torrent::Object
d_list_push_back(core::Download* download, const torrent::Object& rawArgs, const char* first_key, const char* second_key) {
  download_get_variable(download, first_key, second_key).as_list().push_back(rawArgs);

  return torrent::Object();
}

torrent::Object
d_list_push_back_unique(core::Download* download, const torrent::Object& rawArgs, const char* first_key, const char* second_key) {
  const torrent::Object& args = (rawArgs.is_list() && !rawArgs.as_list().empty()) ? rawArgs.as_list().front() : rawArgs;
  torrent::Object::list_type& list = download_get_variable(download, first_key, second_key).as_list();

  if (std::none_of(list.begin(), list.end(), [args](const torrent::Object& obj) { return torrent::object_equal(obj, args); }))
    list.push_back(rawArgs);

  return torrent::Object();
}

If a string is pushed then it should work correctly, so there's likely a bug in your plugin.

Probably should replace the get rid of the special handling of lists, and instead provide a list unwrapping command.

[ranirahn]

I activated xmlrpc.log and this is what I see. If I dont even use rutorrent just php script running from terminal.

 71:CONTENT_LENGTH 268 CONTENT_TYPE text/xml SCGI 1 UNTRUSTED_CONNECTION 0 ,<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>d.views.push_back_unique</methodName><params><param><value><string>6E03C306F60420A4BD651DDEC601B654A4A0BAC8</string></value></param><param><value><string>rat_0</string></value></param></params></methodCall>
---
 Status: 200 OK
Content-Type: text/xml
Content-Length: 111

<?xml version="1.0"?><methodResponse><params><param><value><i8>0</i8></value></param></params></methodResponse>
---
 71:CONTENT_LENGTH 203 CONTENT_TYPE text/xml SCGI 1 UNTRUSTED_CONNECTION 0 ,<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>d.views</methodName><params>
<param><value><string>6E03C306F60420A4BD651DDEC601B654A4A0BAC8</string></value></param>
</params></methodCall>
---
 Status: 200 OK
Content-Type: text/xml
Content-Length: 209

<?xml version="1.0"?><methodResponse><params><param><value><array><data><value><array><data><value><string>rat_0</string></value></data></array></value></data></array></value></param></params></methodResponse>
---
 71:CONTENT_LENGTH 119 CONTENT_TYPE text/xml SCGI 1 UNTRUSTED_CONNECTION 0 ,<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>session.save</methodName><params>
</params></methodCall>
---
 Status: 200 OK
Content-Type: text/xml
Content-Length: 111

<?xml version="1.0"?><methodResponse><params><param><value><i8>0</i8></value></param></params></methodResponse>
---
 71:CONTENT_LENGTH 203 CONTENT_TYPE text/xml SCGI 1 UNTRUSTED_CONNECTION 0 ,<?xml version="1.0" encoding="UTF-8"?><methodCall><methodName>d.views</methodName><params>
<param><value><string>6E03C306F60420A4BD651DDEC601B654A4A0BAC8</string></value></param>
</params></methodCall>
---
 Status: 200 OK
Content-Type: text/xml
Content-Length: 209

<?xml version="1.0"?><methodResponse><params><param><value><array><data><value><array><data><value><string>rat_0</string></value></data></array></value></data></array></value></param></params></methodResponse>
---
 

am I sending the call wrong?

[rakshasa]

Is this with xmlrpc-c or tinyxml?

[rakshasa]

Has it been confirmed to work / not work with xmlrpc-c?

[stickz]

Has it been confirmed to work / not work with xmlrpc-c?

It's worse with xmlrpc-c than tinyxml2.

[anthonyryan1]

It's worse with xmlrpc-c than tinyxml2.

Can you elaborate on that, in which particular ways it's worse? What specific differences in behaviour did you see.

[stickz]

It's worse with xmlrpc-c than tinyxml2.

Can you elaborate on that, in which particular ways it's worse? What specific differences in behaviour did you see.

The ratio plugin is broken on xmlrpc-c. On tinyxml2 only the extratio and throttle plugins are broken on ruTorrent.

[ranirahn]

When I did my tests, then I did them with rtorrent 0.9.8 that runs on xmlrpc-c and rtorrent 0.15.4 and 0.15.5 that runs on tinyxml2. I did not test rutorrent plugins because that was not important. What I did see was that xml command send string, but in session file the change get always saved as nested list. And that is the problem. If its nested you cant change that with xml command anymore because rtorrent does not see this at all. It thinks there is no element at all and just add new element. So every time I send new xml command to change or add or delete this element it does not delete it but add new one so at some point there was 9 or more elements in session file and none of them rtorrent was to delete or change it. Only way for now is to fix the session files directly with a script. And then can send xml commands once and then the element is nested again. I dont think I have anything else to test about this issue. Inside rtorrent I could not find any place where this string type gets changed to list type. But that is exactly how it works right now. Only thing I was thinking to do is to add some check that it would be string type when adding this ratiogroup there, but I dont know if its maybe break something else so I dont want to touch rtorrent code yet.

[rakshasa]

It's finally summer weather here, and already have the ipv6 issue to fix first.

Current plan is to reproduce the errors in unit tests, and possibly add a custom handler in the session file loader to fix invalid d.views values.

[ranirahn]

I also have little free time now so if I can somehow help or make some tests, let me know.

[rakshasa]

I meant I'm not spending much time writing code the next week or two.

[rakshasa]

Branch fix/download-views has stricter checks on the arguments to d.views.push_back*.

Test it with logging, I want to know if it properly throws errors during the calls. (which would indicate lists are being passed to the commands.

[ranirahn]

I compiled this branch and rutorrent show me libtorrent and rtorrent is version 0.15.4 with this install. What I see now is I can change the ratiogroup and it looks like it changed and at some point it reset the ratiogroup back to original. I don't see any changes in session files.

Changed ratiogroups on rutorrent and then did session.save from terminal and then this info get saved to session file and its permanent change so its probably rutorrent issue why its not saving that info to file right now but at least I see values in right format when I save it to the file.

did not find any errors in logs, but I can send the logs if you want, but in my view this fixed the problem.

[rakshasa]

The master branch hasn't been updated to the latest version number, so that isn't relevant.

As for being fixed, it probably needs more testing as this might just have hidden the issue. (or fixed it, hard to tell as of now)

Looking at the code we might not be properly dumping errors to log, not entirely sure, so could you send/post the relevant logs. It should include the dump for the call and if it fails there should be no reply dump.

[rakshasa]

Got sent a log, and all calls to d.views.* look ok, so merging this after adding some tests.

[rakshasa]

I'll backport the fix to stable branch and make a new release, however I've only gotten one confirmation that this fixes the issue.

[drrako]

It seems to be working for me as well. 👍

[rakshasa]

Will consider this fixed then, and a stable release should come in not too long. (week+)