Magnet links downloads won&#39;t start (since version 3.3.0) #3842

Author

Owner

@sledgehammer999 commented on GitHub (Jan 27, 2016):

A screenshot of the whole window would be helpful (cover the torrent names).

@sledgehammer999 commented on GitHub (Jan 27, 2016): A screenshot of the whole window would be helpful (cover the torrent names).

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 27, 2016):

And copy the log too. (View->Log)

@sledgehammer999 commented on GitHub (Jan 27, 2016): And copy the log too. (View->Log)

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 27, 2016):

Here are the screenshots: the same torrent added through its magnet link and its .torrent file.

MAGNET LINK

Preview (never completes the metadata retrieval):

Download (stays so indefinitely):

Log:

.TORRENT FILE

Preview:

Download:

Log:

Thanks for the support! :)

@Lore21 commented on GitHub (Jan 27, 2016): Here are the screenshots: the same torrent added through its magnet link and its .torrent file. # **MAGNET LINK** Preview (never completes the metadata retrieval): ![magnet_preview](https://cloud.githubusercontent.com/assets/16907002/12629571/c3b6a22a-c548-11e5-920b-979e0840ede0.png) Download (stays so indefinitely): ![magnet_download](https://cloud.githubusercontent.com/assets/16907002/12629580/c8bae13c-c548-11e5-939d-ff0bdecf49af.png) Log: ![magnet_log](https://cloud.githubusercontent.com/assets/16907002/12629586/cdb284f6-c548-11e5-988b-ff49d17a3cb1.png) # **.TORRENT FILE** Preview: ![dl_preview](https://cloud.githubusercontent.com/assets/16907002/12629594/d5f3ef9c-c548-11e5-8064-042e89c91616.png) Download: ![dl_download](https://cloud.githubusercontent.com/assets/16907002/12629598/d9cc01f4-c548-11e5-81c9-768d6f1838c0.png) Log: ![dl_log](https://cloud.githubusercontent.com/assets/16907002/12629602/dda9566e-c548-11e5-9758-73e5ae485ee7.png) Thanks for the support! :)

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 27, 2016):

Your log shows an error. I think it tells you that the port you chosen cannot be used. Choose another one(not 8999). And I suspect that's why you don't connect to any DHT nodes (look at the bottom of the window).
Also be sure that the port you choose is forwarded from your router otherwise other peers cannot reach you(that's why you have yellow icon).

@sledgehammer999 commented on GitHub (Jan 27, 2016): Your log shows an error. I think it tells you that the port you chosen cannot be used. Choose another one(not 8999). And I suspect that's why you don't connect to any DHT nodes (look at the bottom of the window). Also be sure that the port you choose is forwarded from your router otherwise other peers cannot reach you(that's why you have yellow icon).

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 27, 2016):

The error says it can't use the same socket address (protocol/address/port) twice, and as a matter of fact the "listening" log lines seem to be duplicated... :-?
Apart from that, the same error shows up even when using the .torrent file, yet in that case the download starts (and completes) without problems; moreover, magnet links stopped working alltogheter as soon as I updated qBittorent from version 3.2.x to version 3.3.x, mantaining the same configuration.
Changing the port randomly doesn't solve the problem anyway (same error with the new port).

@Lore21 commented on GitHub (Jan 27, 2016): The error says it can't use the same socket address (protocol/address/port) twice, and as a matter of fact the "listening" log lines seem to be duplicated... :-? Apart from that, the same error shows up even when using the .torrent file, yet in that case the download starts (and completes) without problems; moreover, magnet links stopped working alltogheter as soon as I updated qBittorent from version 3.2.x to version 3.3.x, mantaining the same configuration. Changing the port randomly doesn't solve the problem anyway (same error with the new port).

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 27, 2016):

Can you go to advanced settigns and choose your specific network interface instead of "any interface"? (might need to restart qbt) After that copy again the log (by selecting and right clicking copy)

@sledgehammer999 commented on GitHub (Jan 27, 2016): Can you go to advanced settigns and choose your specific network interface instead of "any interface"? (might need to restart qbt) After that copy again the log (by selecting and right clicking copy)

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 27, 2016):

After selecting the specific network interface in advanced settings, the error still shows up (qBT still seems to try to listen on the same UDP port twice), but magnet links now work again! :-)

Here is the log:

28/01/2016 00:17 - qBittorrent v3.3.3 started
28/01/2016 00:18 - Couldn't download favicon for URL 'http://rarbg.me/favicon.png'. Reason: The remote host name was not found (invalid hostname)
28/01/2016 00:18 - Couldn't download favicon for URL 'http://trackerfix.com/favicon.png'. Reason: The remote host name was not found (invalid hostname)
28/01/2016 00:18 - Couldn't download favicon for URL 'http://publicbt.com/favicon.png'. Reason: The remote host name was not found (invalid hostname)
28/01/2016 00:17 - Couldn't download favicon for URL 'http://rarbg.me/favicon.ico'. Reason: The remote host name was not found (invalid hostname)
28/01/2016 00:17 - Couldn't download favicon for URL 'http://trackerfix.com/favicon.ico'. Reason: The remote host name was not found (invalid hostname)
28/01/2016 00:17 - Couldn't download favicon for URL 'http://publicbt.com/favicon.ico'. Reason: The remote host name was not found (invalid hostname)
28/01/2016 00:17 - Couldn't download favicon for URL 'http://glotorrents.pw/favicon.png'. Reason: The remote content was not found at the server (404)
28/01/2016 00:17 - Couldn't download favicon for URL 'http://openbittorrent.com/favicon.ico'. Reason: The remote content was not found at the server (404)
28/01/2016 00:17 - Couldn't download favicon for URL 'http://glotorrents.pw/favicon.ico'. Reason: The remote content was not found at the server (404)
28/01/2016 00:17 - 'xxxxxxxxxxxxxxxxxxx' added to download list.
28/01/2016 00:17 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327
28/01/2016 00:17 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327
28/01/2016 00:17 - External IP: 79.52.xx.xx
28/01/2016 00:17 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Di norma è consentito un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta).
28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: UDP/29327
28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433
28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
28/01/2016 00:17 - Options were saved successfully.
28/01/2016 00:17 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016.
28/01/2016 00:17 - UPnP / NAT-PMP support [ON]
28/01/2016 00:17 - Embedded Tracker [OFF]
28/01/2016 00:17 - Encryption support [ON]
28/01/2016 00:17 - Local Peer Discovery support [ON]
28/01/2016 00:17 - PeX support [ON]
28/01/2016 00:17 - DHT support [ON]
28/01/2016 00:17 - Anonymous mode [OFF]
28/01/2016 00:17 - HTTP User-Agent is 'qBittorrent v3.3.3'
28/01/2016 00:17 - Peer ID: -qB3330-
28/01/2016 00:17 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327

@Lore21 commented on GitHub (Jan 27, 2016): After selecting the specific network interface in advanced settings, the error still shows up (qBT still seems to try to listen on the same UDP port twice), but magnet links now work again! :-) Here is the log: ``` 28/01/2016 00:17 - qBittorrent v3.3.3 started 28/01/2016 00:18 - Couldn't download favicon for URL 'http://rarbg.me/favicon.png'. Reason: The remote host name was not found (invalid hostname) 28/01/2016 00:18 - Couldn't download favicon for URL 'http://trackerfix.com/favicon.png'. Reason: The remote host name was not found (invalid hostname) 28/01/2016 00:18 - Couldn't download favicon for URL 'http://publicbt.com/favicon.png'. Reason: The remote host name was not found (invalid hostname) 28/01/2016 00:17 - Couldn't download favicon for URL 'http://rarbg.me/favicon.ico'. Reason: The remote host name was not found (invalid hostname) 28/01/2016 00:17 - Couldn't download favicon for URL 'http://trackerfix.com/favicon.ico'. Reason: The remote host name was not found (invalid hostname) 28/01/2016 00:17 - Couldn't download favicon for URL 'http://publicbt.com/favicon.ico'. Reason: The remote host name was not found (invalid hostname) 28/01/2016 00:17 - Couldn't download favicon for URL 'http://glotorrents.pw/favicon.png'. Reason: The remote content was not found at the server (404) 28/01/2016 00:17 - Couldn't download favicon for URL 'http://openbittorrent.com/favicon.ico'. Reason: The remote content was not found at the server (404) 28/01/2016 00:17 - Couldn't download favicon for URL 'http://glotorrents.pw/favicon.ico'. Reason: The remote content was not found at the server (404) 28/01/2016 00:17 - 'xxxxxxxxxxxxxxxxxxx' added to download list. 28/01/2016 00:17 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 28/01/2016 00:17 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 28/01/2016 00:17 - External IP: 79.52.xx.xx 28/01/2016 00:17 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Di norma è consentito un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta). 28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: UDP/29327 28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433 28/01/2016 00:17 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 28/01/2016 00:17 - Options were saved successfully. 28/01/2016 00:17 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016. 28/01/2016 00:17 - UPnP / NAT-PMP support [ON] 28/01/2016 00:17 - Embedded Tracker [OFF] 28/01/2016 00:17 - Encryption support [ON] 28/01/2016 00:17 - Local Peer Discovery support [ON] 28/01/2016 00:17 - PeX support [ON] 28/01/2016 00:17 - DHT support [ON] 28/01/2016 00:17 - Anonymous mode [OFF] 28/01/2016 00:17 - HTTP User-Agent is 'qBittorrent v3.3.3' 28/01/2016 00:17 - Peer ID: -qB3330- 28/01/2016 00:17 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327 ```

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 27, 2016):

@arvidn for some reason libtorrent sometimes tries to listen to UDP/port twice and it fails. Or the initial "success" alert may be false. I have never experienced it but this user (and others in the past) have. Any idea on whats wrong here?

@sledgehammer999 commented on GitHub (Jan 27, 2016): @arvidn for some reason libtorrent sometimes tries to listen to UDP/port twice and it fails. Or the initial "success" alert may be false. I have never experienced it but this user (and others in the past) have. Any idea on whats wrong here?

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 27, 2016):

the idea is that when it fails, the DHT stays inactive/broken because it doesn't have a socket?
this is 1.0.8?

@arvidn commented on GitHub (Jan 27, 2016): the idea is that when it fails, the DHT stays inactive/broken because it doesn't have a socket? this is 1.0.8?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 27, 2016):

the idea is that when it fails, the DHT stays inactive/broken because it doesn't have a socket?

I suppose so. The screenshots show zero DHT nodes.

this is 1.0.8?

Yes.

@sledgehammer999 commented on GitHub (Jan 27, 2016): > the idea is that when it fails, the DHT stays inactive/broken because it doesn't have a socket? I suppose so. The screenshots show zero DHT nodes. > this is 1.0.8? Yes.

deekerman commented

Author

Owner

@pete6055 commented on GitHub (Jan 28, 2016):

Here's the thing, Sledge.....this wasn't an issue in version 3.25. And, yes, it's the same issue I reported earlier but withdrew. And.... several other folks seem have reported the same problem under other titles.

I think it might have to do with router port forwarding, but I can't search the forum, though someone else mentioned there were instructions there.

Checking Random Ports at start seems to help, but sometimes I still run into a conflict. It's almost like the assigned port is not closed or cleared at the end of the qbit session. Maybe you could compare 3.25 to 3.3.3 to see what's different, but that seems like finding a needle in a haystack.

@pete6055 commented on GitHub (Jan 28, 2016): Here's the thing, Sledge.....this wasn't an issue in version 3.25. And, yes, it's the same issue I reported earlier but withdrew. And.... several other folks seem have reported the same problem under other titles. I think it might have to do with router port forwarding, but I can't search the forum, though someone else mentioned there were instructions there. Checking Random Ports at start seems to help, but sometimes I still run into a conflict. It's almost like the assigned port is not closed or cleared at the end of the qbit session. Maybe you could compare 3.25 to 3.3.3 to see what's different, but that seems like finding a needle in a haystack.

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 28, 2016):

if binding to a specific interface helps, it sounds like there might be two interfaces that end up having the same IP address assigned to them. That would be my first guess at least. libtorrent (by default) tries to bind to all interfaces by enumerating them, and then passing their IP to bind(). If two interfaces return the same IP, I would imagine the second socket would fail.

@arvidn commented on GitHub (Jan 28, 2016): if binding to a specific interface helps, it sounds like there might be two interfaces that end up having the same IP address assigned to them. That would be my first guess at least. libtorrent (by default) tries to bind to all interfaces by enumerating them, and then passing their IP to bind(). If two interfaces return the same IP, I would imagine the second socket would fail.

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 28, 2016):

In my case the binding error was still there even after selecting a specific interface instead of "All interfaces".

@Lore21 commented on GitHub (Jan 28, 2016): In my case the binding error was still there even after selecting a specific interface instead of "All interfaces".

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 29, 2016):

@sledgehammer999 I don't use SO_REUSEADDR on windows, because apparently it allows two live sockets to bind to the same port (as opposed to binding to a TIMED_WAIT port).

However, if the udp socket fails to bind, it's supposed to try again assuming you set a port range. Do you do that or just always specify a single port? It turns out the udp socket doesn't fall back to attempting to bind to port 0 (i.e. let the system pick one) since it's supposed to be bound to the same port as the TCP listen port. When announcing to a tracker you can only specify one port, not one for TCP and one for uTP.

@arvidn commented on GitHub (Jan 29, 2016): @sledgehammer999 I don't use SO_REUSEADDR on windows, because apparently it allows two live sockets to bind to the same port (as opposed to binding to a TIMED_WAIT port). However, if the udp socket fails to bind, it's supposed to try again assuming you set a port range. Do you do that or just always specify a single port? It turns out the udp socket doesn't fall back to attempting to bind to port 0 (i.e. let the system pick one) since it's supposed to be bound to the same port as the TCP listen port. When announcing to a tracker you can only specify one port, not one for TCP and one for uTP.

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 29, 2016):

Could someone give this patch a try? https://github.com/arvidn/libtorrent/pull/440

@arvidn commented on GitHub (Jan 29, 2016): Could someone give this patch a try? https://github.com/arvidn/libtorrent/pull/440

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 29, 2016):

) tries to bind to all interfaces by enumerating them, and then passing their IP to bind(). If two interfaces return the same IP, I would imagine the second socket would fail.

We pass specific local ip address to libtorrent unless "any interface" is configured by user where we let the system decide (eg 0.0.0.0 + :: )

just always specify a single port

We specify always one port.

It turns out the udp socket doesn't fall back to attempting to bind to port 0 (i.e. let the system pick one) since it's supposed to be bound to the same port as the TCP listen port

When using session::listen_on() we also use the session::listen_no_system_port flag. But we also configure the network via the session constructor too, where we can't pass that flag.

Could someone give this patch a try? arvidn/libtorrent#440

I'll provide a build now.

@sledgehammer999 commented on GitHub (Jan 29, 2016): > ) tries to bind to all interfaces by enumerating them, and then passing their IP to bind(). If two interfaces return the same IP, I would imagine the second socket would fail. We pass specific local ip address to libtorrent unless "any interface" is configured by user where we let the system decide (eg 0.0.0.0 + :: ) > just always specify a single port We specify always one port. > It turns out the udp socket doesn't fall back to attempting to bind to port 0 (i.e. let the system pick one) since it's supposed to be bound to the same port as the TCP listen port When using `session::listen_on()` we also use the `session::listen_no_system_port` flag. But we also configure the network via the session constructor too, where we can't pass that flag. > Could someone give this patch a try? arvidn/libtorrent#440 I'll provide a build now.

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 29, 2016):

@sledgehammer999 I think my patch can build now

@arvidn commented on GitHub (Jan 29, 2016): @sledgehammer999 I think my patch can build now

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 29, 2016):

@Lore21 can you try this build: http://builds.shiki.hu/temp/qbittorrent_3.3.3_for_issue_4693.7z
Just overwrite the old files.

@sledgehammer999 commented on GitHub (Jan 29, 2016): @Lore21 can you try this build: http://builds.shiki.hu/temp/qbittorrent_3.3.3_for_issue_4693.7z Just overwrite the old files.

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 29, 2016):

Tried it, I still get the same error:

30/01/2016 03:01 - qBittorrent v3.3.3 started
30/01/2016 03:01 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327
30/01/2016 03:01 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327
30/01/2016 03:01 - External IP: 79.52.xx.xx
30/01/2016 03:01 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Di norma è consentito un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta).
30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: UDP/29327
30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433
30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
30/01/2016 03:01 - Options were saved successfully.
30/01/2016 03:01 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016.
30/01/2016 03:01 - UPnP / NAT-PMP support [ON]
30/01/2016 03:01 - Embedded Tracker [OFF]
30/01/2016 03:01 - Encryption support [ON]
30/01/2016 03:01 - Local Peer Discovery support [ON]
30/01/2016 03:01 - PeX support [ON]
30/01/2016 03:01 - DHT support [ON]
30/01/2016 03:01 - Anonymous mode [OFF]
30/01/2016 03:01 - HTTP User-Agent is 'qBittorrent v3.3.3'
30/01/2016 03:01 - Peer ID: -qB3330-
30/01/2016 03:01 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327

@Lore21 commented on GitHub (Jan 29, 2016): Tried it, I still get the same error: ``` 30/01/2016 03:01 - qBittorrent v3.3.3 started 30/01/2016 03:01 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 30/01/2016 03:01 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 30/01/2016 03:01 - External IP: 79.52.xx.xx 30/01/2016 03:01 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Di norma è consentito un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta). 30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: UDP/29327 30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433 30/01/2016 03:01 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 30/01/2016 03:01 - Options were saved successfully. 30/01/2016 03:01 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016. 30/01/2016 03:01 - UPnP / NAT-PMP support [ON] 30/01/2016 03:01 - Embedded Tracker [OFF] 30/01/2016 03:01 - Encryption support [ON] 30/01/2016 03:01 - Local Peer Discovery support [ON] 30/01/2016 03:01 - PeX support [ON] 30/01/2016 03:01 - DHT support [ON] 30/01/2016 03:01 - Anonymous mode [OFF] 30/01/2016 03:01 - HTTP User-Agent is 'qBittorrent v3.3.3' 30/01/2016 03:01 - Peer ID: -qB3330- 30/01/2016 03:01 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327 ```

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 29, 2016):

@Lore21 other than the error message in the log. do you experience the same symptom of not having a UDP socket / working DHT? (obviously under your original settings)

@arvidn commented on GitHub (Jan 29, 2016): @Lore21 other than the error message in the log. do you experience the same symptom of not having a UDP socket / working DHT? (obviously under your original settings)

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 29, 2016):

Yes, I do: DHT stuck at 0 nodes/yellow icon.
And the magnet links are not starting again: it seems the one that worked a couple of days ago was only a lucky chance...

@Lore21 commented on GitHub (Jan 29, 2016): Yes, I do: DHT stuck at 0 nodes/yellow icon. And the magnet links are not starting again: it seems the one that worked a couple of days ago was only a lucky chance...

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 30, 2016):

@sledgehammer999 I added one more commit attempting to address the udp bind error. When creating the sockets and binding them, I close the existing ones first. It turned out I had forgotten to close the UDP socket (or at least it appears so). with the listen_on() interface, it's easy for a client to kick the open-sockets logic twice. It's possible that qBT does, and sometimes the second time fails because the first one wasn't closed properly.

anyway, it's a bit of a long shot. If you wouldn't mind rebuilding, I'd be curious to know if this solves Lore21's problem.

@arvidn commented on GitHub (Jan 30, 2016): @sledgehammer999 I added one more commit attempting to address the udp bind error. When creating the sockets and binding them, I close the existing ones first. It turned out I had forgotten to close the UDP socket (or at least it appears so). with the listen_on() interface, it's easy for a client to kick the open-sockets logic twice. It's possible that qBT does, and sometimes the second time fails because the first one wasn't closed properly. anyway, it's a bit of a long shot. If you wouldn't mind rebuilding, I'd be curious to know if this solves Lore21's problem.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 30, 2016):

@Lore21 can you try this: http://builds.shiki.hu/temp/qbittorrent_3.3.3_for_issue_4693_v2.7z

@arvidn we don't call listen_on() if the interface/port hasn't changed since session construction.

@sledgehammer999 commented on GitHub (Jan 30, 2016): @Lore21 can you try this: http://builds.shiki.hu/temp/qbittorrent_3.3.3_for_issue_4693_v2.7z @arvidn we don't call listen_on() if the interface/port hasn't changed since session construction.

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 30, 2016):

Different error(s) this time: "The I/O operation has been aborted because of either a thread exit or an application request" (translated to english)

30/01/2016 21:43 - qBittorrent v3.3.3 started
30/01/2016 21:43 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Operazione di I/O terminata a causa dell'uscita dal thread oppure della richiesta di un'applicazione.
30/01/2016 21:43 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
30/01/2016 21:43 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Operazione di I/O terminata a causa dell'uscita dal thread oppure della richiesta di un'applicazione.
30/01/2016 21:43 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433
30/01/2016 21:43 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
30/01/2016 21:43 - Options were saved successfully.
30/01/2016 21:43 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016.
30/01/2016 21:43 - UPnP / NAT-PMP support [ON]
30/01/2016 21:43 - Embedded Tracker [OFF]
30/01/2016 21:43 - Encryption support [ON]
30/01/2016 21:43 - Local Peer Discovery support [ON]
30/01/2016 21:43 - PeX support [ON]
30/01/2016 21:43 - DHT support [ON]
30/01/2016 21:43 - Anonymous mode [OFF]
30/01/2016 21:43 - HTTP User-Agent is 'qBittorrent v3.3.3'
30/01/2016 21:43 - Peer ID: -qB3330-
30/01/2016 21:43 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327
30/01/2016 21:43 - External IP: 79.52.xx.xx
30/01/2016 21:43 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327

@Lore21 commented on GitHub (Jan 30, 2016): Different error(s) this time: "The I/O operation has been aborted because of either a thread exit or an application request" (translated to english) ``` 30/01/2016 21:43 - qBittorrent v3.3.3 started 30/01/2016 21:43 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Operazione di I/O terminata a causa dell'uscita dal thread oppure della richiesta di un'applicazione. 30/01/2016 21:43 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 30/01/2016 21:43 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Operazione di I/O terminata a causa dell'uscita dal thread oppure della richiesta di un'applicazione. 30/01/2016 21:43 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433 30/01/2016 21:43 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 30/01/2016 21:43 - Options were saved successfully. 30/01/2016 21:43 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016. 30/01/2016 21:43 - UPnP / NAT-PMP support [ON] 30/01/2016 21:43 - Embedded Tracker [OFF] 30/01/2016 21:43 - Encryption support [ON] 30/01/2016 21:43 - Local Peer Discovery support [ON] 30/01/2016 21:43 - PeX support [ON] 30/01/2016 21:43 - DHT support [ON] 30/01/2016 21:43 - Anonymous mode [OFF] 30/01/2016 21:43 - HTTP User-Agent is 'qBittorrent v3.3.3' 30/01/2016 21:43 - Peer ID: -qB3330- 30/01/2016 21:43 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327 30/01/2016 21:43 - External IP: 79.52.xx.xx 30/01/2016 21:43 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 ```

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 30, 2016):

and does the problem of the DHT not working persist?

@arvidn commented on GitHub (Jan 30, 2016): and does the problem of the DHT not working persist?

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 30, 2016):

Yes, 0 nodes/yellow icon

@Lore21 commented on GitHub (Jan 30, 2016): Yes, 0 nodes/yellow icon

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 30, 2016):

@arvidn now I get the same errors with RC_1_1 plus some new ones(and of course 0 dht nodes). Check this log:

31/1/2016 12:52 πμ - qBittorrent v3.4.0alpha started
31/1/2016 12:52 πμ - qBittorrent failed listening on interface 0.0.0.0:7619. Reason: Only one usage of each socket address (protocol/network address/port) is normally permitted.
31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/7619
31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/4433
31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP_SSL/4433
31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/7619
31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface :: port: TCP_SSL/4433
31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface :: port: TCP/7619
31/1/2016 12:52 πμ - qBittorrent failed listening on interface 127.0.0.1:7619. Reason: No such device.
31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device.
31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device.
31/1/2016 12:52 πμ - qBittorrent failed listening on interface 127.0.0.1:7619. Reason: No such device.
31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device.
31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device.
31/1/2016 12:52 πμ - Options were saved successfully.
31/1/2016 12:52 πμ - The Web UI is listening on port 30077
31/1/2016 12:52 πμ - GeoIP database loaded. Type: GeoLite2-Country. Build time: Τρι Ιαν 5 21:35:34 2016.
31/1/2016 12:52 πμ - UPnP / NAT-PMP support [ON]
31/1/2016 12:52 πμ - Embedded Tracker [OFF]
31/1/2016 12:52 πμ - Encryption support [ON]
31/1/2016 12:52 πμ - Local Peer Discovery support [ON]
31/1/2016 12:52 πμ - PeX support [ON]
31/1/2016 12:52 πμ - DHT support [ON]
31/1/2016 12:52 πμ - Anonymous mode [OFF]
31/1/2016 12:52 πμ - HTTP User-Agent is 'qBittorrent v3.4.0alpha'
31/1/2016 12:52 πμ - qBittorrent is trying to listen on any interface port: 7619
31/1/2016 12:52 πμ - Peer ID: -qB3400-
31/1/2016 12:52 πμ - qBittorrent is trying to listen on any interface port: 7619

I don't think I ever pass "null" or "127.0.0.1" as interface.

@sledgehammer999 commented on GitHub (Jan 30, 2016): @arvidn now I get the same errors with RC_1_1 plus some new ones(and of course 0 dht nodes). Check this log: ``` 31/1/2016 12:52 πμ - qBittorrent v3.4.0alpha started 31/1/2016 12:52 πμ - qBittorrent failed listening on interface 0.0.0.0:7619. Reason: Only one usage of each socket address (protocol/network address/port) is normally permitted. 31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: UDP/7619 31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/4433 31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP_SSL/4433 31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface 0.0.0.0 port: TCP/7619 31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface :: port: TCP_SSL/4433 31/1/2016 12:52 πμ - qBittorrent is successfully listening on interface :: port: TCP/7619 31/1/2016 12:52 πμ - qBittorrent failed listening on interface 127.0.0.1:7619. Reason: No such device. 31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device. 31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device. 31/1/2016 12:52 πμ - qBittorrent failed listening on interface 127.0.0.1:7619. Reason: No such device. 31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device. 31/1/2016 12:52 πμ - qBittorrent failed listening on interface (null). Reason: No such device. 31/1/2016 12:52 πμ - Options were saved successfully. 31/1/2016 12:52 πμ - The Web UI is listening on port 30077 31/1/2016 12:52 πμ - GeoIP database loaded. Type: GeoLite2-Country. Build time: Τρι Ιαν 5 21:35:34 2016. 31/1/2016 12:52 πμ - UPnP / NAT-PMP support [ON] 31/1/2016 12:52 πμ - Embedded Tracker [OFF] 31/1/2016 12:52 πμ - Encryption support [ON] 31/1/2016 12:52 πμ - Local Peer Discovery support [ON] 31/1/2016 12:52 πμ - PeX support [ON] 31/1/2016 12:52 πμ - DHT support [ON] 31/1/2016 12:52 πμ - Anonymous mode [OFF] 31/1/2016 12:52 πμ - HTTP User-Agent is 'qBittorrent v3.4.0alpha' 31/1/2016 12:52 πμ - qBittorrent is trying to listen on any interface port: 7619 31/1/2016 12:52 πμ - Peer ID: -qB3400- 31/1/2016 12:52 πμ - qBittorrent is trying to listen on any interface port: 7619 ``` I don't think I ever pass "null" or "127.0.0.1" as interface.

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 31, 2016):

is this on windows?

@arvidn commented on GitHub (Jan 31, 2016): is this on windows?

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 31, 2016):

unfortunately the setting up of listening sockets is a bit of a mess. I have an outstanding patch against master (which is still pretty far from complete) to clean it up and simplify it. I don't think it's realistic to solve the underlying problem for 1.0.9, I was hoping that I could solve it without too much surgery.

I'll take a look what can be done in RC_1_1

@arvidn commented on GitHub (Jan 31, 2016): unfortunately the setting up of listening sockets is a bit of a mess. I have an outstanding patch against master (which is still pretty far from complete) to clean it up and simplify it. I don't think it's realistic to solve the underlying problem for 1.0.9, I was hoping that I could solve it without too much surgery. I'll take a look what can be done in RC_1_1

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 31, 2016):

here's one more attempt in RC_1_0 https://github.com/arvidn/libtorrent/pull/444

@arvidn commented on GitHub (Jan 31, 2016): here's one more attempt in RC_1_0 https://github.com/arvidn/libtorrent/pull/444

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 31, 2016):

Yes, windows. And I am preparing a new build for testing based on your new patch.

@sledgehammer999 commented on GitHub (Jan 31, 2016): Yes, windows. And I am preparing a new build for testing based on your new patch.

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Jan 31, 2016):

@Lore21 can you try this: http://builds.shiki.hu/temp/qbittorrent_3.3.3_for_issue_4693_v3.7z

@sledgehammer999 commented on GitHub (Jan 31, 2016): @Lore21 can you try this: http://builds.shiki.hu/temp/qbittorrent_3.3.3_for_issue_4693_v3.7z

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Jan 31, 2016):

Back to the original error:

31/01/2016 19:16 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327
31/01/2016 19:16 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327
31/01/2016 19:16 - External IP: xx.xx.xx.xx
31/01/2016 19:16 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Di norma è consentito un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta).
31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: UDP/29327
31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433
31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327
31/01/2016 19:16 - Options were saved successfully.
31/01/2016 19:16 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016.
31/01/2016 19:16 - UPnP / NAT-PMP support [ON]
31/01/2016 19:16 - Embedded Tracker [OFF]
31/01/2016 19:15 - Encryption support [ON]
31/01/2016 19:15 - Local Peer Discovery support [ON]
31/01/2016 19:15 - PeX support [ON]
31/01/2016 19:15 - DHT support [ON]
31/01/2016 19:15 - Anonymous mode [OFF]
31/01/2016 19:15 - HTTP User-Agent is 'qBittorrent v3.3.3'
31/01/2016 19:15 - Peer ID: -qB3330-
31/01/2016 19:15 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327
31/01/2016 19:15 - qBittorrent v3.3.3 started

@Lore21 commented on GitHub (Jan 31, 2016): Back to the original error: ``` 31/01/2016 19:16 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 31/01/2016 19:16 - UPnP/NAT-PMP: Port mapping successful, message: successfully mapped port using UPnP. external port: 29327 31/01/2016 19:16 - External IP: xx.xx.xx.xx 31/01/2016 19:16 - qBittorrent failed listening on interface 192.168.1.21 port: UDP/29327. Reason: Di norma è consentito un solo utilizzo di ogni indirizzo di socket (protocollo/indirizzo di rete/porta). 31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: UDP/29327 31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP_SSL/4433 31/01/2016 19:16 - qBittorrent is successfully listening on interface 192.168.1.21 port: TCP/29327 31/01/2016 19:16 - Options were saved successfully. 31/01/2016 19:16 - GeoIP database loaded. Type: GeoLite2-Country. Build time: mar gen 5 20:35:34 2016. 31/01/2016 19:16 - UPnP / NAT-PMP support [ON] 31/01/2016 19:16 - Embedded Tracker [OFF] 31/01/2016 19:15 - Encryption support [ON] 31/01/2016 19:15 - Local Peer Discovery support [ON] 31/01/2016 19:15 - PeX support [ON] 31/01/2016 19:15 - DHT support [ON] 31/01/2016 19:15 - Anonymous mode [OFF] 31/01/2016 19:15 - HTTP User-Agent is 'qBittorrent v3.3.3' 31/01/2016 19:15 - Peer ID: -qB3330- 31/01/2016 19:15 - qBittorrent is trying to listen on interface 192.168.1.21 port: 29327 31/01/2016 19:15 - qBittorrent v3.3.3 started ```

deekerman commented

Author

Owner

@arvidn commented on GitHub (Jan 31, 2016):

ok. there appears to be some event triggered that attempts to re-bind the UDP socket. I'll take a look what possibly could be doing that.

@sledgehammer999 would you mind creating a ticket against libtorrent for the RC_1_1 behavior you're seeing? please include that log and also what you pass in to listen_on() or the listen_interfaces setting.

@arvidn commented on GitHub (Jan 31, 2016): ok. there appears to be some event triggered that attempts to re-bind the UDP socket. I'll take a look what possibly could be doing that. @sledgehammer999 would you mind creating a ticket against libtorrent for the RC_1_1 behavior you're seeing? please include that log and also what you pass in to listen_on() or the listen_interfaces setting.

deekerman commented

Author

Owner

@arvidn commented on GitHub (Feb 2, 2016):

@sledgehammer999 do you think there's any way I could reproduce, or attempt to reproduce, this error with client_test.cpp? could you describe how you interact with the session, specifically around how you tell it which IP and port to listen on?

@arvidn commented on GitHub (Feb 2, 2016): @sledgehammer999 do you think there's any way I could reproduce, or attempt to reproduce, this error with client_test.cpp? could you describe how you interact with the session, specifically around how you tell it which IP and port to listen on?

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Feb 2, 2016):

do you think there's any way I could reproduce, or attempt to reproduce, this error with client_test.cpp?

I can't reproduce it myself with RC_1_0. Only with RC_1_1(I'll open a bug report shortly). I have made a very simple test program for @Lore21 to test. It just starts a libtorrent session and watches for the listen succeded/failed alerts. Nothing else. Build against latest RC_1_0.

@Lore21 can you try the following program: http://builds.shiki.hu/temp/test_interface_listen.7z
Open a console window and navigate to it. Noob instructions:

Start->Run...
Enter cmd and hit OK.
In the console window issue cd <path-to-the-folder-that-contains-the-extracted-exe>
Then issue test_interface_listen. It should output something in the console.
Wait a few seconds and then press Ctrl+C
Copy the output text here or screenshot it.

And for completeness sake here is the source code for test_interface_listen:

#include <iostream>
#include <libtorrent/session.hpp>
#include <libtorrent/alert_types.hpp>

using namespace std;
using namespace libtorrent;

void dispatchAlerts(auto_ptr<alert> alertPtr)
{
    switch (alertPtr->type()) {
    case listen_succeeded_alert::alert_type: {

        listen_succeeded_alert *a = static_cast<listen_succeeded_alert*>(alertPtr.get());
        boost::system::error_code ec;

        string proto = "TCP";
        if (a->sock_type == listen_succeeded_alert::udp)
            proto = "UDP";
        else if (a->sock_type == listen_succeeded_alert::tcp)
            proto = "TCP";
        else if (a->sock_type == listen_succeeded_alert::tcp_ssl)
            proto = "TCP_SSL";
        else
            proto = "OTHER";

        cout << "Listen succeeded on interface: " << a->endpoint.address().to_string(ec).c_str() << " port: " << proto << "/" << a->endpoint.port() << endl;
        break;
    }
    case listen_failed_alert::alert_type: {

        listen_failed_alert *a = static_cast<listen_failed_alert*>(alertPtr.get());
        boost::system::error_code ec;

        string proto = "TCP";
        if (a->sock_type == listen_failed_alert::udp)
            proto = "UDP";
        else if (a->sock_type == listen_failed_alert::tcp)
            proto = "TCP";
        else if (a->sock_type == listen_failed_alert::tcp_ssl)
            proto = "TCP_SSL";
        else
            proto = "OTHER";

        cout << "Listen failed on interface: " << a->endpoint.address().to_string(ec).c_str() << " port: " << proto << "/" << a->endpoint.port() << endl;
        break;
    }

    default:
        break;
    }

}

int main()
{
    fingerprint finger("LT", 1, 0, 8, 0);
    std::pair<int,int> ports(29327, 29327);
    int alertMask = alert::error_notification
                    | alert::peer_notification
                    | alert::port_mapping_notification
                    | alert::storage_notification
                    | alert::tracker_notification
                    | alert::status_notification
                    | alert::ip_block_notification
                    | alert::progress_notification
                    | alert::stats_notification
                    ;

    session nativeSession(finger, ports, 0, 0, alertMask);
    nativeSession.set_alert_dispatch(&dispatchAlerts);

    while (true)
        ;

    return 0;
}

@sledgehammer999 commented on GitHub (Feb 2, 2016): > do you think there's any way I could reproduce, or attempt to reproduce, this error with client_test.cpp? I can't reproduce it myself with RC_1_0. Only with RC_1_1(I'll open a bug report shortly). I have made a very simple test program for @Lore21 to test. It just starts a libtorrent session and watches for the listen succeded/failed alerts. Nothing else. Build against latest RC_1_0. @Lore21 can you try the following program: http://builds.shiki.hu/temp/test_interface_listen.7z Open a console window and navigate to it. Noob instructions: 1. Start->Run... 2. Enter `cmd` and hit OK. 3. In the console window issue `cd <path-to-the-folder-that-contains-the-extracted-exe>` 4. Then issue `test_interface_listen`. It should output something in the console. 5. Wait a few seconds and then press `Ctrl+C` 6. Copy the output text here or screenshot it. And for completeness sake here is the source code for `test_interface_listen`: ``` c++ #include <iostream> #include <libtorrent/session.hpp> #include <libtorrent/alert_types.hpp> using namespace std; using namespace libtorrent; void dispatchAlerts(auto_ptr<alert> alertPtr) { switch (alertPtr->type()) { case listen_succeeded_alert::alert_type: { listen_succeeded_alert *a = static_cast<listen_succeeded_alert*>(alertPtr.get()); boost::system::error_code ec; string proto = "TCP"; if (a->sock_type == listen_succeeded_alert::udp) proto = "UDP"; else if (a->sock_type == listen_succeeded_alert::tcp) proto = "TCP"; else if (a->sock_type == listen_succeeded_alert::tcp_ssl) proto = "TCP_SSL"; else proto = "OTHER"; cout << "Listen succeeded on interface: " << a->endpoint.address().to_string(ec).c_str() << " port: " << proto << "/" << a->endpoint.port() << endl; break; } case listen_failed_alert::alert_type: { listen_failed_alert *a = static_cast<listen_failed_alert*>(alertPtr.get()); boost::system::error_code ec; string proto = "TCP"; if (a->sock_type == listen_failed_alert::udp) proto = "UDP"; else if (a->sock_type == listen_failed_alert::tcp) proto = "TCP"; else if (a->sock_type == listen_failed_alert::tcp_ssl) proto = "TCP_SSL"; else proto = "OTHER"; cout << "Listen failed on interface: " << a->endpoint.address().to_string(ec).c_str() << " port: " << proto << "/" << a->endpoint.port() << endl; break; } default: break; } } int main() { fingerprint finger("LT", 1, 0, 8, 0); std::pair<int,int> ports(29327, 29327); int alertMask = alert::error_notification | alert::peer_notification | alert::port_mapping_notification | alert::storage_notification | alert::tracker_notification | alert::status_notification | alert::ip_block_notification | alert::progress_notification | alert::stats_notification ; session nativeSession(finger, ports, 0, 0, alertMask); nativeSession.set_alert_dispatch(&dispatchAlerts); while (true) ; return 0; } ```

deekerman commented

Author

Owner

@arvidn commented on GitHub (Feb 2, 2016):

@sledgehammer999 maybe you could enable verbose logging in that build too

@arvidn commented on GitHub (Feb 2, 2016): @sledgehammer999 maybe you could enable verbose logging in that build too

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Feb 2, 2016):

Below is the output of the test program:

Listen succeeded on interface: 0.0.0.0 port: TCP/29327
Listen succeeded on interface: 0.0.0.0 port: TCP_SSL/4433
Listen succeeded on interface: :: port: TCP/29327
Listen succeeded on interface: :: port: TCP_SSL/4433
Listen succeeded on interface: 0.0.0.0 port: UDP/29327

@Lore21 commented on GitHub (Feb 2, 2016): Below is the output of the test program: ``` Listen succeeded on interface: 0.0.0.0 port: TCP/29327 Listen succeeded on interface: 0.0.0.0 port: TCP_SSL/4433 Listen succeeded on interface: :: port: TCP/29327 Listen succeeded on interface: :: port: TCP_SSL/4433 Listen succeeded on interface: 0.0.0.0 port: UDP/29327 ```

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Feb 2, 2016):

Can you do the same with the following build? Try running multiple times, you should get a "Listen failed blah blah" message in one of those times. It is a race condition somewhere and it doesn't always fail.
See my description here: https://github.com/arvidn/libtorrent/issues/450
Build: http://builds.shiki.hu/temp/test_interface_listen_v2.7z

@sledgehammer999 commented on GitHub (Feb 2, 2016): Can you do the same with the following build? Try running multiple times, you should get a "Listen failed blah blah" message in one of those times. It is a race condition somewhere and it doesn't always fail. See my description here: https://github.com/arvidn/libtorrent/issues/450 Build: http://builds.shiki.hu/temp/test_interface_listen_v2.7z

deekerman commented

Author

Owner

@Lore21 commented on GitHub (Feb 2, 2016):

It executed 22 times in a row without errors (all "Listen succeeded on interface..."), then on the 23rd execution I got:

Listen succeeded on interface: 0.0.0.0 port: TCP/29327
Listen succeeded on interface: 0.0.0.0 port: TCP_SSL/4433
Listen succeeded on interface: :: port: TCP/29327
Listen succeeded on interface: :: port: TCP_SSL/4433
Listen succeeded on interface: 0.0.0.0 port: UDP/29327
Listen succeeded on interface: 0.0.0.0 port: TCP/29327
Listen succeeded on interface: :: port: TCP/29327
Listen failed on interface: 0.0.0.0 port: UDP/29327

@Lore21 commented on GitHub (Feb 2, 2016): It executed 22 times in a row without errors (all "Listen succeeded on interface..."), then on the 23rd execution I got: ``` Listen succeeded on interface: 0.0.0.0 port: TCP/29327 Listen succeeded on interface: 0.0.0.0 port: TCP_SSL/4433 Listen succeeded on interface: :: port: TCP/29327 Listen succeeded on interface: :: port: TCP_SSL/4433 Listen succeeded on interface: 0.0.0.0 port: UDP/29327 Listen succeeded on interface: 0.0.0.0 port: TCP/29327 Listen succeeded on interface: :: port: TCP/29327 Listen failed on interface: 0.0.0.0 port: UDP/29327 ```

deekerman commented

Author

Owner

@sledgehammer999 commented on GitHub (Feb 2, 2016):

then on the 23rd execution I got:

Nice. @arvidn that build applies session setting with ssl_listen set to zero.

@sledgehammer999 commented on GitHub (Feb 2, 2016): > then on the 23rd execution I got: Nice. @arvidn that build applies session setting with `ssl_listen` set to zero.

deekerman commented

Author

Owner

@arvidn commented on GitHub (Feb 3, 2016):

I opened a ticket for the UDP socket bind issue. https://github.com/arvidn/libtorrent/issues/454
and sledgehammer999 opened a separate issue for the failure he discovered in RC_1_1 https://github.com/arvidn/libtorrent/issues/450

@arvidn commented on GitHub (Feb 3, 2016): I opened a ticket for the UDP socket bind issue. https://github.com/arvidn/libtorrent/issues/454 and sledgehammer999 opened a separate issue for the failure he discovered in RC_1_1 https://github.com/arvidn/libtorrent/issues/450

deekerman commented

Author

Owner

@arvidn commented on GitHub (Feb 7, 2016):

FYI. I have un-deprecated the endpoint field in listen_failed_alert. I realized it does make sense to keep it around, after having spent some more time on working on the direction I want to go to simplify and unify the socket listen logic in master.

@arvidn commented on GitHub (Feb 7, 2016): FYI. I have un-deprecated the endpoint field in listen_failed_alert. I realized it does make sense to keep it around, after having spent some more time on working on the direction I want to go to simplify and unify the socket listen logic in master.

deekerman commented