transgui
transgui copied to clipboard
transmission-remote-gui
Fixed a 'Duplicate object member: "status"' bug with v3.00 daemon'
This pull request fixes a bug, I've experienced with connecting Transmission Remote GUI to transmission-daemon v3.00. The whole just wouldn't work, showing a pop-up message 'Duplicate object member: "status"'. The client OS is Linux x86_64.
The bug is related to sending 'status' field two times in one of the JSON-RPC calls. This bug was supposedly triggered by changing the transmission-daemon RPC engine, as the duplicate record was no longer filtered in response.
The bug has been here before, it's just wasn't a problem to send duplicate fields with the older versions of transmission-daemon.
The solution for this bug is rather simple: sort by fields in those calls for RequestInfo(), which have non-trivial second array argument. A code review revealed that there is only one such case, most of the calls pass "array of const" for the first argument. To preserve code efficiency TStringList sorting is only done in the non-trivial case, but in the other cases TJSONArray is created by 'array of const', as it has been before.
It was not obvious for me, how the second argument of RequestInfo is formed, so a solution for removing "status" from where it comes from was abandoned. Sorting is a safe way, that would work without possibly breaking something else.
The program has been tested on linux, and it now works fine with all available daemon versions. Testing on other platforms should be done.
anna328p, yes, the very same issue, but my variant is less hacky. It would filter out any duplicates, should someone decide to call RequestInfo with an arbitrary set of intersecting fields. Also it preserves efficiency of calling RequestInfo with an empty second argument.
Tried this patch as newly merged in nixpkgs (PR mentioned above). Works like a charm!
I get #1329 merged as it's sent earlier and touched less thing here, but I'm not sure which one is better, please feel free to test it, and also feel free to refactor it if needed.
Hi @ivzeivze Thank you for your contribution! Just noticed that there is a git conflict in the changes. In order to proceed with merging your PR, would you like to resolve the conflict, and then we can continue with the merge process? Many thanks, again!
As far as I see, as a result of further development, the code patch has been amended with more understanding of the API internals. Thus my quick-fix from the past expires in favour of the new changes =)