Opened 9 years ago

Closed 7 years ago

#1796 closed Enhancement (fixed)

run script after torrent completion

Reported by: DonkeyPunch Owned by: charles
Priority: Normal Milestone: 2.00
Component: Transmission Version: 1.42
Severity: Normal Keywords: patch script torrent complete completion
Cc: mediatank, 1100101@…

Description

I really like the ability for transmissioncli to run a script after torrent completion. Can this be added to the daemon also? I'd like to be able to send myself an email when each torrent completes. Thank you.

Attachments (4)

transmission-run_cmd_after_completion_v1.diff (10.9 KB) - added by turbo 9 years ago.
First draft. Knowing how picky Charles is, I'm already calling it 'v1' :). I'm currently waiting for it to trigger on one of two torrents that are almost done - I'm not sure I put the call in the correct place. Please test and comment!
transmission-run_cmd_after_completion_v2.diff (11.5 KB) - added by turbo 9 years ago.
Missed to _save_ (set variable) after loading settings file. Also changed location on the fireExternalScript() function. Still haven't gotten it to fire (due to the variable being unset because it wasn't saved in a variable!)
transmission-run_cmd_after_completion_v3.diff (11.4 KB) - added by turbo 9 years ago.
Final version - works like a charm!
torrent_done.sh (266 bytes) - added by turbo 9 years ago.
Example shellscript - mail and move!

Download all attachments as: .zip

Change History (50)

comment:1 follow-up: Changed 9 years ago by turbo

  • Owner changed from charles to turbo

Charles: Sorry for 'stealing' this ticket (you can always take it back :) but I need it to. I'll be uploading a patch later today or tomorrow...

comment:2 Changed 9 years ago by turbo

Thought: Do we want to:

  1. Specify script per torrent (i.e. uniq scripts for torrents)?
  2. Specify one script globaly (i.e. ONE script to run on all torrents)

And I'll assume an RPC command to enable/disable script... ?

Changed 9 years ago by turbo

First draft. Knowing how picky Charles is, I'm already calling it 'v1' :). I'm currently waiting for it to trigger on one of two torrents that are almost done - I'm not sure I put the call in the correct place. Please test and comment!

comment:3 Changed 9 years ago by charles

First draft. Knowing how picky Charles is, I'm already calling it 'v1' :).

LOL!

Changed 9 years ago by turbo

Missed to _save_ (set variable) after loading settings file. Also changed location on the fireExternalScript() function. Still haven't gotten it to fire (due to the variable being unset because it wasn't saved in a variable!)

Changed 9 years ago by turbo

Final version - works like a charm!

Changed 9 years ago by turbo

Example shellscript - mail and move!

comment:4 Changed 9 years ago by turbo

  • Component changed from Daemon to libtransmission
  • Keywords patch script torrent complete completion added
  • Owner changed from turbo to charles
  • Summary changed from Transmission daemon to run script after torrent completion to [PATCH} Transmission daemon to run script after torrent completion

My job is done - reassigning it to charles...

comment:5 Changed 9 years ago by charles

  • Summary changed from [PATCH} Transmission daemon to run script after torrent completion to [PATCH] Transmission daemon to run script after torrent completion

comment:6 Changed 9 years ago by charles

  • Milestone changed from None Set to 1.60
  • Status changed from new to assigned

comment:7 Changed 9 years ago by ydrol

Just a question, when will external-done-command trigger. Presumable 'done' means all file parts requested have downloaded? Is there also a way to run a command when pre-determined ratio is met? (I looked in the wiki but didnt see anything) Apologies if this is not the correct place to discuss.

comment:8 Changed 9 years ago by charles

@turbo: I like most of this patch, but I'm a little uneasy with remote users being able to specify arbitrary scripts to be executed on the machine running transmission-daemon. I'd feel better if the RPC pieces were removed.

comment:9 Changed 9 years ago by livings124

turbo: ping

comment:10 Changed 9 years ago by charles

  • Milestone changed from 1.60 to Sometime

comment:11 Changed 9 years ago by charles

  • Milestone Sometime deleted
  • Resolution set to invalid
  • Status changed from assigned to closed

My feelings on this feature still teeter between "no" and "maybe". Since there's been no reply or updates to this patch in three months, I'm going to close this ticket for now.

If this ticket is still important to anyone, please reopen this ticket with an updated patch that addresses comment number 8 above.

comment:12 Changed 9 years ago by mediatank

  • Cc mediatank added
  • Milestone set to 1.72
  • Resolution invalid deleted
  • Status changed from closed to reopened

Hi there,

I'm kind of a noob to this so I hope I'm using this system in the way it is intended.

However, I'd really love to see this issue adressed since I think auto-unpacking is a much wanted feature, especially for people who are not that handy with using telnet to start the unpak script (which are imo exactly te people that won't end up here to vote for this issue ;) )

comment:13 Changed 9 years ago by charles

  • Milestone changed from 1.72 to None Set

Hi mediatank,

Thanks for showing interest in this ticket. When people add comments to long-idle tickets, it helps the developers to know which ones are worth revisiting.

Setting the milestone is a faux pas -- you're essentially giving the development team marching orders. Even if this ticket does get re-accepted, I can 100% guarantee you it's not going into a bugfix "point release".

Also, the existing patch is not going to go in as-is, and its author's been gone for four months.

Maybe I'm misunderstanding things though. When you set the milestone for 1.72, were you volunteering to bring the patch up-to-date?

comment:14 Changed 9 years ago by mediatank

Haha no definitely not. I would if I could, but the best programming/scripting I ever did is some basic action script and a "hello world" in C :)

Sorry for setting the milestone: I'm not really familiar with bugtracking/ticketing systems.

I'm just a guy who would love to see post-processing (with unrarring and cleaning up like the nzbget post-processing script does) implemented in transmission for NMT..

comment:16 in reply to: ↑ 1 Changed 9 years ago by fyl

Any updates since then ?

Replying to turbo:

Charles: Sorry for 'stealing' this ticket (you can always take it back :) but I need it to. I'll be uploading a patch later today or tomorrow...

comment:17 Changed 9 years ago by fyl

Sorry ... pls ignore previous post. Read the trail the wrong way.

comment:18 Changed 8 years ago by mediatank

Anyone please.....? I'm begging you :)

comment:19 Changed 8 years ago by livings124

That's not going to speed things up...

comment:20 Changed 8 years ago by charles

  • Resolution set to invalid
  • Status changed from reopened to closed

This can be done without having to change any code in Transmission:

http://trac.transmissionbt.com/wiki/Scripts/EmailNotifier

comment:21 Changed 8 years ago by KyleK

  • Cc 1100101@… added
  • Resolution invalid deleted
  • Status changed from closed to reopened

I'm not really a fan of performing tasks via cronjobs. I've had this patch in my copy of Transmission for a while now and it is working just as expected. I'm going to revise it though and clean it up a bit. I'll also remove the RPC pieces as mentioned in comment 8.

comment:22 Changed 8 years ago by Elbandi

KyleK, could you upload the updated patch?

And 2 think: first, this patch is forgot to free the externalDoneCommand variable at tr_sessionclose. Second, the system() call is waiting until the script is finish (if i know good) . this is bad, if the script is more time to finish (link unpack a big torrent), because T is freezed. so a fork() is need before set envs and run command.

comment:23 Changed 8 years ago by marxarelli

For what it's worth, I would much rather see a general approach to this using a socket or other IPC to relay messages (such as but not limited to torrent completion) instead of executing commands. That would be much more flexible and secure, as the second process wouldn't be limited to the same user or system.

What about an additional RPC method (e.g. torrent-progress) that results in a persistent connection and returns JSON objects (the same as torrent-get) incrementally that detail the progress of the torrent? It could even take a number of parameters that filter what events should result in progress updates. For example, invocation with a parameter like notify-on-seed-ratio=2.0 would return an object whenever a torrent's seed ratio reaches "2.0". Or, to use the completion scenario, a parameter like notify-on-completion would return an object whenever a torrent finishes downloading.

With such a method, one could easily setup a separate process to listen for and handle all sorts of events. Just a thought.

comment:24 follow-up: Changed 8 years ago by charles

Just checking, is this still something that some people are interested in?

IMO the idea of persistent RPC/JSON connections is even more overkill for this feature than scripts would be...

comment:25 in reply to: ↑ 24 Changed 8 years ago by marxarelli

Replying to charles:

IMO the idea of persistent RPC/JSON connections is even more overkill for this feature than scripts would be...

It's absolutely overkill for this particular feature, but I was trying to offer a solution that isn't specific to it. In my mind, code or configuration that addresses only one disparate feature constitutes more bloat than something slightly more complex that can be used in any number of ways. However, maybe there isn't a need for the broader functionality that I've outlined. In that case it really would be worse.

comment:26 Changed 8 years ago by charles

  • Resolution set to invalid
  • Status changed from reopened to closed

comment:27 Changed 8 years ago by zosky

  • Milestone changed from None Set to Sometime
  • Resolution invalid deleted
  • Status changed from closed to reopened

i'd like to see this please. when deamon completes a dl it would be nice to trigger an xbmc-library update (&email too). for now im using cron @hourly (not ideal)

comment:28 Changed 8 years ago by nefk

  • Component changed from libtransmission to Daemon
  • Version changed from 1.42 to 1.91

Hi,

i am using Transmission as a daemon on my Gentoo system. It runs fine. But i add torrent files over the website and what to add the function that automatically after the download is finished, transmission runs a shell script? Is this possible? How do i have to reconfigure transmission?

Thanks a lot.

Cu nefk

comment:29 Changed 8 years ago by nefk

Hi,

i am using Transmission as a daemon on my Gentoo system. It runs fine. But i add torrent files over the website and what to add the function that automatically after the download is finished, transmission runs a shell script? Is this possible? How do i have to reconfigure transmission?

Thanks a lot.

Cu nefk

comment:30 Changed 8 years ago by livings124

  • Version changed from 1.91 to 1.42

comment:31 Changed 8 years ago by nefk

Hi,

can someone add this patch for a newer version like 1.91?

Thanks a lot

Cu nefk

comment:32 Changed 8 years ago by sim

(spam removed)

Last edited 8 years ago by titer (previous) (diff)

comment:33 Changed 8 years ago by mechanic

what about supporting webhooks? seems like a good compliment to the rpc interface.

comment:34 Changed 8 years ago by charles

  • Component changed from Daemon to Transmission
  • Resolution set to fixed
  • Status changed from reopened to closed

Implemented for transmission-remote, transmission-gtk, and transmission-qt for 2.00

comment:35 Changed 8 years ago by livings124

  • Summary changed from [PATCH] Transmission daemon to run script after torrent completion to run script after torrent completion

comment:36 Changed 8 years ago by Darwin

  • Resolution fixed deleted
  • Status changed from closed to reopened

Contrary to the resolution comment, this does not appear to have been implemented for transmission-remote.

Also, would it be possible to support other events, like when a torrent is added or seeding is finished?

comment:37 Changed 8 years ago by Longinus00

What do people think about spawning a process to run the script asynchronously? The low effort way of doing this would be to just append " &" to the file path. More involved solutions might involve posix_spawn or forking.

comment:38 Changed 8 years ago by charles

Added to transmission-remote in trunk for 2.00 by r10640.

@Longinus00: do you want to make a patch for that?

comment:39 Changed 8 years ago by Longinus00

I'm not sure which method is the best way to do this. We could simply add documentation to EditConfigFiles about adding & to the end of the script path.

comment:40 Changed 8 years ago by charles

I doubt people would read the documentation. :)

comment:41 Changed 8 years ago by charles

I'm thinking of maybe adding jch's threadpool from #2808 after all, and having a short-lived worker thread to fire off these scripts. Longinus00, how does that sound?

comment:42 Changed 8 years ago by Longinus00

That sounds fine. We might want to have only one script run at a time and queue them up if the script takes some time to finish, e.g. scripts which uncompress files in a torrent. This will also make life easier for script writers as they won't have to worry about race conditions as much. I suppose this could be done by making a threadpool especially for running scripts and setting maxthreads to 1. I'm also somewhat partial to Darwin's request about supporting other events.

On a related note, we should make explicit that torrents can't be finished if they never started. I usually "uncheck all" in a torrent if I only want to download a few files and this currently sets off the finished flag. Something like the following should suffice.

diff --git libtransmission/torrent.c libtransmission/torrent.c
index 67a4773..ab2107b 100644
--- libtransmission/torrent.c
+++ libtransmission/torrent.c
@@ -1101,7 +1101,7 @@ tr_torrentStat( tr_torrent * tor )
             break;
     }

-    s->finished = seedRatioApplies && !seedRatioBytesLeft;
+    s->finished = s->downloadedEver && seedRatioApplies && !seedRatioBytesLeft;

     if( !seedRatioApplies || s->finished )
         s->seedRatioPercentDone = 1;

comment:43 follow-up: Changed 8 years ago by charles

  • s->finished = seedRatioApplies && !seedRatioBytesLeft;

+ s->finished = s->downloadedEver && seedRatioApplies && !seedRatioBytesLeft;

I'm not sure I understand this patch. So the seed ratio can't apply to the initial seeder?

comment:44 in reply to: ↑ 43 Changed 8 years ago by Longinus00

Replying to charles:

  • s->finished = seedRatioApplies && !seedRatioBytesLeft;

+ s->finished = s->downloadedEver && seedRatioApplies && !seedRatioBytesLeft;

I'm not sure I understand this patch. So the seed ratio can't apply to the initial seeder?

Ahh, overlooked that; haveValid should work instead of downloadedEver.

The point of the patch is to not flag a torrent as finished if you use "uncheck all" or something similar prior to starting the torrent. This way scripts won't fire as you try to pick out the files you want in a torrent.

comment:45 Changed 8 years ago by charles

comment:46 Changed 7 years ago by charles

  • Milestone changed from Sometime to 2.00
  • Resolution set to fixed
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.