script-torrent-done-filename on OS X?

[anville]

I have been trying to get a script to run after torrent is complete by setting "script-torrent-done-enabled" and "script-torrent-done-filename" on my 10.6 Mac, but no luck so far.

Here are my settings:

Code: Select all

$ defaults read org.m0k.transmission |grep script-torrent
    "script-torrent-done-enabled" = 1;
    "script-torrent-done-filename" = "/Users/anville/bin/post_process_torrents.sh";

Is this feature functional on Mac?

[Rolcol]

No... Transmission on Mac doesn't use settings.json so you can't add or change preferences just like you can on GTK+/Qt/Daemon.

[Rolcol]

?

https://trac.transmissionbt.com/wiki/Ed ... les#MacOSX

Just because you add it to the config file doesn't mean Transmission will honor it like the config files of the other platforms. I just did

Code: Select all

defaults write org.m0k.transmission upload-slots-per-torrent 2

and nothing changed from the default of 14 set in the source code.

[anville]

So, I tried this:

Code: Select all

transmission-remote localhost  --torrent-done-script "/Users/anville/bin/post_process_torrents.sh"

and the script would run upon completion, which is cool, sort of, but it's not persistent. I suppose I could set up a cron job to "remind" the client every so often!

Is this a bug that the Mac client doesn't honor the entries in the plist file? Or is something that just hasn't been implemented yet?

[Rolcol]

Not saying you're wrong, but did you quit Transmission before making the edit. Also, I believe, according to Longinuus this script thing should work.

Yep. I quit Transmission, made the change, and restarted. What kind of tester do you think I am

[Rolcol]

Thanks for correcting my grammar, Sir! I'm dying to test this script possibility on delete .part files. How does one refer to the torrent name--$TORRENT_ID?

Also since T on OS X uses no less than 3 .plist files, I wonder if one needs to be more specific when doing the defaults write bit.

~/Library/Preferences/org.m0k.transmission.LSSharedFileList.plist
~/Library/Preferences/org.m0k.transmission.plist
~/Library/Application Support/Transmission/Transfers.plist

I currently don't see #1 anywhere in my ~/Library folder. I'm thinking that is created by the OS.
#2 is the preferences file that I made the change to. That is the one that regulates the settings.
#3 just lists the added torrents, their location, infohash, group number, and activity status. That info is written into the .resume files, too, and .resume is the default for other systems. #3 looks like it was created to support those other features that libtransmission doesn't.

("You're" and "Your" are one of my biggest spelling pet peeves. You weren't supposed to notice that :p)

[anville]

Path should be /bin/post_process_torrents.sh, right?

x190, as the long as the path is correct, it shouldn't matter where your script goes!

Like I mentioned above, I was able to set this using the remote client CLI:

Code: Select all

transmission-remote localhost  --torrent-done-script "/Users/anville/bin/post_process_torrents.sh"

It does work, but it's not persistent (meaning it won't be set again if I restart transmission). I had to build the client from source, as it doesn't seem to be distributed with the app bundle (but I could be wrong?).

I was able to set up a cron job to set the script every hour.

I do notice that sometimes it runs before the files have been moved from the incomplete folder to the complete folder.... Weird.

[anville]

Regarding script persistence did you stop (quit) the daemon (or client)

No. Since "transmission-remote" talks to the torrent daemon directly, it won't work unless the daemon is running. That's why I had to make a cron hack to keep "reminding ' it of the script. Every time I restart the app, it "forgets".

Obviously this is a deficiency in the Mac version of the app that it doesn't read this from the settings file. I will search in Trac later, and post an issue if it's not there already.

[serversurfer]

x190, so are you saying that the script will execute as long as it's set up properly in the JSON file? I'm considering moving from the GUI client to the daemon, but running the torrent-done script is pretty important to my flow.

Can anyone confirm/deny this before I go through the trouble of setting up the daemon on my other machine?

[serversurfer]

Okay, thanks. I just got mediatomb launchd'd on the iMac and I was going to start working on transmission-daemon tonight, so I guess I'll report back and let you guys know how it goes.

Speaking of the torrent-done script though, anyone have any idea why sometimes it seems to not fire? My script just runs files through ffmpeg to change the container to .m4v, so it's pretty straightforward, but occasionally it just doesn't work. The issue doesn't seem to be the video itself, as when I manually run ffmpeg on the curiously-unmassaged files, it does its thing without any errors or warnings. Is the script launcher just buggy, or am I missing something?

Here's the script itself…

Code: Select all

#!/bin/sh
{


CONVERTOR=/.sw/bin/ffmpeg
CODEC_ARGS="-vcodec copy -acodec copy -f mp4"

EPISODE=`echo $TR_TORRENT_NAME | sed 's:\(S[0-9]*E[0-9]*\).*:\1:'`
SERIES=`echo $TR_TORRENT_NAME | sed 's:\(S[0-9]*\)[[:print:]]*:\1:'`


if [ ! -d "$TR_TORRENT_DIR/Fixed/$SERIES" ]; then
	mkdir $TR_TORRENT_DIR/Fixed/$SERIES
fi


$CONVERTOR -i $TR_TORRENT_DIR/$TR_TORRENT_NAME $CODEC_ARGS $TR_TORRENT_DIR/Fixed/$SERIES/$EPISODE.m4v


} &

I was having the same issue before I added the mkdir and the stuff to pull out $SERIES, so I don't think that's the issue. In the past, I've had several instances of ffmpeg running simultaneously without issue, so I don't think it's a matter of two completed torrents stepping on each other's toes. (At least, not from ffmpeg's perspective.)

[ijuxda]

It could be that $TR_TORRENT_DIR or $TR_TORRENT_NAME has spaces or other shell metacharaters in it.

[serversurfer]

No spaces or other oddness in $TR_TORRENT_DIR. I don't have any examples still laying around, but I'm reasonably sure $TR_TORRENT_NAME is clean as well. (I didn't need to treat them specially in the shell when I massaged them manually, etc.) Good guess, but I don't think it's the issue.

I'll try adding some log echoes to my script and see if I can narrow down where it's failing, at least, though currently, I'm distracted by the fact that I got transmission-daemon up and running as a launchd service, but as soon as I added a torrent to my watched directory, it basically annihilated my entire LAN. A multitude of transmission-daemon instances had spawned, and while they seemed to be downloading the file as expected, nothing else was happening on the network. I tried the web interface and it showed the torrent I'd added, but it said it has only downloaded about 315KB of it, and it said I wasn't connected to any peers. Meanwhile, Finder reported that the .part was about 375MB and growing. I unloaded the job from launchctl, but had to resort to killall to get rid of all of the processes which had spawned. Last, but not least, it didn't even trash the .torrent like it was supposed to do. Anyway, figuring this out is currently at the top of my list now.

[serversurfer]

Well, I seem have gotten transmission-daemon to behave by disabling PEX.

Then I was having trouble getting it to respect the trash-torrent and torrent-done flags—it does seem to be reading the JSOM file, for what it's worth—so I decided to try using transmission-remote to get it to do the post-processing.

That's when I realized that fink only supplies transmission 1.91.

[serversurfer]

Well, I got 2.13 installed.

I'm able to get it to run my post-processing script, but like anville, I do need to resort to transmission-remote to tell it where to find the script, so while the functionality is definitely there, for whatever reason, it's not reading the script location from the JSON file. Oddly, does seem to be reading other information from the JSON, like the fact that it's supposed to run a script at all. Sure sounds like a bug to me.

However, I'm still having the issue where the script randomly(?) fails to fire. Looking at the output from transmission-daemon, I can see that in fact, the script isn't even being called, so it's not an issue with the script itself. Out of eight completed files, the script has fired six times, which is similar to the success ratio I was getting when using the GUI client. AFAICT, there's nothing wrong with the file/path names. In fact, it'll fire on one file and not on another, when the file name differs by only a digit or two. Better than no automation whatsoever, I suppose, but annoying that I still need to manually check things to make sure all the work was done properly (and then do it myself when it wasn't).

[serversurfer]

PEBCAK

Seems I was setting script-torrent-done in the JSOM instead of script-torrent-done-filename. ><