Deluge
Shryp: Thank you so very much! This is exactly what I need to know - the detailed instructions!
Uninstalling a software may be a problematic thing if one only wants software affected and wants to keep data and settings. I always use default installation settings to keep reinstallation, reconfiguration etc as simple as possible although you recommend starting installation with uninstalling the present Deluge. It should be possible to install a new version over an existing as the expected result would be replacing old program files with new ones and restart application, possibly after a reboot. But no problem, I will not do any experimental issues but follow your advises.
And your advises are trustworthy, however, I will shedule these actions to take place after next backup scheduled here (Sunday evening) which means Monday morning. This is only because I have never uninstalled the Deluge before to make a clean install and hopefully keep all internal settings. I can also make mistakes, mispreting something etc. I will report back how this task has completed (successfully, I hope).
The actual problem is the "Next Announcement" execution. The behavior is not always as expected, sometimes I am told "Announce sent" and relatively often the time scheduled for "Next Announce" is blanked out with no other effect detectable. The receiving tracker removes of course its notification about the torrent concerned to be seeded after a while. I don't understand completely yet what happens and why. But maybe it will be clarified. Someone said that this probably depends on a too old and buggy libtorrent.pyd (0.16.18.0 from original installation). Myself I don't know - I don't see any diagnostic information about what happens! And I am not fully aware about the internal processing logic in the Deluge.
Kind regards,
Axel
Libtorrent 1.0.4 compiled - for those with speed issues
Re: Libtorrent 1.0.4 compiled - for those with speed issues
You can install over the older one without uninstalling, however myself and a couple other people noticed that installing the py2.7 version on top of the py2.6 version causes crashes when trying to start it. That is why I said uninstall first. Uninstall will delete the folder C:\Program Files (x86)\Deluge. That is ok because all of your settings are in the folder C:\Users\[user name]\AppData\Roaming\deluge.
Deluge is just a fancy interface that runs on top of libtorrent. Libtorrent is the actual program that handles all the download logic stuff.
Deluge is just a fancy interface that runs on top of libtorrent. Libtorrent is the actual program that handles all the download logic stuff.
Re: Libtorrent 1.0.4 compiled - for those with speed issues
Thanks, Shryp!
My actual problem is that tracker and client do not cooperate properly, the information I see is that the Announce synchronisation doesn't seem to work well when I run a considerable amount of torrents, but I don't understand why. Recently slightly more than 4000 torrents are up and and running at the client side. I found that changing buffer size had some effect.
Download works relatively good but Deluge runs download even to torrents said to be in paused state. This is confusing. But Announce status seems to be okay - it runs although the "paused" state.
Seeds has worser problems It drops Announce settings when a "Next Announce" occurs and at the tracker side the seeded torrents are removed as being up and running after a while, obviously because the client has stopped Announce synchronisation accordingly to the changed "Next Announcee" setting. The seed count in the tracker goes down to zero. But client says it's seeding. It is a status mismatch but I don't understand why.
Programming error? Or simply timeout when client waits for Announce acknowledgement from tracker?
Typically it looks like errors in internal buffer error in the Announce exchange process like SYN-ACK-SYN handshake, maybe buffer overflow somewhere due to a larger number of concurrent torrents? Therefore, I do updating of the softwares concerned - hopefully the problems I see maybe have been fixed. I can also have misconfigured something in the libtorrent - there are lots of settings and I am not fully aware about which settings who apply nor what their effects could be.
But the very first thing to do is to upgrade to actual versions of the helper software in use. And then consider the settings offered via the ItConfig plugin more in detail and their effects in this Announce synchronisation perspective.
Many thanks for your comments! They are valuable!
Axel
My actual problem is that tracker and client do not cooperate properly, the information I see is that the Announce synchronisation doesn't seem to work well when I run a considerable amount of torrents, but I don't understand why. Recently slightly more than 4000 torrents are up and and running at the client side. I found that changing buffer size had some effect.
Download works relatively good but Deluge runs download even to torrents said to be in paused state. This is confusing. But Announce status seems to be okay - it runs although the "paused" state.
Seeds has worser problems It drops Announce settings when a "Next Announce" occurs and at the tracker side the seeded torrents are removed as being up and running after a while, obviously because the client has stopped Announce synchronisation accordingly to the changed "Next Announcee" setting. The seed count in the tracker goes down to zero. But client says it's seeding. It is a status mismatch but I don't understand why.
Programming error? Or simply timeout when client waits for Announce acknowledgement from tracker?
Typically it looks like errors in internal buffer error in the Announce exchange process like SYN-ACK-SYN handshake, maybe buffer overflow somewhere due to a larger number of concurrent torrents? Therefore, I do updating of the softwares concerned - hopefully the problems I see maybe have been fixed. I can also have misconfigured something in the libtorrent - there are lots of settings and I am not fully aware about which settings who apply nor what their effects could be.
But the very first thing to do is to upgrade to actual versions of the helper software in use. And then consider the settings offered via the ItConfig plugin more in detail and their effects in this Announce synchronisation perspective.
Many thanks for your comments! They are valuable!
Axel
Re: Libtorrent 1.0.4 compiled - for those with speed issues
Not quite certain yet, but the Anounce problem doesn't seem to be related to the Deluge, Python nor libtorrent. I suspect that it is a tracker issue and concerns the handshake process the "Announce" function indeed represents. Some type of mismatch in the request/reply exchange process, which causes malfunction and no "overall" compatibility regardless of BitTorrent software vendor. Now the "Announcement" seems to work properly to me and it is not due to some configuration change I have done. I was running the Deluge client "as is" waiting for doing Python and libtorrent updates after the weekly scheduled backup being taken on regular basis. I could of course force extra backup, but planned to wait for ordinaru weekly backup to take place as scheduled. I intended to restart the Deluge client when ongoing seed processes "deceased". due to this "Announce" handshake failure.
An unexpected solution, but I don't control both ends myself of the process.
So there I am now.
Update:
I finally found out the libtorrent settings giving the Deluge behavior I expected. So there is not necessary to update Python and libtorrent versions right now. I would prefer my Deluge to conform with the standard design currently being distributed rather than myself manipulating versions of individual components - the maintenance should primarily be distributed centrally bu Deluge vendors for good effectiveness and a minimum of customer personal maintenance although this area is exciting and I am interested in evolving the Deluge as product. But I cannot do that for so many software products in my computer and moreover, doing such a job should be coordinated at vendor level and be distributed to all customers as an update,
Another reason to limit such workouts is that the free Microsoft Windows 10 distribution will take place in about two weeks according to the MS announcement. Therefore, I lock the computer in the current, fully workingm state with no true problems to simplify the upgrade to Windows 10 (and, if required, go back to the older version from actual backup). I don't want to be sitting with a nonworking computer for long time, days and maybe weeks, while analysing and correcting possible upgrade problems.
Also, I don't know whether the Deluge will persist the Windows 10 upgrade, I haven't seen any Windows 10 certification of the Deluge. But Deluge is relatively uncomplex at OS level (no strong OS or HW dependencies) so I don't belive in any serious problems regarding Deluge when upgrading to Windows 10.
Exciting, isn't? I belive in a seamless upgrade of the OS anyhow regarding the Deluge function due to its general structure and implementation.
An unexpected solution, but I don't control both ends myself of the process.
So there I am now.
Update:
I finally found out the libtorrent settings giving the Deluge behavior I expected. So there is not necessary to update Python and libtorrent versions right now. I would prefer my Deluge to conform with the standard design currently being distributed rather than myself manipulating versions of individual components - the maintenance should primarily be distributed centrally bu Deluge vendors for good effectiveness and a minimum of customer personal maintenance although this area is exciting and I am interested in evolving the Deluge as product. But I cannot do that for so many software products in my computer and moreover, doing such a job should be coordinated at vendor level and be distributed to all customers as an update,
Another reason to limit such workouts is that the free Microsoft Windows 10 distribution will take place in about two weeks according to the MS announcement. Therefore, I lock the computer in the current, fully workingm state with no true problems to simplify the upgrade to Windows 10 (and, if required, go back to the older version from actual backup). I don't want to be sitting with a nonworking computer for long time, days and maybe weeks, while analysing and correcting possible upgrade problems.
Also, I don't know whether the Deluge will persist the Windows 10 upgrade, I haven't seen any Windows 10 certification of the Deluge. But Deluge is relatively uncomplex at OS level (no strong OS or HW dependencies) so I don't belive in any serious problems regarding Deluge when upgrading to Windows 10.
Exciting, isn't? I belive in a seamless upgrade of the OS anyhow regarding the Deluge function due to its general structure and implementation.
Re: Libtorrent 1.0.4 compiled - for those with speed issues
So i've been watching deluge for awhile and I noticed something. Trackers that show the seeds/peers with the 1 (1) with both the number and the available in the brackets there are no issues seeding. It is only trackers that don't show the () that have the seeding issues.
IPTorrents works good because they have the () but another private tracker without can't seed at all.
IPTorrents works good because they have the () but another private tracker without can't seed at all.
Libtorrent 1.0.6
Changelog from libtorrent site:
* fixed uTP vulnerability
* make utf8 conversions more lenient
* fix loading of piece priorities from resume data
* improved seed-mode handling (seed-mode will now automatically be left when performing operations implying it's not a seed)
* fixed issue with file priorities and override resume data
* fix request queue size performance issue
* slightly improve UDP tracker performance
* fix http scrapes
* add missing port mapping functions to python binding
* fix bound-checking issue in bdecoder
* expose missing dht_settings fields to python
* add function to query the DHT settings
* fix bug in 'dont_count_slow_torrents' feature, which would start too many torrents
http://shryp.ashendust.com/deluge/libto ... .6.pyd.zip
* fixed uTP vulnerability
* make utf8 conversions more lenient
* fix loading of piece priorities from resume data
* improved seed-mode handling (seed-mode will now automatically be left when performing operations implying it's not a seed)
* fixed issue with file priorities and override resume data
* fix request queue size performance issue
* slightly improve UDP tracker performance
* fix http scrapes
* add missing port mapping functions to python binding
* fix bound-checking issue in bdecoder
* expose missing dht_settings fields to python
* add function to query the DHT settings
* fix bug in 'dont_count_slow_torrents' feature, which would start too many torrents
http://shryp.ashendust.com/deluge/libto ... .6.pyd.zip
Re: Libtorrent 1.0.4 compiled - for those with speed issues
Installed on my 2012 R2 box and lets see what happens.
Re: Libtorrent 1.0.4 compiled - for those with speed issues
Well this is new. The seed/peers are showing up with the () numbers for both my trackers before I use this didn't happen before.
Re: Libtorrent 1.0.6
Shryp wrote:Changelog from libtorrent site:
* fixed uTP vulnerability
* make utf8 conversions more lenient
* fix loading of piece priorities from resume data
* improved seed-mode handling (seed-mode will now automatically be left when performing operations implying it's not a seed)
* fixed issue with file priorities and override resume data
* fix request queue size performance issue
* slightly improve UDP tracker performance
* fix http scrapes
* add missing port mapping functions to python binding
* fix bound-checking issue in bdecoder
* expose missing dht_settings fields to python
* add function to query the DHT settings
* fix bug in 'dont_count_slow_torrents' feature, which would start too many torrents
http://shryp.ashendust.com/deluge/libto ... .6.pyd.zip
Hey Shryp,
Since installing this I have been getting deluged.exe crashes, are you seeing this too? Server 2012 R2
Re: Libtorrent 1.0.6
No, working fine for me on Windows 7.JayMan wrote: Hey Shryp,
Since installing this I have been getting deluged.exe crashes, are you seeing this too? Server 2012 R2