transgui fails to connect to transmission-daemon over ssh tunnel

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Install transmission-daemon on your Ubuntu v11.04 x64 server.
2. Tunnel transmission through SSH (port 9091) to your Ubuntu v11.04 x64 
desktop.
3. Install transgui from the Ubuntu Software Centre on your Ubuntu desktop.
4. Scratch your head over the fact that transgui cannot set up a connection on 
localhost:9091 and instead displays 2 error windows with absolutely no 
information whatsoever within them.

What is the expected output? What do you see instead?
Quite frankly I don't get why transgui cannot connect to localhost:9091 and 
even if it doesn't I would really like to know what caused transgui to fail at 
this. And since the 2 error windows doesn't provide any insight it doesn't 
really help me to solve the problem.

What I would like to see is transgui setting up this connection, but if it 
fails to do so (and it does) I would like to know why.

What version of the product are you using? On what operating system?
transgui 3.0.1 on Ubuntu natty x64
transmission-daemon 2.31 on Ubuntu Server natty x64

Please provide any additional information below.
I decided to upgrade transgui to 3.0.1 using ppa:andreas-noteng/transgui which 
I found at https://launchpad.net/~andreas-noteng/+archive/transgui, but it 
proved to be unsuccessful as well...

I also tried to launch transgui from inside gnome-terminal to get some messages 
inside the terminal. To me it's pretty confusing as I don't understand it, but 
maybe you guys do. =)

[WARNING] Out of OEM specific VK codes, changing to unassigned
[WARNING] Out of unassigned VK codes, assigning $FF

(transgui:5201): Gtk-CRITICAL **: IA__gtk_widget_realize: assertion 
`GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed

(transgui:5201): Gtk-CRITICAL **: IA__gtk_widget_realize: assertion 
`GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed

(transgui:5201): Gtk-CRITICAL **: IA__gtk_widget_realize: assertion 
`GTK_WIDGET_ANCHORED (widget) || GTK_IS_INVISIBLE (widget)' failed
TApplication.HandleException Could not convert variant of type (Null) into type 
(Int64)
  Stack trace:
  $0000000000760F96
  $000000000075B8BB
  $000000000073EA59
  $000000000072501C
  $0000000000723FA7
  $0000000000722036
  $00000000006323C2
  $000000000063218E
  $0000000000631F53
  $0000000000631055
  $000000000055169A
  $000000000053D7A3
  $00000000005419B5
  $00000000005515CB
  $000000000066AE8D
  $000000000053EC07
  $0000000000633A11

Original issue reported on code.google.com by G.r.v.kr...@gmail.com on 14 Jun 2011 at 10:35

Attachments:

• screenshot.png

[GoogleCodeExporter]

And the actual connection settings, just in case.

Original comment by G.r.v.kr...@gmail.com on 14 Jun 2011 at 10:40

Attachments:

• screenshot2.png

[GoogleCodeExporter]

i don't think ssh tunneling is the problem here... 

my bro & I use transmission-daemon on 1 box (ubuntu lucid server)
and transGUI on 2 others ... my desktop is kubuntu maverick & his is win7

after upgrading daemon from 1.93 to 2.31 ($apt-get upgrade)
both instances of transGUI are doing this

deamon is running... both of us can get to the webUI (http://server:9091)
but the client can no longer connect ???

Original comment by boolionc...@gmail.com on 17 Jun 2011 at 7:15

[GoogleCodeExporter]

confirmed ... downgraded back to 1.93 and transGUI connects again

Original comment by boolionc...@gmail.com on 17 Jun 2011 at 7:50

[GoogleCodeExporter]

daemon 1.93 is in the ubuntu repo, but way way old
I grabbed the 2.22.deb from tramission's ppa and installed manually then pinned 
it

Please let us know when the GUI will support 2.31+

Thanks

Original comment by boolionc...@gmail.com on 25 Jun 2011 at 7:14

[GoogleCodeExporter]

I also was affected by the issue. Downloading the latest transgui from the 
website solved the issue : 
http://code.google.com/p/transmisson-remote-gui/downloads/list

It seems to work well with 2.32 daemon.

Original comment by schoup...@gmail.com on 26 Jul 2011 at 3:43

[GoogleCodeExporter]

It wasn't mentioned so I'll ask.

Did anyone try not using the keyword "localhost" and instead try "127.0.0.1" OR 
their computer's lan IP?  e.g. 192.168.1.100

I've had issues with other applications having issues with localhost when 
tunneling and using the lan ip or 127.x has almost always solved it.

Original comment by Clayton....@gmail.com on 21 Sep 2011 at 8:16

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

This one also hit me on 2.11.2. It's definitely related to ssh tunnels. cli 
testcase:

$ sudo service transmission-daemon start
[cut]
$ transmission-remote localhost --list
ID     Done       Have  ETA           Up    Down  Ratio  Status       Name
Sum:              None               0.0     0.0
$ ssh -NT -L 9093:localhost:9091 localhost &
$ transmission-remote localhost:9093 --list
channel 2: open failed: administratively prohibited: open failed
[13:17:22.966] transmission-remote: (http://localhost:9093/transmission/rpc 
Server returned nothing (no headers, no data)

Have tried to adjust the rpc-whitelist* parameters in settings.json, no luck.

Original comment by Leamas.A...@gmail.com on 7 Oct 2011 at 11:24

[GoogleCodeExporter]

Original comment by j...@cp-lab.com on 24 Oct 2011 at 10:06

• Changed state: WontFix

[GoogleCodeExporter]

I don't have this issue, but I felt I must chime in.

A "wontfix" with no comment is essentially a "fuck you" to your users.  You owe 
them nothing, but I think they deserve even the slightest comment you could 
muster.

Original comment by Clayton....@gmail.com on 24 Oct 2011 at 10:18

[GoogleCodeExporter]

I don't interested in investigating this problem, since I do not use SSH 
tunneling. Probably I will never take a look into this issue. User patches is 
welcome.
I re-opened this issue and set the NoInterest priority, so users can continue 
discuss the problem here...

Original comment by j...@cp-lab.com on 24 Oct 2011 at 10:40

• Changed state: New
• Added labels: Priority-NoInterest
• Removed labels: Priority-Low

[GoogleCodeExporter]

for the record: 

i run 1 transmission-daemon on the LAN
and another at a friend's house 
... no issues forwarding 9091 
and switching between 2 connections in trans-gui 

Original comment by boolionc...@gmail.com on 25 Oct 2011 at 5:13

[GoogleCodeExporter]

I got the same problem in 3.01 when trying to run it from either an SSH tunnel 
or on the local network. Upgrading to 3.1 solved it for me.

Original comment by denravon...@gmail.com on 1 Nov 2011 at 6:10

[GoogleCodeExporter]

I had the same problem without using SSH, just to a local server on the same 
LAN subnet.  Using the link from comment #5 and simply overwriting the binary 
file solved the problem for me.

Original comment by annett.d...@gmail.com on 27 Feb 2013 at 5:23