Ошибка could not connect to tracker

Hello,
I have a recurring problem with transmission. I am using version 2.50 (13236).
Sometimes when I add some new torrent to download, transmission seems not to be able to start them becouse it gets tracker errors.
For example, using a torrent of a popular tv shows that uses:
udp://tracker.example.com:80
udp://tracker.tracker.example.com:80

I get: Connection failed for all 3 trackers.
The only meaningful error I get in the log is this:

2012-03-13 16:40:59 +0000 tr-udp.c:260 [Error] UDP: Couldn’t bind IPv4 socket

All the other messages are just the retry in connecting to the trackers.
I managed to solve the problem by periodically remove the org.m0k.transmission.plist file.

If I close transmission and delete preferences files then all the download start promptly and the trackers respond as usual.
Of course this is only a workaround, by deleting the preference file I loose all the preferences as well as filters and so on.
I imagine that the plist file would be useful to further debug the problem..
Here is a link to the plist file:

EDIT: new plist file, the old one was the wrong one
http://www.mediafire.com/?4ip0vcvr4edp4ff

I hope someone can understand the reason of this odd behaviour..

I managed to isolate the problem:
1) put some torrent running
2) change port in preferences
3) quit transmission without stopping downloads
4) reopen transmission:
— the «Couldn’t bind IPv4 socket» message will appear
— now the torrents do not connect to trackers
5) choose a random port
5a) at this point the torrents still do not connect to tracker
6) restart transmission: everything works fine.
6a) now every announce works well..

It seems to me a really odd behavior… But I still do not have enough «proofs» in order to file a bug.. Any suggestion on how to further investigate this?

x190 wrote:Seems like 2 issues.

• Unresponsive trackers which use Port 80 from your example and which may be normal or temporary.

I thought so but the unresponsiveness of the trackers only verify when following the procedure in my second post. ie: if I follow that procedure the tracker are NEVER responding, if I change the port and restart the tracker are ALWAYS responding.

• «Couldn’t bind IPv4 socket» in tr-udp.c. Do you have some type of firewall blocking certain ports? When you get this message do you also see something like «2012-03-13 11:57:55 -0600 net.c:558 [Debug] Transmission: Bound socket 11 to port xxxxx on 0.0.0.0»?

Try leaving Transmission->Preferences->Network set to «Randomize on launch».

viewtopic.php?f=1&t=3415
http://forum.transmissionbt.com/viewtop … f=1&t=3274

Yes, upon start (when NOT in the situation in which the trackers are irresponsive) I see this:

2012-03-13 19:34:58 +0000 session.c:718 [Info] Transmission: Transmission 2.50 (13236) started
2012-03-13 19:34:58 +0000 cache.c:249 [Debug] Cache: Maximum cache size set to 4.00 MB (244 blocks)
2012-03-13 19:34:58 +0000 rpc-server.c:803 [Info] RPC Server: Adding address to whitelist: 127.0.0.1
2012-03-13 19:34:58 +0000 net.c:371 [Debug] Transmission: Bound socket 11 to port 59946 on 0.0.0.0
2012-03-13 19:34:58 +0000 net.c:371 [Debug] Transmission: Bound socket 12 to port 59946 on ::
2012-03-13 19:34:58 +0000 tr-udp.c:56 [Errore] UDP: Failed to set receive buffer: No buffer space available
2012-03-13 19:34:58 +0000 tr-udp.c:75 [Errore] UDP: Failed to set receive buffer: requested 4194304, got 42080

Instead when I am in the irresponsive situation I only see the «Couldn’t bind IPv4 socket» message.

Yes I am using the Lion firewall with the default settings and Transmission is already allowed to transmit.
I tried disabling it, nothing changes..

x190 wrote:

Lion firewall with the default settings and Transmission is already allowed to transmit.
I tried disabling it, nothing changes..

Okay, so you don’t use PG2, L’il Snitch, Norton Firewall, or the like? I wonder about your ISP?

No other firewalls; the situation is the same with or without Lion builtin firewall.
I don’t think about something related to ISP: following steps above, one time announces work, the next they don’t.
In addition I managed to further simplify the procedure to reproduce the situation.

Premises: transmission open, with one port selected (ie 30000) and recognized as Open, one torrent running and announces working properly.
1) in preferences change the port into one perviously used by transmission, in my case 6998.
2) shut down transmission
3) reopen transmission: the «Couldn’t bind IPv4 socket» appears, no tracker activity:(
4) choose another port
5) close and reopen transmission: everything works OK

I just noticed a few things:
a) when transmission is in the «stuck tracker» mode and I change the port the tracker announces still fails: I have to restart it in order to make it «see» the new port setting
b) the problem seems to affect only one port 6998, which is the one I usually use for transmission and is the one I forwarded on my router; following the steps above with initial port 7000 and next port 8000 results in everything OK. This may mean that in some way the 6998 port is still «bind for UDP» by some process.. maybe a crashed instance of Transmission?
c) I will try restarting the mac and see if it only happen with port 6998 or maybe with the port opened by transmission the first time it is launched.

Instead when I am in the irresponsive situation I only see the «Couldn’t bind IPv4 socket» message.

Try disabling µTP in Transmission->Preferences->Network.

I tried both with µTP on and off, same results..
Port forwarding too, tried both on and off, same results

I always had the same problem. It is a problem with Transmission. Firewall has nothing to do with it; just use uTorrent with the same port and you can verify that it will connect without any issues.

This is UDP-specific. If another tracker is added with a HTTP protocol, it will work, even when the UDP connection is not working.

I actually thought that the problem was that Transmission itself did not support UDP trackers at all. But since nick said above that he can actually manage to make the connection work, I guess is just that Transmission has a poor UDP implementation.

quantumnoise wrote:I always had the same problem. It is a problem with Transmission. Firewall has nothing to do with it; just use uTorrent with the same port and you can verify that it will connect without any issues.

This is UDP-specific. If another tracker is added with a HTTP protocol, it will work, even when the UDP connection is not working.

I actually thought that the problem was that Transmission itself did not support UDP trackers at all. But since nick said above that he can actually manage to make the connection work, I guess is just that Transmission has a poor UDP implementation.

Hi, did you tried changing the port and restarting? I have no doubt uTorrent does work, but for me when the problem occurred it was limited to one single port: changing the port and restarting Transmission solved it for the moment.. then sometimes it occurs again but I change port and this simply does it..

Yes, I always tried to restart after changing the port. Never worked. Though I never followed rigorously the routine 1-6 you mentioned; I would just change the port without worrying whether or not the transfers were paused, and then load Transmission again, then try to resume the download.

But if the problem is the port, then why it would work on that same port as soon as you add a HTTP tracker? Take for instance the case of publicbt. If you have a torrent with publicbt UDP tracker and Transmission cannot connect, as soon as you add the HTTP publicbt tracker it will work. No need to change port nor restart.

I perfectly understand your problem: even my Transmission sometime connects to http tracker with no problem but fails on udp..
I ask you 2 things:
— do you have a mac?
— can you post the first entries of the transmission logs upon startup?

IE: I have set the log level to «Debug», here’s what I get:

2012-03-29 17:22:14 +0000 session.c:718 [Info] Transmission: Transmission 2.50 (13236) started
2012-03-29 17:22:14 +0000 cache.c:249 [Debug] Cache: Maximum cache size set to 4.00 MB (244 blocks)
2012-03-29 17:22:14 +0000 rpc-server.c:803 [Info] RPC Server: Adding address to whitelist: 127.0.0.1
2012-03-29 17:22:14 +0000 net.c:371 [Debug] Transmission: Bound socket 11 to port 50000 on 0.0.0.0
2012-03-29 17:22:14 +0000 net.c:371 [Debug] Transmission: Bound socket 12 to port 50000 on ::
2012-03-29 17:22:14 +0000 tr-udp.c:56 [Errore] UDP: Failed to set receive buffer: No buffer space available
2012-03-29 17:22:14 +0000 tr-udp.c:75 [Errore] UDP: Failed to set receive buffer: requested 4194304, got 42080
2012-03-29 17:22:14 +0000 tr-dht.c:276 [Debug] DHT: Initializing DHT

I noticed that when the two lines in bold are in the same ways as above… well, everything works fine..
While if I get

2012-03-13 16:40:59 +0000 tr-udp.c:260 [Error] UDP: Couldn’t bind IPv4 socket

T. won’t connect to any tracker, either TCP or UDP.

I «guess» ( NOT knowing how the T. internals do work, neither how does it binds to port) that in the latter case the unresponsivness of the trackers are due to a previously execution of T. which crashed or, somehow, failed to «release» the port. Then when you open again T. ( with the same port set in the preferences) it will fail until you choose another port and restart it.
That is also the reason why deleting the .plist file solves the problem.. when T. recreates the .plist it will choose a random port, thus different from the previous one..

thought I’d bump this topic. I experienced the same problem, though the cure was not the same as the one listed in the previous posts.

I couldn’t connect to any UDP based trackers at all, even though other torrent clients I installed did. I have no errors in the logs. I tried changing the port and relaunching, etc, and that didn’t seem to fix the problem. Rebooting the computer didn’t fix the problem. Installing the latest nightly built didn’t solve the problem.

The only thing that did was deleting the plist file and relaunching Transmission, after which it would connect no problem, even though I have it configured (and it automatically selected) to use the same port it was using before.

I am not sure how long this problem has been happening, as I have been using torrents with many seeds and http trackers for quite a while. It was only tonight I was using an obscure torrent that only had udp trackers that I found out I couldn’t connect to anything.

Unfortunately, I emptied the trash after I deleted the plist without thinking, so I do not have the defective plist for examination. But, if there is anything else I can provide that would be helpful, let me know.

I’m having a similar problem. All my torrents are reporting «Scrape error: could not connect to tracker».

My port is open; I can download and seed; but I looking at the log, I think my peers are all coming from DHT (if that makes sense).

Here’s some log excerpts when I launch Transmission. By the way, another mystery is this: all the torrents are paused, so why are we scraping at all???? Pause should mean pause. I like to keep a lot of paused torrents in my list, but I’ll have to stop doing that if there is this secret cost.

2012-07-26 12:23:45 -0700 session.c:720 [Info] Transmission: Transmission 2.61 (13407) started
2012-07-26 12:23:45 -0700 cache.c:249 [Debug] Cache: Maximum cache size set to 4.00 MB (244 blocks)
2012-07-26 12:23:45 -0700 rpc-server.c:803 [Info] RPC Server: Adding address to whitelist: 127.0.0.1
2012-07-26 12:23:45 -0700 net.c:373 [Debug] Transmission: Bound socket 12 to port 51414 on 0.0.0.0
2012-07-26 12:23:45 -0700 net.c:373 [Debug] Transmission: Bound socket 13 to port 51414 on ::
2012-07-26 12:23:45 -0700 port-forwarding.c:181 [Info] Port Forwarding: Stopped
2012-07-26 12:23:45 -0700 tr-udp.c:58 [Error] UDP: Failed to set receive buffer: No buffer space available
2012-07-26 12:23:45 -0700 tr-udp.c:77 [Error] UDP: Failed to set receive buffer: requested 4194304, got 42080
2012-07-26 12:23:45 -0700 tr-udp.c:58 [Error] UDP: Failed to set receive buffer: No buffer space available
2012-07-26 12:23:45 -0700 tr-udp.c:77 [Error] UDP: Failed to set receive buffer: requested 4194304, got 42080
2012-07-26 12:23:45 -0700 tr-dht.c:276 [Debug] DHT: Initializing DHT
2012-07-26 12:23:45 -0700 tr-dht.c:305 [Info] DHT: Reusing old id
2012-07-26 12:23:45 -0700 tr-dht.c:153 [Info] DHT: Bootstrapping from 156 IPv4 nodes
2012-07-26 12:23:45 -0700 tr-dht.c:330 [Debug] DHT: DHT initialized
2012-07-26 12:23:45 -0700 tr-dht.c:156 [Info] DHT: Bootstrapping from 32 IPv6 nodes
2012-07-26 12:23:45 -0700 rpc-server.c:803 [Info] RPC Server: Adding address to whitelist: 127.0.0.1
[skipping entries while it reads resume files]
2012-07-26 12:24:20 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:24:20 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 301 seconds.
2012-07-26 12:24:30 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:24:30 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 327 seconds.
2012-07-26 12:24:40 -0700 announcer.c:1259 [Info] Hindemith - Villa Musica: Scrape error: Could not connect to tracker
2012-07-26 12:24:40 -0700 announcer.c:1268 [Info] Hindemith - Villa Musica: Retrying scrape in 322 seconds.
2012-07-26 12:24:40 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:24:40 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 310 seconds.
2012-07-26 12:25:00 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:25:00 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 330 seconds.
2012-07-26 12:25:00 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:25:00 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 357 seconds.
2012-07-26 12:25:01 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Tracker did not respond
2012-07-26 12:25:01 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 334 seconds.
2012-07-26 12:25:10 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:25:10 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 358 seconds.
2012-07-26 12:25:21 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Connection failed
2012-07-26 12:25:21 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 330 seconds.
2012-07-26 12:25:21 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:25:21 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 333 seconds.
2012-07-26 12:25:30 -0700 announcer.c:1259 [Info] Joyce, James - Ulysses (Unabridged): Scrape error: Could not connect to tracker
2012-07-26 12:25:30 -0700 announcer.c:1268 [Info] Joyce, James - Ulysses (Unabridged): Retrying scrape in 359 seconds.
2012-07-26 12:25:30 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:25:30 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 308 seconds.
2012-07-26 12:25:30 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Could not connect to tracker
2012-07-26 12:25:30 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 311 seconds.
2012-07-26 12:25:31 -0700 announcer.c:1259 [Info] Bach CPE - Sinfonie - Amis de Philippe: Scrape error: Connection failed
2012-07-26 12:25:31 -0700 announcer.c:1268 [Info] Bach CPE - Sinfonie - Amis de Philippe: Retrying scrape in 329 seconds.
2012-07-26 12:25:31 -0700 announcer.c:1259 [Info] Hindemith - Villa Musica: Scrape error: Connection failed
2012-07-26 12:25:31 -0700 announcer.c:1268 [Info] Hindemith - Villa Musica: Retrying scrape in 316 seconds.
2012-07-26 12:25:31 -0700 announcer.c:1259 [Info] glenn gould: Scrape error: Connection failed
2012-07-26 12:25:31 -0700 announcer.c:1268 [Info] glenn gould: Retrying scrape in 300 seconds.