I'm not sure what has caused this, but suddenly I'm unable to use any of the rpc services. It appears that the JSON is corrupt. I initially posted this in the transmission-remote-gui at http://code.google.com/p/transmisson-re ... ail?id=655, since it wasn't connecting and said something like Error at line 1 POS XXXX: Expected , or ] got token "result".
Looking at the output, though the author said the the conversation was wrong and "the daemon returns wrong JSON. It misses commas in some places. And I don't know why."
He pointed me at a year old bug involving unicode and it causing transmission to corrupt json output, but this didn't seem to involve unicode. The output of an 'si' command to the remote, was over 1k in length? Maybe there's an internal buffer overflow somewhere?
I was running 2.75, but when I filed the bug report (that never showed up) I saw 2.77 was available and tried it as well -- same thing.
It happened when I added 2 torrents yesterday. They downloaded -- in fact the server/daemon is still running/serving at full tilt, but can't get status on sessions even with the CLI.
(or the transmission-web interface) -- I see the trans. Icon, but it's next to an error message that says Connection failed -- you may have to reload the page to connect. So even the internal web-server
can't talk to itself! Weird.
I deleted the 2 torrents, but it didn't help the problem, so I'm stuck. Any ideas other than deleting all 400 some odd torrents and rebuilding the session?? Ug... (and I don't even know that that would help!)...
Thanks...
transmission seems to be sending corrupt rpc output
Re: transmission seems to be sending corrupt rpc output
I already updated my ticket, but you can't see it because my post to the ticket won't be posted until it goes through a 24hr moderation period. Never known any project to have moderation on a buglist other than this one...very odd -- it tends to hinder posting updates to the bug as well as you being able to see the updates I posted.
It's also hard for me to remember what I posted where if I can't
look at it and am not emailed a copy.
Some of these tests I did after I posted that bug post, but it wasn't available to post to for over a day after I posted it. If you want the bug updated with the details, the bug needs to be available in real-time to update.
FWIW, you should start taking bugs here in the forum, it might make it easier to get get faster turn-around and details.
---
Also, you ask "Browser type and version, for example. " I ran into the problem in transmission-remote-gui -- so it wasn't using a web browser. I repeated the bug in the CLI and and saw the problem in wireshark -- a dump I pointed to in the tran-bug, but that hasn't posted last I looked. I repeated the failure with a web-browser -- pointing to the fact that it could talk with the client, but couldn't get torrent specific information -- like the tracker info shown in the bug report. To me, browser type and version didn't seem like useful information.
It's also hard for me to remember what I posted where if I can't
look at it and am not emailed a copy.
Some of these tests I did after I posted that bug post, but it wasn't available to post to for over a day after I posted it. If you want the bug updated with the details, the bug needs to be available in real-time to update.
FWIW, you should start taking bugs here in the forum, it might make it easier to get get faster turn-around and details.
---
Also, you ask "Browser type and version, for example. " I ran into the problem in transmission-remote-gui -- so it wasn't using a web browser. I repeated the bug in the CLI and and saw the problem in wireshark -- a dump I pointed to in the tran-bug, but that hasn't posted last I looked. I repeated the failure with a web-browser -- pointing to the fact that it could talk with the client, but couldn't get torrent specific information -- like the tracker info shown in the bug report. To me, browser type and version didn't seem like useful information.