Error state on unregistered torrents not set correctly (tracker_backoff and autodl)

[niayh]

Hey there,

I've been trying to get Deluge 1.3.12 + Libtorrent 1.0.7 to work in conjunction with an autodl filter and a watch folder from a private tracker. I've been running around in circles trying to figure out why if when a torrent is added before the tracker has registered it, the client will wait a full 30 minutes until the next announce to refresh.

I found the tracker_backoff setting and was hopeful that this would fix my problem; however, no amount of changing this value would do anything to solve my problem with unregistered torrents. The torrent gets added and if the torrent is not registered, the announce interval is set to 30 minutes.

I started wondering, perhaps a failure isn't being reported properly somehow. Sure enough, I altered the tracker URL to something bogus and suddenly the retry intervals were set according to the tracker_backoff setting ( 7, 15, 27, 45, 95, 127, 165 seconds, etc). This leads me to believe that somehow the error status on unregistered torrents isn't being recognized properly, even though the Announce Status reads: Error: (Unregistered Torrent) and as a result of being able to connect to the tracker, libtorrent decides to announce as if all is normal and set the next refresh to 30 minutes.

This may be a tracker specific issue; however, it's worth noting that the error state is read correctly when using AutoDL with rtorrent.

[niayh]

Upon a bit more investigation, this appears to be an issue localized to a single tracker. Is there any way to refine the definition of failure in this circumstance?

[niayh]

Upon a bit more investigation, this appears to be an issue localized to a single tracker. Is there any way to refine the definition of failure in this circumstance?

[arvidn]

I would be interested in seeing an example response from this tracker, if you have one (ideally as a wireshark capture).

I would expect that if the tracker responds with a proper "failure reason" key, libtorrent would treat it as a failure (as opposed to a "warning message" key). However, whether libtorrent treats it as a fatal error or not probably would depend on some other property of the response. i.e. tracker failures aren't necessarily fatal, but could be transient. libtorrent does not implement http://bittorrent.org/beps/bep_0031.html

However, passing a very large announce interval might work.

[arvidn]

I would be interested in seeing an example response from this tracker, if you have one (ideally as a wireshark capture).

I would expect that if the tracker responds with a proper "failure reason" key, libtorrent would treat it as a failure (as opposed to a "warning message" key). However, whether libtorrent treats it as a fatal error or not probably would depend on some other property of the response. i.e. tracker failures aren't necessarily fatal, but could be transient. libtorrent does not implement http://bittorrent.org/beps/bep_0031.html

However, passing a very large announce interval might work.

[niayh]

Thanks for the response. I got you an example output log from deluge when the error occurs and I also grabbed 2 different sets of packets that I received in response from trying to add an unregistered torrent to the tracker.

https://www.dropbox.com/s/440db7d65ct64v6/unregistered.log?dl=0

Wireshark versions of responses:
https://www.dropbox.com/s/5oudezfx4cl0omz/unregistered.pcap?dl=0

Do you mean increasing the autodl delay? I'm reluctant to do so because even with as large of a delay as 45 seconds, I still miss announces from time to time. Conversely, torrents that announce within 15 seconds, I would miss all or part of the main swarm.

[niayh]

Thanks for the response. I got you an example output log from deluge when the error occurs and I also grabbed 2 different sets of packets that I received in response from trying to add an unregistered torrent to the tracker.

https://www.dropbox.com/s/440db7d65ct64v6/unregistered.log?dl=0

Wireshark versions of responses:
https://www.dropbox.com/s/5oudezfx4cl0omz/unregistered.pcap?dl=0

Do you mean increasing the autodl delay? I'm reluctant to do so because even with as large of a delay as 45 seconds, I still miss announces from time to time. Conversely, torrents that announce within 15 seconds, I would miss all or part of the main swarm.

[niayh]

Set up a few more autodl tests on other trackers and turns out another one of my trackers performs in the same manner to the one in the test, so that makes 2 trackers now.

[niayh]

Set up a few more autodl tests on other trackers and turns out another one of my trackers performs in the same manner to the one in the test, so that makes 2 trackers now.

[arvidn]

by "announce interval" I meant the key the tracker is supposed to return in the tracker response. If the tracker would do that, libtorrent would not try again until that many seconds.

I notice the tracker response in your capture literally just contain a "failure reason" key/value. This is a bit odd and not really how I would read the specification. I would think that it's reasonable to try again 30 minutes later in this case. Is that what you see libtorrent do?

I'm curious, how do other clients behave? Do they simply consider the response invalid and never talk to the tracker again? (for that torrent). If so, I wonder if the reason not to talk to it again is that the response is too broken, or because the "failure reason" message exist in the response.

[arvidn]

by "announce interval" I meant the key the tracker is supposed to return in the tracker response. If the tracker would do that, libtorrent would not try again until that many seconds.

I notice the tracker response in your capture literally just contain a "failure reason" key/value. This is a bit odd and not really how I would read the specification. I would think that it's reasonable to try again 30 minutes later in this case. Is that what you see libtorrent do?

I'm curious, how do other clients behave? Do they simply consider the response invalid and never talk to the tracker again? (for that torrent). If so, I wonder if the reason not to talk to it again is that the response is too broken, or because the "failure reason" message exist in the response.

[niayh]

Ahh, I see now, what you mean by announce interval.

Libtorrent is indeed behaving how you think: resetting to 30 minutes

When I use rtorrent the behavior is what I am hoping to see in deluge: rtorrent lists the torrent as if it is in error mode and keeps trying to sync with the tracker in small intervals until it manages to do so. At this point, it backs of to regular intervals.

[niayh]

Ahh, I see now, what you mean by announce interval.

Libtorrent is indeed behaving how you think: resetting to 30 minutes

When I use rtorrent the behavior is what I am hoping to see in deluge: rtorrent lists the torrent as if it is in error mode and keeps trying to sync with the tracker in small intervals until it manages to do so. At this point, it backs of to regular intervals.

[arvidn]

please re-open if there's anything actionable here

[arvidn]

please re-open if there's anything actionable here

[slaughtermouse]

I'm also seeing this as well with libtorrent: 1.0.7.0 and deluge 1.3.12, where rtorrent will correctly retry in smaller intervals deluge sets the retry to 30 minutes which means you completely miss the swarm when it eventually announces.

Is it not possible to treat value received per the above captures as an error state that will trigger tracker_backoff ?

[slaughtermouse]

I'm also seeing this as well with libtorrent: 1.0.7.0 and deluge 1.3.12, where rtorrent will correctly retry in smaller intervals deluge sets the retry to 30 minutes which means you completely miss the swarm when it eventually announces.

Is it not possible to treat value received per the above captures as an error state that will trigger tracker_backoff ?

[arvidn]

my understanding of what you're asking for is the opposite of back-off.. if a tracker fails, you want to try it again more_frequently than you would normally contact it. The obvious risk is that a tracker getting overwhelmed with traffic will receive increasing amount of traffic as clients retry frequently.

Is there something unique about these tracker failures that indicate that the torrent will be available soon?

Do you have an idea of a reasonable behavior to improve the situation?

[arvidn]

my understanding of what you're asking for is the opposite of back-off.. if a tracker fails, you want to try it again more_frequently than you would normally contact it. The obvious risk is that a tracker getting overwhelmed with traffic will receive increasing amount of traffic as clients retry frequently.

Is there something unique about these tracker failures that indicate that the torrent will be available soon?

Do you have an idea of a reasonable behavior to improve the situation?

[slaughtermouse]

Yeah, not 100% sure on terminology, I'm just expanding on what the OP posted about.

I guess the unique aspect comes from using something like autodl-irssi which automatically downloads a torrent file that has been announced by a particular trackers bot.

What happens is the download of the torrent file happens so quick, then added to deluge, before the tracker seems to be aware of it so it ends up sitting in an unregistered state until the torrent client announces again. So in a sense the torrent file is definitely valid, just happens too fast.

With autodl-irssi you can set a delay to avoid this but as described above its a fine line between setting the delay for too long or too short that you end up missing the swam.

The way rtorrent handles the exact same tracker is it retries within seconds of the torrent being added in the "unregistered torrent" state, rather than waiting 30 minutes like Deluge

[slaughtermouse]

Yeah, not 100% sure on terminology, I'm just expanding on what the OP posted about.

I guess the unique aspect comes from using something like autodl-irssi which automatically downloads a torrent file that has been announced by a particular trackers bot.

What happens is the download of the torrent file happens so quick, then added to deluge, before the tracker seems to be aware of it so it ends up sitting in an unregistered state until the torrent client announces again. So in a sense the torrent file is definitely valid, just happens too fast.

With autodl-irssi you can set a delay to avoid this but as described above its a fine line between setting the delay for too long or too short that you end up missing the swam.

The way rtorrent handles the exact same tracker is it retries within seconds of the torrent being added in the "unregistered torrent" state, rather than waiting 30 minutes like Deluge

[arvidn]

would it be reasonable to perhaps have an exception where, if the torrent was added recently enough, the retry timeout is shorter.

[arvidn]

would it be reasonable to perhaps have an exception where, if the torrent was added recently enough, the retry timeout is shorter.

[niayh]

This sounds reasonable to me -- even a window as small as 5-10 minutes could be sufficient to avoid the described behavior

[niayh]

This sounds reasonable to me -- even a window as small as 5-10 minutes could be sufficient to avoid the described behavior

[slaughtermouse]

I think 5 to 10 minutes is still too long though, it needs to be in seconds
as on competitive trackers 5 to 10 minutes is long enough for 90% of people
to have completed the download which would result in a lower than
acceptable ratio

Can it be a ramping sort of behaviour e.g. Try in 5 seconds then (if failed)10
seconds then 15 seconds and so on?

Obviously the goal is to not smash the tracker so I'm not sure how rtorrent
does it

On Wednesday, February 10, 2016, niayh notifications@github.com wrote:

This sounds reasonable to me -- even a window as small as 5-10 minutes
could be sufficient to avoid the described behavior

—
Reply to this email directly or view it on GitHub
#315 (comment).

[slaughtermouse]

I think 5 to 10 minutes is still too long though, it needs to be in seconds
as on competitive trackers 5 to 10 minutes is long enough for 90% of people
to have completed the download which would result in a lower than
acceptable ratio

Can it be a ramping sort of behaviour e.g. Try in 5 seconds then (if failed)10
seconds then 15 seconds and so on?

Obviously the goal is to not smash the tracker so I'm not sure how rtorrent
does it

On Wednesday, February 10, 2016, niayh notifications@github.com wrote:

This sounds reasonable to me -- even a window as small as 5-10 minutes
could be sufficient to avoid the described behavior

—
Reply to this email directly or view it on GitHub
#315 (comment).

[arvidn]

on the other hand, if the tracker admins incentivize hammering the tracker, and publish the torrent before their tracker whitelist it, perhaps they want people to hammer their tracker.

[arvidn]

on the other hand, if the tracker admins incentivize hammering the tracker, and publish the torrent before their tracker whitelist it, perhaps they want people to hammer their tracker.

[slaughtermouse]

I'm not really sure what to say other than rtorrent handles it fine

[slaughtermouse]

I'm not really sure what to say other than rtorrent handles it fine

[ssiloti]

Personally I'm opposed to making any accommodations for this. The trackers here are broken in at least two ways:

1. They publish torrents before they have been authorized.
2. They enforce a minimum ratio. This is broken because pure ratio is a zero sum so you end up with the degenerate behavior of people jumping on any and all torrents the instant they go up in a desperate bid to find someone to upload to.

These issues should be taken up with the tracker admins, not hacked around in libtorrent.

[ssiloti]

Personally I'm opposed to making any accommodations for this. The trackers here are broken in at least two ways:

1. They publish torrents before they have been authorized.
2. They enforce a minimum ratio. This is broken because pure ratio is a zero sum so you end up with the degenerate behavior of people jumping on any and all torrents the instant they go up in a desperate bid to find someone to upload to.

These issues should be taken up with the tracker admins, not hacked around in libtorrent.

[slaughtermouse]

Probably easier to just stick with adding a delay to the download script.

As you say, it's clearly a tracker issue.

On Wed, Feb 10, 2016 at 4:33 PM, Steven Siloti notifications@github.com
wrote:

Personally I'm opposed to making any accommodations for this. The trackers
here are broken in at least two ways:

1. They publish torrents before they have been authorized.
2. They enforce a minimum ratio. This is broken because pure ratio is
   a zero sum so you end up with the degenerate behavior of people jumping on
   any and all torrents the instant they go up in a desperate bid to find
   someone to upload to.

These issues should be taken up with the tracker admins, not hacked around
in libtorrent.

—
Reply to this email directly or view it on GitHub
#315 (comment).

[slaughtermouse]

Probably easier to just stick with adding a delay to the download script.

As you say, it's clearly a tracker issue.

On Wed, Feb 10, 2016 at 4:33 PM, Steven Siloti notifications@github.com
wrote:

Personally I'm opposed to making any accommodations for this. The trackers
here are broken in at least two ways:

1. They publish torrents before they have been authorized.
2. They enforce a minimum ratio. This is broken because pure ratio is
   a zero sum so you end up with the degenerate behavior of people jumping on
   any and all torrents the instant they go up in a desperate bid to find
   someone to upload to.

These issues should be taken up with the tracker admins, not hacked around
in libtorrent.

—
Reply to this email directly or view it on GitHub
#315 (comment).

[arvidn]

your download script could hammer the tracker until receiving a legitimate response, and then add the torrent. :)

[arvidn]

your download script could hammer the tracker until receiving a legitimate response, and then add the torrent. :)

[slaughtermouse]

lol, what it does is when it receives the announce from the irc bot it
waits X seconds before downloading the torrent file.. that way nothing gets
hammered

On Wed, Feb 10, 2016 at 5:26 PM, Arvid Norberg notifications@github.com
wrote:

your download script could hammer the tracker until receiving a legitimate
response, and then add the torrent. :)

—
Reply to this email directly or view it on GitHub
#315 (comment).

[slaughtermouse]

lol, what it does is when it receives the announce from the irc bot it
waits X seconds before downloading the torrent file.. that way nothing gets
hammered

On Wed, Feb 10, 2016 at 5:26 PM, Arvid Norberg notifications@github.com
wrote:

your download script could hammer the tracker until receiving a legitimate
response, and then add the torrent. :)

—
Reply to this email directly or view it on GitHub
#315 (comment).

[slaughtermouse]

Actually, now that I've had more time to process this wouldn't you just be adding another condition based on the OP's scenario that would use the tracker_backoff function?

Or am I just being ignorant here?

[slaughtermouse]

Actually, now that I've had more time to process this wouldn't you just be adding another condition based on the OP's scenario that would use the tracker_backoff function?

Or am I just being ignorant here?

[arvidn]

trackers are re-tried with an exponential back-off if we fail to connect to them (and possibly if they return some fatal error at a layer below the bittorrent-tracker protocol, like an HTTP 503).

In this case, we are successful in connecting and talking to the tracker at the bittorrent-level protocol. This means we can be certain the tracker is there and expects to be used as a bittorrent tracker.

At that point, the tracker has a fair amount of control over the client's behavior (for good reasons). If the tracker wants the client to never connect back again, or try again in a few seconds, it can ask the client to do so. In this case, iirc, it returns a somewhat strange and ambiguous response.

(also, currently there's actually a sanity check in libtorrent clamping re-announce intervals to 5 minutes, maybe the tracker should be trusted more than that).

My point is that, yes, it's possible to add a case where this is considered a failure at a lower level, and the tracker is retried. But this is just one tracker. The next tracker will presumably have a slightly different response in this situation. I imagine it would make a lot more sense to tighten up the specification and stay more true to it, than to sprinkle special cases around. The risk is that, at some point you run into a case where the special case causes the opposite effect than you want, and the user/admin is surprised of the behavior because it's undocumented.

[arvidn]

trackers are re-tried with an exponential back-off if we fail to connect to them (and possibly if they return some fatal error at a layer below the bittorrent-tracker protocol, like an HTTP 503).

In this case, we are successful in connecting and talking to the tracker at the bittorrent-level protocol. This means we can be certain the tracker is there and expects to be used as a bittorrent tracker.

At that point, the tracker has a fair amount of control over the client's behavior (for good reasons). If the tracker wants the client to never connect back again, or try again in a few seconds, it can ask the client to do so. In this case, iirc, it returns a somewhat strange and ambiguous response.

(also, currently there's actually a sanity check in libtorrent clamping re-announce intervals to 5 minutes, maybe the tracker should be trusted more than that).

My point is that, yes, it's possible to add a case where this is considered a failure at a lower level, and the tracker is retried. But this is just one tracker. The next tracker will presumably have a slightly different response in this situation. I imagine it would make a lot more sense to tighten up the specification and stay more true to it, than to sprinkle special cases around. The risk is that, at some point you run into a case where the special case causes the opposite effect than you want, and the user/admin is surprised of the behavior because it's undocumented.

[slaughtermouse]

Fair call.

Thanks for the explanation, makes more sense now!

On Thu, Feb 11, 2016 at 4:12 AM, Arvid Norberg notifications@github.com
wrote:

trackers are re-tried with an exponential back-off if we fail to connect
to them (and possibly if they return some fatal error at a layer below the
bittorrent-tracker protocol, like an HTTP 503).

In this case, we are successful in connecting and talking to the tracker
at the bittorrent-level protocol. This means we can be certain the tracker
is there and expects to be used as a bittorrent tracker.

At that point, the tracker has a fair amount of control over the client's
behavior (for good reasons). If the tracker wants the client to never
connect back again, or try again in a few seconds, it can ask the client to
do so. In this case, iirc, it returns a somewhat strange and ambiguous
response.

(also, currently there's actually a sanity check in libtorrent clamping
re-announce intervals to 5 minutes, maybe the tracker should be trusted
more than that).

My point is that, yes, it's possible to add a case where this is
considered a failure at a lower level, and the tracker is retried. But this
is just one tracker. The next tracker will presumably have a slightly
different response in this situation. I imagine it would make a lot more
sense to tighten up the specification and stay more true to it, than to
sprinkle special cases around. The risk is that, at some point you run into
a case where the special case causes the opposite effect that you want, and
the user/admin is surprised of the behavior because it's undocumented.

—
Reply to this email directly or view it on GitHub
#315 (comment).

[slaughtermouse]

Fair call.

Thanks for the explanation, makes more sense now!

On Thu, Feb 11, 2016 at 4:12 AM, Arvid Norberg notifications@github.com
wrote:

trackers are re-tried with an exponential back-off if we fail to connect
to them (and possibly if they return some fatal error at a layer below the
bittorrent-tracker protocol, like an HTTP 503).

In this case, we are successful in connecting and talking to the tracker
at the bittorrent-level protocol. This means we can be certain the tracker
is there and expects to be used as a bittorrent tracker.

At that point, the tracker has a fair amount of control over the client's
behavior (for good reasons). If the tracker wants the client to never
connect back again, or try again in a few seconds, it can ask the client to
do so. In this case, iirc, it returns a somewhat strange and ambiguous
response.

(also, currently there's actually a sanity check in libtorrent clamping
re-announce intervals to 5 minutes, maybe the tracker should be trusted
more than that).

My point is that, yes, it's possible to add a case where this is
considered a failure at a lower level, and the tracker is retried. But this
is just one tracker. The next tracker will presumably have a slightly
different response in this situation. I imagine it would make a lot more
sense to tighten up the specification and stay more true to it, than to
sprinkle special cases around. The risk is that, at some point you run into
a case where the special case causes the opposite effect that you want, and
the user/admin is surprised of the behavior because it's undocumented.

—
Reply to this email directly or view it on GitHub
#315 (comment).

[jmo4114979]

Hi. I had the same problem. I found the following solution and it works.
http://wiki.bytesized-hosting.com/wiki/index.php/Autodl-irssi
It is the upload-delay-secs parameter. I tried 27 as stated but it didn't work. I the tried as 60 and it worked. I have not fine tuned to find the lowest number of seconds. This parameter can be set by tracker in the autodl.cfg file, and there is a global Delay parameter on the Filter General tab. I set 60 on both. Thanks for identifying this problem, I have been searching for days for a solution. Jack.

[jmo4114979]

Hi. I had the same problem. I found the following solution and it works.
http://wiki.bytesized-hosting.com/wiki/index.php/Autodl-irssi
It is the upload-delay-secs parameter. I tried 27 as stated but it didn't work. I the tried as 60 and it worked. I have not fine tuned to find the lowest number of seconds. This parameter can be set by tracker in the autodl.cfg file, and there is a global Delay parameter on the Filter General tab. I set 60 on both. Thanks for identifying this problem, I have been searching for days for a solution. Jack.

[jmo4114979]

Oops I should have said I am using the rutorrent gui for the autodl-irssi configuration and it now works for both rtorrent and deluge so I set the global Delay parameter on rutorrent and I changed the ipt section on the deluge autodl.cfg for the tracker modification.

[jmo4114979]

Oops I should have said I am using the rutorrent gui for the autodl-irssi configuration and it now works for both rtorrent and deluge so I set the global Delay parameter on rutorrent and I changed the ipt section on the deluge autodl.cfg for the tracker modification.

[jmo4114979]

Let me try one more time. I guess the autodl.cfg is for the audodl-irssi. On the rutorrent autodl-irssi Filter General tab there is a Delay at the global level and on the Trackers tracker tab there is a Delay at that tracker level.

[jmo4114979]

Let me try one more time. I guess the autodl.cfg is for the audodl-irssi. On the rutorrent autodl-irssi Filter General tab there is a Delay at the global level and on the Trackers tracker tab there is a Delay at that tracker level.

[slaughtermouse]

Yeah, the delay functionality is useful.

The only problem I have setting a delay is there's a chance you might miss
the initial swarm. Unfortunately the tracker in question will announce
within a few seconds or more than a minute so there's quite a variance
there.

In the end I obtained and modified a script which makes use of the Execute
plugin for Deluge and update-tracker.py command from here
https://github.com/s0undt3ch/Deluge/blob/master/deluge/ui/console/commands/update-tracker.py

It loops through looking for the word unregistered and will initiate an
update-tracker command via deluge-console till it gets an Announce OK.

It's not ideal but it gets around the variable announce

On Wed, Feb 24, 2016 at 8:17 AM, jmo4114979 notifications@github.com
wrote:

Let me try one more time. I guess the autodl.cfg is for the audodl-irssi.
On the rutorrent autodl-irssi Filter General tab there is a Delay at the
global level and on the Trackers tracker tab there is a Delay at that
tracker level.

—
Reply to this email directly or view it on GitHub
#315 (comment).

[slaughtermouse]

Yeah, the delay functionality is useful.

The only problem I have setting a delay is there's a chance you might miss
the initial swarm. Unfortunately the tracker in question will announce
within a few seconds or more than a minute so there's quite a variance
there.

In the end I obtained and modified a script which makes use of the Execute
plugin for Deluge and update-tracker.py command from here
https://github.com/s0undt3ch/Deluge/blob/master/deluge/ui/console/commands/update-tracker.py

It loops through looking for the word unregistered and will initiate an
update-tracker command via deluge-console till it gets an Announce OK.

It's not ideal but it gets around the variable announce

On Wed, Feb 24, 2016 at 8:17 AM, jmo4114979 notifications@github.com
wrote:

Let me try one more time. I guess the autodl.cfg is for the audodl-irssi.
On the rutorrent autodl-irssi Filter General tab there is a Delay at the
global level and on the Trackers tracker tab there is a Delay at that
tracker level.

—
Reply to this email directly or view it on GitHub
#315 (comment).

[arvidn]

another interesting approach would be to remember the peers you typically see early on in swarms on a specific tracker, and optimistically just add those to the swarm. you may be lucky and hit the original seed even before the tracker gets around to whitelisting

[arvidn]

another interesting approach would be to remember the peers you typically see early on in swarms on a specific tracker, and optimistically just add those to the swarm. you may be lucky and hit the original seed even before the tracker gets around to whitelisting

[TacoDelPaco]

@slaughtermouse could you... post the script you 'obtained'?

Cough... thanks.

[TacoDelPaco]

@slaughtermouse could you... post the script you 'obtained'?

Cough... thanks.

[slaughtermouse]

#!/bin/bash
torrentid=$1
torrentname=$2
torrentpath=$3

x=1
while [ $x -le 45 ]
do
sleep 2
echo "Running $x times" >> script.log
echo "TorrentID: $torrentid" >> script.log
line=$(/usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>; info" $1 | grep "Tracker status")
echo $line >> script.log
case "$line" in
*unregistered*|*Sent*)
eval /usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>\; update-tracker '$torrentid'";;
*)
echo "Found working torrent: $torrentname $torrentpath $torrentid" >> script.log
exit 1;;
esac
x=$(( $x + 1 ))
done

Save it to a file of your choice, use the Execute plugin in deluge. You'll need to modify the port, user pass to suit

It's crude, some of the things in there are superfluous, but does the job

[slaughtermouse]

#!/bin/bash
torrentid=$1
torrentname=$2
torrentpath=$3

x=1
while [ $x -le 45 ]
do
sleep 2
echo "Running $x times" >> script.log
echo "TorrentID: $torrentid" >> script.log
line=$(/usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>; info" $1 | grep "Tracker status")
echo $line >> script.log
case "$line" in
*unregistered*|*Sent*)
eval /usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>\; update-tracker '$torrentid'";;
*)
echo "Found working torrent: $torrentname $torrentpath $torrentid" >> script.log
exit 1;;
esac
x=$(( $x + 1 ))
done

Save it to a file of your choice, use the Execute plugin in deluge. You'll need to modify the port, user pass to suit

It's crude, some of the things in there are superfluous, but does the job

[slaughtermouse]

Yes, you have to restart deluge after you've enabled execute and added the
script.. as I've chmod +x'd my script I just call it as /home/user/script

The port refers to the port your deluge instance is listening on, default
is 20000 I think?

On Fri, Jun 10, 2016 at 2:21 PM, plasticspoonn notifications@github.com
wrote:

@slaughtermouse https://github.com/slaughtermouse , I am pretty new to
unix and my seedbox, I'm trying to implement your script using the path and
script name monukoshy provided.

This is the correct command and path for execute? sh
/home/user/.config/deluge/workaround.sh

I am also not sure what port I should be putting into the script.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#315 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AOQZ3efQCphpwDx5_A_h-cxwaj5Zi9L_ks5qKMopgaJpZM4GvytU
.

[slaughtermouse]

Yes, you have to restart deluge after you've enabled execute and added the
script.. as I've chmod +x'd my script I just call it as /home/user/script

The port refers to the port your deluge instance is listening on, default
is 20000 I think?

On Fri, Jun 10, 2016 at 2:21 PM, plasticspoonn notifications@github.com
wrote:

@slaughtermouse https://github.com/slaughtermouse , I am pretty new to
unix and my seedbox, I'm trying to implement your script using the path and
script name monukoshy provided.

This is the correct command and path for execute? sh
/home/user/.config/deluge/workaround.sh

I am also not sure what port I should be putting into the script.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#315 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AOQZ3efQCphpwDx5_A_h-cxwaj5Zi9L_ks5qKMopgaJpZM4GvytU
.

[plasticspoonn]

@slaughtermouse, Still getting same error, if I manually go into that folder and do a sh workaround.sh I can get it to spit out the script.log. I think deluge cannot find the path. This is the path of the file for me

/media/sdj1//.config/deluge/workaround.sh

I have tried that and the path /home/user/.config/deluge/workaround.sh provided.

As for the port, is it the server interface port? not the daemon port I assume.

[plasticspoonn]

@slaughtermouse, Still getting same error, if I manually go into that folder and do a sh workaround.sh I can get it to spit out the script.log. I think deluge cannot find the path. This is the path of the file for me

/media/sdj1//.config/deluge/workaround.sh

I have tried that and the path /home/user/.config/deluge/workaround.sh provided.

As for the port, is it the server interface port? not the daemon port I assume.

[slaughtermouse]

Daemon port yes

Not sure, put the script in /media/sdj1 instead and/or try without sh

On Friday, 10 June 2016, plasticspoonn notifications@github.com wrote:

@slaughtermouse https://github.com/slaughtermouse, Still getting same
error, if I manually go into that folder and do a sh workaround.sh I can
get it to spit out the script.log. I think deluge cannot find the path.
This is the path of the file for me

/media/sdj1//.config/deluge/workaround.sh

I have tried that and the path /home/user/.config/deluge/workaround.sh
provided.

As for the port, is it the server interface port? not the daemon port I
assume.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#315 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AOQZ3bCbJVHeitWq9FiQYho36HmTOC2rks5qKNfJgaJpZM4GvytU
.

[slaughtermouse]

Daemon port yes

Not sure, put the script in /media/sdj1 instead and/or try without sh

On Friday, 10 June 2016, plasticspoonn notifications@github.com wrote:

@slaughtermouse https://github.com/slaughtermouse, Still getting same
error, if I manually go into that folder and do a sh workaround.sh I can
get it to spit out the script.log. I think deluge cannot find the path.
This is the path of the file for me

/media/sdj1//.config/deluge/workaround.sh

I have tried that and the path /home/user/.config/deluge/workaround.sh
provided.

As for the port, is it the server interface port? not the daemon port I
assume.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#315 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AOQZ3bCbJVHeitWq9FiQYho36HmTOC2rks5qKNfJgaJpZM4GvytU
.

[MutatedHero]

I've been seeing this issue quite often at multiple trackers and missing the initial swarm in todays competitive enviroment is a hard hit on ones ratio.
@slaughtermouse, Your script looks like the only solution currently but after trying to convert it to batch for Windows and failing I thought I'd hear with you if that is something you've already done?

[MutatedHero]

I've been seeing this issue quite often at multiple trackers and missing the initial swarm in todays competitive enviroment is a hard hit on ones ratio.
@slaughtermouse, Your script looks like the only solution currently but after trying to convert it to batch for Windows and failing I thought I'd hear with you if that is something you've already done?

[slaughtermouse]

@MutatedHero, it's not something I've tried on Windows sorry.

But when I have some time I'll see if I can whip something up

[slaughtermouse]

@MutatedHero, it's not something I've tried on Windows sorry.

But when I have some time I'll see if I can whip something up

[fluxcapacitus]

Heya @slaughtermouse I set up your script by inserting my own info, but this is the error I get when I try to run it through putty on my seedbox.

/.config/deluge/delaything.sh: line 5: $'\r': command not found
/.config/deluge/delaything.sh: line 14: syntax error near unexpected token `$'in\r''
'/.config/deluge/delaything.sh: line 14: `case "$line" in

Any idea what that's all about? I have very little programming and linux skills so I can follow along with what the script is basically trying to do but any syntax details go right over my head.

No errors or any other indicators in deluge and no log is created. I'm on latest versions of everything.
Thanks

[fluxcapacitus]

Heya @slaughtermouse I set up your script by inserting my own info, but this is the error I get when I try to run it through putty on my seedbox.

/.config/deluge/delaything.sh: line 5: $'\r': command not found
/.config/deluge/delaything.sh: line 14: syntax error near unexpected token `$'in\r''
'/.config/deluge/delaything.sh: line 14: `case "$line" in

Any idea what that's all about? I have very little programming and linux skills so I can follow along with what the script is basically trying to do but any syntax details go right over my head.

No errors or any other indicators in deluge and no log is created. I'm on latest versions of everything.
Thanks

[slaughtermouse]

@fluxcapacitus try editing in nano and remove the \r's from the end of each line in the script

…

________________________________ From: fluxcapacitus <notifications@github.com> Sent: Tuesday, 17 January 2017 3:24:46 p.m. To: arvidn/libtorrent Cc: James Leonard; Mention Subject: Re: [arvidn/libtorrent] Error state on unregistered torrents not set correctly (tracker_backoff and autodl) (#315) Heya @slaughtermouse<https://github.com/slaughtermouse> I set up your script by inserting my own info, but this is the error I get when I try to run it through putty on my seedbox. /.config/deluge/delaything.sh: line 5: $'\r': command not found /.config/deluge/delaything.sh: line 14: syntax error near unexpected token `$'in\r'' '/.config/deluge/delaything.sh: line 14: `case "$line" in Any idea what that's all about? I have very little programming and linux skills so I can follow along with what the script is basically trying to do but any syntax details go right over my head. No errors or any other indicators in deluge and no log is created. I'm on latest versions of everything. Thanks - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#315 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AOQZ3Um6bq_wMBzjjvJ8b8imYNDwuEm3ks5rTCZugaJpZM4GvytU>.

[slaughtermouse]

@fluxcapacitus try editing in nano and remove the \r's from the end of each line in the script

…

________________________________ From: fluxcapacitus <notifications@github.com> Sent: Tuesday, 17 January 2017 3:24:46 p.m. To: arvidn/libtorrent Cc: James Leonard; Mention Subject: Re: [arvidn/libtorrent] Error state on unregistered torrents not set correctly (tracker_backoff and autodl) (#315) Heya @slaughtermouse<https://github.com/slaughtermouse> I set up your script by inserting my own info, but this is the error I get when I try to run it through putty on my seedbox. /.config/deluge/delaything.sh: line 5: $'\r': command not found /.config/deluge/delaything.sh: line 14: syntax error near unexpected token `$'in\r'' '/.config/deluge/delaything.sh: line 14: `case "$line" in Any idea what that's all about? I have very little programming and linux skills so I can follow along with what the script is basically trying to do but any syntax details go right over my head. No errors or any other indicators in deluge and no log is created. I'm on latest versions of everything. Thanks - You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#315 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AOQZ3Um6bq_wMBzjjvJ8b8imYNDwuEm3ks5rTCZugaJpZM4GvytU>.

[fluxcapacitus]

@slaughtermouse I'm not seeing any of those in the script, the only \ I even see is at the end of the second password placeholder but deleting that didn't stop the error.

torrentid=$1
torrentname=$2
torrentpath=$3

x=1
while [ $x -le 45 ]
do
sleep 2
echo "Running $x times" >> script.log
echo "TorrentID: $torrentid" >> script.log
line=$(/usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>; info" $1 | grep "Tracker status")
echo $line >> script.log
case "$line" in
*unregistered*|*Sent*)
eval /usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>\; update-tracker '$torrentid'";;
*)
echo "Found working torrent: $torrentname $torrentpath $torrentid" >> script.log
exit 1;;
esac
x=$(( $x + 1 ))
done

It's an exact paste of your code snippet with the placeholders replaced with my login and port. Was I supposed to do something with the code from the page you linked? https://github.com/s0undt3ch/Deluge/blob/master/deluge/ui/console/commands/update-tracker.py

[fluxcapacitus]

@slaughtermouse I'm not seeing any of those in the script, the only \ I even see is at the end of the second password placeholder but deleting that didn't stop the error.

torrentid=$1
torrentname=$2
torrentpath=$3

x=1
while [ $x -le 45 ]
do
sleep 2
echo "Running $x times" >> script.log
echo "TorrentID: $torrentid" >> script.log
line=$(/usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>; info" $1 | grep "Tracker status")
echo $line >> script.log
case "$line" in
*unregistered*|*Sent*)
eval /usr/local/bin/deluge-console "connect 127.0.0.1:<port> <user> <pass>\; update-tracker '$torrentid'";;
*)
echo "Found working torrent: $torrentname $torrentpath $torrentid" >> script.log
exit 1;;
esac
x=$(( $x + 1 ))
done

It's an exact paste of your code snippet with the placeholders replaced with my login and port. Was I supposed to do something with the code from the page you linked? https://github.com/s0undt3ch/Deluge/blob/master/deluge/ui/console/commands/update-tracker.py

[slaughtermouse]

Try typing: which deluge-console

The location of your deluge-console might be different to mine being in /usr/local/bin/

Also, probably not required but don't forget to include #!/bin/bash at the top of the script

You need to copy update-tracker.py to the following, or relevant to your install, location: /usr/local/lib/python2.7/dist-packages/deluge-1.3.13_dev-py2.7.egg/deluge/ui/console/commands

The update-tracker.py file adds the update-tracker command to deluge-console, without it the script won't work

Failing that, here's the script (slightly updated since I originally posted it) https://drive.google.com/file/d/0B-Mod1AY73DdNTh6N1hiV25MY0E/view?usp=sharing

[slaughtermouse]

Try typing: which deluge-console

The location of your deluge-console might be different to mine being in /usr/local/bin/

Also, probably not required but don't forget to include #!/bin/bash at the top of the script

You need to copy update-tracker.py to the following, or relevant to your install, location: /usr/local/lib/python2.7/dist-packages/deluge-1.3.13_dev-py2.7.egg/deluge/ui/console/commands

The update-tracker.py file adds the update-tracker command to deluge-console, without it the script won't work

Failing that, here's the script (slightly updated since I originally posted it) https://drive.google.com/file/d/0B-Mod1AY73DdNTh6N1hiV25MY0E/view?usp=sharing

[fluxcapacitus]

The problem was no tracker-update.py and I can't add it because I don't have the permissions for that location with this seedbox provider. I wasn't really pleased with the service anyway so this is enough to get me to switch. Thanks for the help, I'll come back in a month when this term expires.

…

On January 17, 2017 1:44:18 AM MST, slaughtermouse ***@***.***> wrote: Try typing: which deluge-console The location of your deluge-console might be different to mine being in /usr/local/bin/ Also, probably not required but don't forget to include `#!/bin/bash` at the top of the script You need to copy update-tracker.py to the following, or relevant to your install, location: /usr/local/lib/python2.7/dist-packages/deluge-1.3.13_dev-py2.7.egg/deluge/ui/console/commands Failing that, here's the script slightly updated https://drive.google.com/file/d/0B-Mod1AY73DdNTh6N1hiV25MY0E/view?usp=sharing -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #315 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[fluxcapacitus]

The problem was no tracker-update.py and I can't add it because I don't have the permissions for that location with this seedbox provider. I wasn't really pleased with the service anyway so this is enough to get me to switch. Thanks for the help, I'll come back in a month when this term expires.

…

On January 17, 2017 1:44:18 AM MST, slaughtermouse ***@***.***> wrote: Try typing: which deluge-console The location of your deluge-console might be different to mine being in /usr/local/bin/ Also, probably not required but don't forget to include `#!/bin/bash` at the top of the script You need to copy update-tracker.py to the following, or relevant to your install, location: /usr/local/lib/python2.7/dist-packages/deluge-1.3.13_dev-py2.7.egg/deluge/ui/console/commands Failing that, here's the script slightly updated https://drive.google.com/file/d/0B-Mod1AY73DdNTh6N1hiV25MY0E/view?usp=sharing -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #315 (comment)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[orytek]

Script is working good for me. I initially got errors in both files until I made sure to remove tabs in .py file and and non-unix line endings in script.
Thanks slaughtermouse.

[orytek]

Script is working good for me. I initially got errors in both files until I made sure to remove tabs in .py file and and non-unix line endings in script.
Thanks slaughtermouse.

[HYQ307]

@slaughtermouse
Hi there, i have done everything right but the question is the Script just doesn't work whenever a new torrents added in watch folder with "unregistered torrents" . Any idea how to fix that?
I have copy the update-tracker.py also enabled the Excute in Deluge, just doesn't work.

[HYQ307]

@slaughtermouse
Hi there, i have done everything right but the question is the Script just doesn't work whenever a new torrents added in watch folder with "unregistered torrents" . Any idea how to fix that?
I have copy the update-tracker.py also enabled the Excute in Deluge, just doesn't work.

[slaughtermouse]

Normally you need to restart deluge as the execute plugin doesn't always work off the bat

Also I assume you've added the script to the execute plugin, selecting the "torrent added" event and the command as /home//trachk or whatever you've called the script

For good measure chmod +x trachk from the command line

[slaughtermouse]

Normally you need to restart deluge as the execute plugin doesn't always work off the bat

Also I assume you've added the script to the execute plugin, selecting the "torrent added" event and the command as /home//trachk or whatever you've called the script

For good measure chmod +x trachk from the command line

[HYQ307]

@slaughtermouse
I Do did all those. But it still does not work ? May you give a little test to see if it still works?

[HYQ307]

@slaughtermouse
I Do did all those. But it still does not work ? May you give a little test to see if it still works?

[slaughtermouse]

I have it running all the time The script runs fine when you manually run it with no arguments? Try running deluge-web without forking to daemon you might be able to see an error as to why the script isn't running when the torrent is added

…

On Fri, 5 May 2017 at 9:14 PM, HYQ307 ***@***.***> wrote: @slaughtermouse <https://github.com/slaughtermouse> I Do did all those. But it still does not work ? May you give a little test to see if it still works? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3X5hGYG1NUZstBQcqyO944tkqHYYks5r2uhmgaJpZM4GvytU> .

[slaughtermouse]

I have it running all the time The script runs fine when you manually run it with no arguments? Try running deluge-web without forking to daemon you might be able to see an error as to why the script isn't running when the torrent is added

…

On Fri, 5 May 2017 at 9:14 PM, HYQ307 ***@***.***> wrote: @slaughtermouse <https://github.com/slaughtermouse> I Do did all those. But it still does not work ? May you give a little test to see if it still works? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3X5hGYG1NUZstBQcqyO944tkqHYYks5r2uhmgaJpZM4GvytU> .

[HYQ307]

I manually run the script and get this:
"Running 1 times
TorrentID:
Tracker status: xxx: Announce OK Tracker status: xxxx: Announce OK Tracker status: chdbits$
Found working torrent:"

So i guess the script works fine. But the question is whenever a new torrent added, it just doesn't work to update the tracker. Here is what i set in Deluge Excute:
https://picload.org/image/rcpclcgl/1.png

I also reboot to make it apply. But doesn't work when an unregistered torrents added.

And how to do this "Try running deluge-web without forking to daemon you might be able to see"
You mean deluge-console like this?
https://picload.org/image/rcpclciw/1.png

@slaughtermouse

[HYQ307]

I manually run the script and get this:
"Running 1 times
TorrentID:
Tracker status: xxx: Announce OK Tracker status: xxxx: Announce OK Tracker status: chdbits$
Found working torrent:"

So i guess the script works fine. But the question is whenever a new torrent added, it just doesn't work to update the tracker. Here is what i set in Deluge Excute:
https://picload.org/image/rcpclcgl/1.png

I also reboot to make it apply. But doesn't work when an unregistered torrents added.

And how to do this "Try running deluge-web without forking to daemon you might be able to see"
You mean deluge-console like this?
https://picload.org/image/rcpclciw/1.png

@slaughtermouse

[slaughtermouse]

Not sure, all I can suggest is you don't need to add bash in front of the script, it should just be /location/to/script.sh http://dev.deluge-torrent.org/wiki/Plugins/Execute

…

On 6 May 2017 at 18:54, HYQ307 ***@***.***> wrote: I manually run the scripte and get this: "Running 1 times TorrentID: Tracker status: awesome-hd.me: Announce OK Tracker status: awesome-hd.me: Announce OK Tracker status: chdbits$ Found working torrent:" So i guess the script works fine. But the question is whenever a new torrents added, it just doesn't work to update the tracker. Here is what i set in Deluge Excute: [img]https://picload.org/image/rcpclcgl/1.png[/img] And i also reboot to make it apply. But doesn't work when an unregistered torrents added. @slaughtermouse <https://github.com/slaughtermouse> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3dj90MhBZU-IQ6aY5qOtUPtth3a5ks5r3Bk_gaJpZM4GvytU> .

[slaughtermouse]

Not sure, all I can suggest is you don't need to add bash in front of the script, it should just be /location/to/script.sh http://dev.deluge-torrent.org/wiki/Plugins/Execute

…

On 6 May 2017 at 18:54, HYQ307 ***@***.***> wrote: I manually run the scripte and get this: "Running 1 times TorrentID: Tracker status: awesome-hd.me: Announce OK Tracker status: awesome-hd.me: Announce OK Tracker status: chdbits$ Found working torrent:" So i guess the script works fine. But the question is whenever a new torrents added, it just doesn't work to update the tracker. Here is what i set in Deluge Excute: [img]https://picload.org/image/rcpclcgl/1.png[/img] And i also reboot to make it apply. But doesn't work when an unregistered torrents added. @slaughtermouse <https://github.com/slaughtermouse> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3dj90MhBZU-IQ6aY5qOtUPtth3a5ks5r3Bk_gaJpZM4GvytU> .

[HYQ307]

Yeah, this time works. Thansk for helping.

[HYQ307]

Yeah, this time works. Thansk for helping.

[slaughtermouse]

np

…

On 6 May 2017 at 21:22, HYQ307 ***@***.***> wrote: Yeah, this time works. Thansk for helping. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3cSH0bgwmKtXOJ2VTdueoLrY8tjsks5r3Du-gaJpZM4GvytU> .

[slaughtermouse]

np

…

On 6 May 2017 at 21:22, HYQ307 ***@***.***> wrote: Yeah, this time works. Thansk for helping. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3cSH0bgwmKtXOJ2VTdueoLrY8tjsks5r3Du-gaJpZM4GvytU> .

[tuga1982]

Hello I am having this error: core:154 [execute] Execute script not found or not executable

Can someone help with a walkthrough.

[tuga1982]

Hello I am having this error: core:154 [execute] Execute script not found or not executable

Can someone help with a walkthrough.

[slaughtermouse]

did you chmod +x <scriptname> the script?

…

On 17 April 2018 at 08:46, tuga1982 ***@***.***> wrote: Hello I am having this error: core:154 [execute] Execute script not found or not executable Can someone help with a walkthrough. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3cIltqgvnQIFyjq3D7EsC_Ct0zBDks5tpQM6gaJpZM4GvytU> .

[slaughtermouse]

did you chmod +x <scriptname> the script?

…

On 17 April 2018 at 08:46, tuga1982 ***@***.***> wrote: Hello I am having this error: core:154 [execute] Execute script not found or not executable Can someone help with a walkthrough. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3cIltqgvnQIFyjq3D7EsC_Ct0zBDks5tpQM6gaJpZM4GvytU> .

[tuga1982]

Hello yes I did.

[tuga1982]

Hello yes I did.

[slaughtermouse]

can you ls -l <scriptname> also ensure the location is correct and the user running deluged can actually access the location

…

On 17 April 2018 at 08:59, tuga1982 ***@***.***> wrote: Hello yes I did. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3QDdLwkJ3gXa9oqeSieLn8V_t0hBks5tpQZEgaJpZM4GvytU> .

[slaughtermouse]

can you ls -l <scriptname> also ensure the location is correct and the user running deluged can actually access the location

…

On 17 April 2018 at 08:59, tuga1982 ***@***.***> wrote: Hello yes I did. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3QDdLwkJ3gXa9oqeSieLn8V_t0hBks5tpQZEgaJpZM4GvytU> .

[tuga1982]

Hello my problem is I did not copy update-tracker.py but my problem is that the seedbox provider do not share with me this folder.

Any possible solution?

[tuga1982]

Hello my problem is I did not copy update-tracker.py but my problem is that the seedbox provider do not share with me this folder.

Any possible solution?

[tuga1982]

sh unregistered.sh
Unknown command: update-tracker

[tuga1982]

sh unregistered.sh
Unknown command: update-tracker

[slaughtermouse]

You could just ask your hosting provider to place the file in the location for you, or see if there's an alternate location deluge looks for

…

On 17 April 2018 at 21:33, tuga1982 ***@***.***> wrote: sh unregistered.sh Unknown command: update-tracker — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3fa8PJ0xsvyzwvHfC7WvdNjKXJ0Bks5tpbbggaJpZM4GvytU> .

[slaughtermouse]

You could just ask your hosting provider to place the file in the location for you, or see if there's an alternate location deluge looks for

…

On 17 April 2018 at 21:33, tuga1982 ***@***.***> wrote: sh unregistered.sh Unknown command: update-tracker — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3fa8PJ0xsvyzwvHfC7WvdNjKXJ0Bks5tpbbggaJpZM4GvytU> .

[tuga1982]

I already asked the provider he told me I should install my own version of deluge.

How to check where deluge looks for the file?

[tuga1982]

I already asked the provider he told me I should install my own version of deluge.

How to check where deluge looks for the file?

[slaughtermouse]

That would be a question for Deluge developers unfortunately

…

On 17 April 2018 at 22:17, tuga1982 ***@***.***> wrote: I already asked the provider he told me I should install my own version of deluge. How to check where deluge looks for the file? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3dpe9p4r9dV9pEVhxXn0ymQ9tmX9ks5tpcFDgaJpZM4GvytU> .

[slaughtermouse]

That would be a question for Deluge developers unfortunately

…

On 17 April 2018 at 22:17, tuga1982 ***@***.***> wrote: I already asked the provider he told me I should install my own version of deluge. How to check where deluge looks for the file? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#315 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AOQZ3dpe9p4r9dV9pEVhxXn0ymQ9tmX9ks5tpcFDgaJpZM4GvytU> .

[tuga1982]

Thanks you m8 I would try to reinstall deluge but at the end of the month my contract will be over with this seedbox provider and I will move to new one help it will work there.

[tuga1982]

Thanks you m8 I would try to reinstall deluge but at the end of the month my contract will be over with this seedbox provider and I will move to new one help it will work there.