Custom Query (2449 matches)
Results (601 - 603 of 2449)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #2325 | Fixed | [win32] Unistalling will delete everything under install directory | ||
| Description |
If not using usual http://git.deluge-torrent.org/deluge/tree/win32/deluge-win32-installer.nsi?h=1.3-stable#n216 Section Uninstall RmDir /r "$INSTDIR" Possible solution: http://nsis.sourceforge.net/Uninstall_only_installed_files |
|||
| #2324 | Fixed | deluge and crypto_provide | ||
| Description |
deluge gtk appears to be requesting libtorrent to send an incorrect bitfield for crypto_provide on outbound connections. original forum post: http://forum.deluge-torrent.org/viewtopic.php?f=8&t=43859 libtorrent ticket: https://code.google.com/p/libtorrent/issues/detail?id=474 in a nutshell, deluge gtk is sending via libtorrent: bitfield 0x00 instead of 0x01 when requesting handshake/plaintext encryption from the outbound peer. bitfield 0x01 instead of 0x02 when requesting fullstream encryption from the outbound peer. bitfield 0x02 instead of 0x03 when requesting the outbound peer choose their preferred encryption method. the implications of this vary depending on which encryption method the user has selected in the gui. worst case scenario is no outbound peering occurs if the user has selected handshake/plaintext encryption as their encryption method. outbound peering appears to occur for "fullstream" and "choose" but i suspect the encryption level selected by the peer is actually always "handshake/plaintext" and "fullstream" respectively. however i'm not 100% sure of this, it's a suspicion. regards tristen |
|||
| #2323 | WorksForMe | [win32] https tracker issue with libtorrent 0.16.x on windows 2.7py client | ||
| Description |
on version 1.3.6- 2.7python libtorrent 0.16.x on Windows client, the client is unable to connect to https trackers duo to some issue with libtorrent. |
|||
