Opened 14 years ago

Closed 13 years ago

Last modified 12 years ago

#826 closed Bug (fixed)

Transmission doesn't open torrents via web browser

Reported by: charles Owned by: charles
Priority: High Milestone: 1.33
Component: GTK+ Client Version: 1.20
Severity: Normal Keywords:
Cc:

Description

https://bugs.launchpad.net/ubuntu/+source/transmission/+bug/204184

I don't know if cause is firefox or transmission, however sometimes, when I click on a torrent file link via Firefox and open it with transmission (for example in http://torrent.ubuntu.com:6969/) it's not open. And so I need to re-click on same link. This happens when transmission is already open and it's downloading another file.

Change History (16)

comment:1 Changed 14 years ago by charles

  • Status changed from new to assigned

comment:2 Changed 13 years ago by charles

I can't reproduce this anymore, but I don't know if/when it was fixed.

comment:3 Changed 13 years ago by denisleroy

  • Summary changed from Transmission doesn't open torrents via Firefox 3 to Transmission doesn't open torrents via web browser
  • Version changed from 1.06 to 1.11

This is still occurring with 1.11, this on Fedora 8.

This bug has been around for a long time. Typically this only happens when opening torrents from the web browser, and when transmission is already running. It also only seems to occur with specific torrent files (maybe 1 out of 5 ?).

The workaround is to download the torrent file, and opening it directly from transmission (or dragging the torrent file icon onto the torrent window), so at least we know it's not a corrupted torrent file issue.

This occurs with galeon and epiphany also.

comment:4 Changed 13 years ago by denisleroy

The problem is on the server receiving side. The client sends 2 messages: the "version" message and the "addfiles" messages. Sometimes both messages are coalesced by the socket kernel/libc stack, and the server reads them both from the socket with a single read() command. When that happens, the 2nd message seems to be ignored.

comment:5 Changed 13 years ago by denisleroy

I narrowed this bug down to a race condition when sending the "addfiles" command on the server socket. The problem looks to me like a libc bug of some sort, or some incorrect use of the socket API.

The client application, when called by the web browser to open a new torrent file, sends a couple of commands ('version' and 'addfiles') to the server process (the bug is only triggered when transmission is already running), then quits. It would seem that by exiting just after sending the "addfiles" command, that command never gets to its destination. However adding a simple sleep(1) command before the exit is enough to reliably fix the bug:

--- transmission-1.11/gtk/ipc.c~	2008-04-04 21:27:33.000000000 +0200
+++ transmission-1.11/gtk/ipc.c	2008-05-02 18:56:50.000000000 +0200
@@ -339,7 +350,7 @@
   }
 
   g_main_loop_run(con->u.client.loop);
-
+  sleep(1);
   return ret;
 }

I don't fully understand what's going on here, as normally there's nothing wrong with sending something on a socket then closing immediately: the kernel/libc is supposed to close things down gracefully...

comment:6 Changed 13 years ago by charles

  • Milestone changed from None Set to 1.20

comment:7 Changed 13 years ago by charles

  • Resolution set to fixed
  • Status changed from assigned to closed

yuck, what a nasty bug.

thanks for the workaround. :)

comment:8 Changed 13 years ago by charles

comment:9 Changed 13 years ago by btmorex

  • Resolution fixed deleted
  • Status changed from closed to reopened

This is not fixed for me in 1.20.

comment:10 Changed 13 years ago by Festor

  • Milestone changed from 1.20 to 1.21
  • Version changed from 1.11 to 1.20

comment:11 Changed 13 years ago by charles

  • Milestone changed from 1.21 to 1.30
  • Resolution set to fixed
  • Status changed from reopened to closed

The add-a-torrent-from-another-app code has been completely rewritten in 1.30, fixing this as a side-effect. As of 1.30, the copy of Transmission started by $BROWSER will pass the .torrent to the existing copy of Transmission via dbus instead of our IPC code.

comment:12 Changed 13 years ago by charles

  • Milestone changed from 1.30 to 1.33
  • Priority changed from Normal to High
  • Resolution fixed deleted
  • Status changed from closed to reopened

Well 1.3x is a little better, but not as good as I'd hoped. There's still a bug triggered in the "torrent options" dialog when the browser deletes the temporary torrent file. This needs to be fixed RSN.

On the positive side, if you turn off the "torrent options" dialog then adding torrents via the web browser seems to work 100% of the time.

comment:13 Changed 13 years ago by charles

Test fix in r6512.

If this works, it needs to be backported to the 1.3x branch.

comment:14 Changed 13 years ago by charles

  • Resolution set to fixed
  • Status changed from reopened to closed

fix confirmed by adamw in #transmission.

1.3x: r6513

comment:15 Changed 13 years ago by add

(deleted spam)

Last edited 12 years ago by charles (previous) (diff)

comment:16 Changed 12 years ago by sim

(deleted spam)

Last edited 12 years ago by charles (previous) (diff)
Note: See TracTickets for help on using tickets.