Transmission 1.83 Released

[applemac1]

Got to say for me this is the worst update I´ve ever had off of transmission, as 1.82 the previous release was downloading after making the update Ive lost all the torrents. Also my ratio has disappeared altogether.

[Lutin]

I uploaded and seeded the whole night a 3 GB file on a private tracker and my ratio has not changed at all. In fact, the tracker doesn't see me and posts 0 seeder, even though Transmission currenly indicates 3 active leechers. This is the first time I have this problem. In previous releases, the tracker was updating my ratio just fine. Any suggestion?

[Rolcol]

Got to say for me this is the worst update I´ve ever had off of transmission, as 1.82 the previous release was downloading after making the update Ive lost all the torrents. Also my ratio has disappeared altogether.

That sounds like it's a problem with the configuration files not being found. As far as I know, there was no change in how 1.83 handles its configuration. Check that Transmission's files are there (~/Library/Application Support/Transmission or ~/.config/transmission)

[Marc31]

Excellent release! Upgraded smoothly.

Downloaded +10 and seeding +80 torrents on 8 different private trackers without any problems whatsoever.

cheers,

<edit> btw, OS X 10.6.2

[Jordan]

natpmp.c:164: warning: no previous declaration for ‘readnatpmpresponse’
miniwget.c: In function ‘miniwget2’:
miniwget.c:43: warning: unused parameter ‘url’
regress.c: In function ‘test_simpleread’:
regress.c:373: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c: In function ‘test_fork’:
regress.c:537: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c:568: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c:581: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c: In function ‘test_event_base_new’:
regress.c:897: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c: In function ‘test_multiple_events_for_same_fd’:
regress.c warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c: In function ‘read_once_cb’:
regress.c warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
regress.c: In function ‘test_want_only_once’:
regress.c warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
bench.c: In function ‘read_cb’:
bench.c:76: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
bench.c: In function ‘run_once’:
bench.c:101: warning: ignoring return value of ‘write’, declared with attribute warn_unused_result
webseed.c: In function ‘fireNeedReq’:
webseed.c:63: warning: unused parameter ‘w’

These warnings should be reported upstream. We try to always use the upstream code as-is.

[rb07]

I've also seen what others describe as transmission appearing to stop a torrent with no reason, but its not in general.

What I've seen is that in this version when you start a new torrent, it behaves normal for a very short while then disconnects completely. If I pause and start the torrent, everything goes to normal. If I don't do anything I assume it recovers on the next announce/scrape because next day the torrent did in fact finished downloading and seeding.

Since there's no info about trackers/seeders/leechers on the GUIs, the only info I got was with transmission-remote, and it looks normal except that it is not connected to anybody:

Code: Select all

TRANSFER
  State: Idle
  Location: /opt/var/transmission/downloads
  Percent Done: 0.00%
  ETA: 0 seconds
  Download Speed: 0.0 KB/s
  Upload Speed: 0.0 KB/s
  Have: 64.0 KB (None verified)
  Total size: 704.8 MB (704.8 MB wanted)
  Downloaded: 94.5 KB
  Uploaded: None
  Ratio: 0.00
  Corrupt DL: None
  Peers: connected to 0, uploading to 0, downloading from 0
...
TRACKERS

  Tracker #1: tracker.tracker.example.com.com:80
  Active in tier #1
  Got a list of 7 peers 19 minutes ago
  Tracker had 2 seeders and 1 leechers 2 minutes, 33 seconds ago
  Asking for peer counts in 12 minutes
...

Additional info is that this is with a private tracker, and no, transmission 1.83 is not banned or anything.

[Lutin]

Is the fact that I am getting the "Scrape Error: Tracker did not respond" message on all my files related to my problem mentioned above?
Also, when I am quiting, Transmission stops abruptly without hanging at all.
Thanks in advance.

I am using 1.83 on latest snow leopard.

[rb07]

Is the fact that I am getting the "Scarpe Error: Tracker did not respond" message on all my files related to my problem mentioned above?

Yes. If the tracker doesn't see you, or if its not working (which could be the case here), then it can't update your statistics.

[Lutin]

Thanks rb07. What are my options now? How can I correct this?

[rb07]

What are my options now? How can I correct this?

Very few, its probably a tracker error so you can't do anything there except wait for it to come on-line again. Also, I don't know if this has changed but, the client stats are not sent until the torrent is paused or stopped... but don't stop it yet, that is independent of the tracker not responding.

If its not the tracker, then something is blocking your communication with the tracker. That's unlikely since you had communication at some point (the tracker gave you the list of peers you uploaded to, unless that tracker allows PEX or DHT).

[naddy]

Since they are private trackers, are you sure they are allowing 1.83 yet. Typically, they do not allow new clients right away. Also, are you sure the problem isn't on the tracker's end?

I'm looking at the network traffic to the trackers with tcpdump right now... and there is none. 1.83 does not even send queries to the trackers—which explains why it doesn't get any responses.

[kovalev]

After running Transmission 1.83 for a couple of days, have finally got a crash (system had become completely unresponsive), with over 50 Mb of such messages in a system log:

Feb 1 13:20:51 kovalev-home kernel: [98411.053744] WARNING: at /build/buildd/linux-2.6.31/net/ipv4/tcp.c:1408 tcp_recvmsg+0xa49/0xb20()
Feb 1 13:20:51 kovalev-home kernel: [98411.053747] Hardware name: Satellite L40
Feb 1 13:20:51 kovalev-home kernel: [98411.053749] Modules linked in: udf crc_itu_t isofs xt_tcpudp sbp2 aes_i586 aes_generic binfmt_misc ppdev nls_iso8859_1 nls_cp437 vfat fat joydev snd_hda_codec_analog arc4 ecb pcmcia snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi iptable_filter snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device ip_tables x_tables psmouse serio_raw yenta_socket rsrc_nonstatic pcmcia_core snd shpchp ath5k mac80211 ath cfg80211 soundcore snd_page_alloc video1394 raw1394 asus_laptop led_class lp parport usbhid fbcon tileblit font bitblit softcursor i915 drm i2c_algo_bit 8139too ohci1394 ieee1394 8139cp mii intel_agp agpgart video output
Feb 1 13:20:51 kovalev-home kernel: [98411.053811] Pid: 1974, comm: transmission Tainted: G W 2.6.31-18-generic #55-Ubuntu
Feb 1 13:20:51 kovalev-home kernel: [98411.053814] Call Trace:
Feb 1 13:20:51 kovalev-home kernel: [98411.053822] [<c014513d>] warn_slowpath_common+0x6d/0xa0
Feb 1 13:20:51 kovalev-home kernel: [98411.053827] [<c04d2439>] ? tcp_recvmsg+0xa49/0xb20
Feb 1 13:20:51 kovalev-home kernel: [98411.053831] [<c04d2439>] ? tcp_recvmsg+0xa49/0xb20
Feb 1 13:20:51 kovalev-home kernel: [98411.053836] [<c0145185>] warn_slowpath_null+0x15/0x20
Feb 1 13:20:51 kovalev-home kernel: [98411.053840] [<c04d2439>] tcp_recvmsg+0xa49/0xb20
Feb 1 13:20:51 kovalev-home kernel: [98411.053845] [<c0492433>] sock_common_recvmsg+0x43/0x60
Feb 1 13:20:51 kovalev-home kernel: [98411.053849] [<c04920ac>] sock_aio_read+0x11c/0x130
Feb 1 13:20:51 kovalev-home kernel: [98411.053855] [<c01e78fc>] do_sync_read+0xbc/0x100
Feb 1 13:20:51 kovalev-home kernel: [98411.053860] [<c015c1d0>] ? autoremove_wake_function+0x0/0x40
Feb 1 13:20:51 kovalev-home kernel: [98411.053865] [<c04f02c1>] ? inet_ioctl+0x31/0xb0
Feb 1 13:20:51 kovalev-home kernel: [98411.053870] [<c02cbb7f>] ? security_file_permission+0xf/0x20
Feb 1 13:20:51 kovalev-home kernel: [98411.053874] [<c01e799f>] ? rw_verify_area+0x5f/0xe0
Feb 1 13:20:51 kovalev-home kernel: [98411.053877] [<c0490940>] ? sock_ioctl+0x0/0x260
Feb 1 13:20:51 kovalev-home kernel: [98411.053881] [<c01e7fda>] vfs_read+0x17a/0x190
Feb 1 13:20:51 kovalev-home kernel: [98411.053886] [<c01f5651>] ? do_vfs_ioctl+0x71/0x310
Feb 1 13:20:51 kovalev-home kernel: [98411.053890] [<c0217e0d>] ? sys_epoll_ctl+0x9d/0x240
Feb 1 13:20:51 kovalev-home kernel: [98411.053894] [<c01e850d>] sys_read+0x3d/0x70
Feb 1 13:20:51 kovalev-home kernel: [98411.053898] [<c01033ac>] syscall_call+0x7/0xb
Feb 1 13:20:51 kovalev-home kernel: [98411.053901] ---[ end trace 146c0bb6f81806ff ]---
Feb 1 13:20:51 kovalev-home kernel: [98411.053904] recvmsg bug: copied 96082306 seq 9608289A

I did experienced similar events occasionally while running previous releases of Transmission (including 1.76 installed from repository), with absolutely the same call trace. As before, this had happened while downloading a torrent with a large swarm and at a relatively high speed - the only thing I was able to link to the event so far.

[kovalev]

Sorry - just an addition to the previous post:

current Transmission version is 1.83+ rc10048 GTK running on Ubuntu 9.10 (Linux kernel 2.6.31.18 and Gnome 2.28.1).

[Lutin]

I'm looking at the network traffic to the trackers with tcpdump right now... and there is none. 1.83 does not even send queries to the trackers—which explains why it doesn't get any responses.

That would certainly explain why I didn't get any ratio update after I uploaded and seeded a 3 GB file, as well as why Transmission stops abruptly when I quit instead of the usual time it takes to send queries to all the trackers.

[gorillaki]

I can't connect to peers from private trackers, either.
1.82 is working mighty fine.
Archlinux system, with the cli version of transmission (run as daemon).
I do believe that the problem is in the way the torrent is parsed to the client via the web-ui... because the public torrents are working just fine.
With 1.83, both the embedded web-ui and the windoze transmission remote client do not work for me, for private torrents.