TorrentToMedia not being called? (now: DS compatibility WIP)

[piejanssens]

I've set up SR to use torrents for backlog. Followed the nzbToMedia wiki on how to setup TorrentToMedia. The torrent is added to transmission, but when the download finishes nothing happens and I don't see any errors or log traces of calling the TorrentToMedia.py script in logs/nzbtomedia.log.

Update: when I stop/start the transmission package (SynoCommunity) the settings.json file is overwritten or at least this part is overwritten:

"script-torrent-done-enabled": true, 
"script-torrent-done-filename": "/volume1/downloads/nzbToMedia/TorrentToMedia.py",

[piejanssens]

Stop transmission before you change the config, you dumb ass. :)

[clinton-hall]

LMAO... I think most of us have been caught by that...

Please feel free to edit the wiki to help prevent others from doing the same...

The hardest thing for me is documenting things that I don't specifically use, or haven't done for a while, or otherwise just take for granted...

[piejanssens]

It is in the wiki :smile:

Make sure you edit while the daemon is not running.

[clinton-hall]

Oh... that is priceless :dancer: I think this shows that I don't read the wiki either.

Let me know if you run into any issues with this.

[piejanssens]

Hmm damn, I do have an issue still.. Even now it's in the settings.json correctly, the TorrentToMedia.py script is not called :angry: Don't know what to do next.

[clinton-hall]

Are there any transmission logs you can access?

As a guess, if it isn't config, it is likely permissions.

If you did a git clone of these scripts I am guessing you did this via ssh as root. Transmission probably runs as transmission:users

You can try

cd /volume1/downloads
chown -R transmission:users nzbToMedia

[piejanssens]

Ah, maybe yes. Remember my other issue this week? Then we did chown -R nzbget:users nzbToMedia :smile:

I don't see any transmission logs btw..

I did this now and will test again:

chgrp -R users nzbToMedia/
chmod -R g+w nzbToMedia/

[clinton-hall]

Damn... I'm slow.... Sometimes I don't put posts together...

Ok... So 755 should be fine for transmission:users since the group users has r-x permissions.

Try doing a 777 on autoProcessMedia.cfg and logs/nzbtomedia.log Both of these are ignored by git update, so you should be safe....

Now, the other likely issue... Transmission is unable to call a python script because the PATH variable used by Transmission spkg on Synology doesn't include the python location???

This can be verified by creating a .sh script that just dumps the environment into a file, and call this from Transmission... But eh... That's when you are desperate.

What I would do is first verify where your python and python2 executables are

which python
which python2

Let us assume they are at /opt/bin for this next step... You can obviously correct this.

What you want to do is edit the script that launches transmission (how do you start/stop via ssh?) this is usually an /etc/init.d/transmission.sh or similar... If you edit this file, you add the following line just under all of the global definitions...

export PATH=$PATH:/opt/bin

Then restart Transmission.... Now when it goes to launch the script, it should run... But if it can't find Python in the path, it will just print an error to terminal (which isn't monitored) so there will be no logging or anyway to know...

Permissions and Paths.... Almost impossible to figure out with so many different systems and Apps...

[clinton-hall]

And if this does indeed work.... This will certainly need to be added to the wiki ;)

[piejanssens]

Did 777 for both files, now testing again...

I can already say that which pythonand which python2 returns nothing.

/volume1/@appstore/python/bin/python2

[clinton-hall]

Wow... So you shouldn't be able to run this script manually??? But that is as root... It might be that your nzbget/SABnzbd downloader does have this path defined. The other way to do this might be to create a symlink to your python binary

find / -I name python2.7

This will return a full path (e.g /volume1/opt/bin/python2.7)

Create a symlink to somewhere that is in your path (and hopefully is not reset on reboot...) Try /usr/local/bin

ln -sf /volume1/opt/bin/python2.7 /usr/local/bin/python2
ln -sf /volume1/opt/bin/python2.7 /usr/local/bin/python

Even if that works now, but is reset after a reboot, at least we know what the issue is and we can find the best way to handle this.

[piejanssens]

I'm using the Syno pkg and I don't see any update for PATH in the transmission package for python. IMHO it should be in the pyhon package but it's not... https://github.com/SynoCommunity/spksrc/blob/develop/spk/python/src/dsm-control.sh

Your seach query gives this:

/volume1/@appstore/python/bin/python2.7
/volume1/@appstore/python/include/python2.7
/volume1/@appstore/python/lib/python2.7
/volume1/@appstore/couchpotatoserver/env/lib/python2.7
/volume1/@appstore/couchpotatoserver/env/include/python2.7
/volume1/@appstore/couchpotatoserver/env/bin/python2.7
/volume1/@appstore/headphones/env/lib/python2.7
/volume1/@appstore/headphones/env/include/python2.7
/volume1/@appstore/headphones/env/bin/python2.7
/volume1/@appstore/sickbeard-custom/env/lib/python2.7
/volume1/@appstore/sickbeard-custom/env/include/python2.7
/volume1/@appstore/sickbeard-custom/env/bin/python2.7
/volume1/@debian/usr/lib/python2.7

Python is also located in /usr/local/python/bin/python2.7 (I guess that's the same as the first line).

Other packages like CP and SB are setting the PATH variable to include /usr/local/python/bin. I have them running too, so isn't it werid that which pythondoesn't return anything?!

[clinton-hall]

Is there also a /usr/local/python/bin/python2 and /usr/local/python/bin/python?

I don't understand Syno packages... But if I am reading correctly you want to change https://github.com/SynoCommunity/spksrc/blob/develop/spk/transmission/src/dsm-control.sh#L9 To

PATH="${INSTALL_DIR}/bin:/usr/local/python/bin:${PATH}"

[clinton-hall]

Ah... There it is... Look at NZBGet https://github.com/SynoCommunity/spksrc/blob/develop/spk/nzbget/src/dsm-control.sh#L10

That is why NZBGet works and Transmission doesn't

I would suggest reporting this on the Syno repository... Link in the URL to this thread if you want...

[piejanssens]

Yes there is python, python2 and python2.7.

Yes I was seeing that difference too. But I don't get it, that path variable is per application and not for the system? It would be better if the python package set the PATH variable if that was possible.

[clinton-hall]

Exactly... The transmission application uses a path that doesn't find python... So transmission can't run a python script.

You just verified that the default system (root user) path doesn't find python command.

[clinton-hall]

Obviously the nzbget app actually specifically sets python into its path (which is what you need Transmission to do). It would be great to set this into the system path, but my guess is the system path is set in the firmware and is expanded from flash at boot time. So not easy to add to.

[piejanssens]

That also removes the option of using DS with TorrentToMedia.py I guess, because it is totally the same as transmission under the hood (even setting.json). It was the next thing I was going to try..

[clinton-hall]

This will be any easy fix... Just need to find the file...

cd /usr/local/transmission
ls

[piejanssens]

I mean that DS will not be able to run python..

[clinton-hall]

Possibly is you can configure its path...

[piejanssens]

https://github.com/SynoCommunity/spksrc/pull/1137

[clinton-hall]

Nice. That should do it...

[piejanssens]

I think we should use a bash script instead of directly calling TorrentToMedia.py for DownloadStation and set the PATH first. What do you think?

#!/bin/sh

PYTHON_DIR="/usr/local/python"
PATH="${PYTHON_DIR}/bin:${PATH}"
/volume1/downloads/nzbToMedia/TorrentToMedia.py

[piejanssens]

btw, TorrentToMedia.py works with those changes from the pull request :wink:

Just one minor thing:

2014-07-09 15:46:43 INFO    ::COPYLINK: SOURCE FOLDER: [/volume1/downloads/torrent/tv/Banshee S02E10 HDTV x264-KILLERS[ettv]]
2014-07-09 15:46:43 INFO    ::COPYLINK: TARGET FOLDER: [/volume1/downloads/torrent/tv/tv/Banshee S02E10 HDTV x264-KILLERS[ettv]]
2014-07-09 15:46:43 INFO    ::COPYLINK: Moving SOURCE MEDIAFILE -> TARGET FOLDER
2014-07-09 15:46:43 INFO    ::MAIN: FLATTEN: Flattening directory: /volume1/downloads/torrent/tv/tv/Banshee S02E10 HDTV x264-KILLERS[ettv]
2014-07-09 15:46:43 INFO    ::MAIN: Found 1 media files in /volume1/downloads/torrent/tv/tv/Banshee S02E10 HDTV x264-KILLERS[ettv]

Why is it being put in another 'tv' folder? :tongue: SR is adding the torrent with that directory '/torrent/tv' so that it's seperated from other '/torrent'. And what would happen if I download a song/movie/application with transmission because transmission will call 'TorrentToMedia.py' for every torrent?

Note for anyone that wants to try and get this working with DownloadStation: You need to comment out rm ${PACKAGE_DIR}/etc/download/settings.json in /var/packages/DownloadStation/scripts/start-stop-status.

[piejanssens]

Hell yeah! It works with DownloadStation too!!

[piejanssens]

@clinton-hall Created a wiki page :wink:

https://github.com/clinton-hall/nzbToMedia/wiki/Download-Station

[clinton-hall]

good job with DownloadStation.

for the creating a second tv directory, what is happening here is that all downloads are placed into their own category directory in the outputDirectory. so Your outputDirectory must be /volume1/downloads/torrent/tv

the way this was intended is that the outputDirectory should not include a category. Also, by separating this from the Download directory, we actually create a link in a new location, process this while leaving the actual torrent files alone (so you can seed indefinitely) and then remove the torrent itself if you have enabled the delete original option.

so, my recommendation for your config is to create a directory /volume1/downloads/torrent/processed and then set autoProcessMedia.cfg

[Torrent]
    outputDirectory = /volume1/downloads/torrent/processed
    useLink = hard

now, movies will be linked to /volume1/downloads/torrent/processed/movies, tv to /volume1/downloads/torrent/processed/tv etc...

Using hard links allows this to be treated as a new file without taking any additional hard disk space... give it a go.

the way you are currently using it will work, but just looks a little messy.

[clinton-hall]

out of curiosity? does DS use the same transmission RPC? with transmission we can delete the torrent, and pause it before processing etc... but I don't know if these are available in DS.

[piejanssens]

OK, I didn't know transmission supported categories..? I am using useLink = move atm. Don't understand this hard linking. Could you tell me why it is better than move for this use case?

I tested RPC with this, but I get a 404. I do see a lot of messages across the internet of people using RPC with DS, so I guess it should be possible.

[clinton-hall]

ok...here goes...

a "file" is made up of the data and the "node"/file-header... A hard-link will create a new file-header that points to the same data. So essentially this appears as a new file, but it takes up (almost) no extra space. if you delete the linked (new) file-header, the original remains. if you edit the data for either file, the data is changed for the other. If you delete the original file this deletes the first fileheader only and the second fileheader still points to the original data....

So a hard-link is a safe way to handle 2 instances of the same data.

A sym-link is just a short-cut that points to the data. if you delete the original data, the link points to nothing... but with a hardlink the data remains until ALL fileheaders are deleted.

Now, we all know a copy creates a copy of the data and a new filename (new file-header)... a Move actually makes a hard-link to the new location and then deletes (unlinks) the first file-header. (this is on the same directory... across directories Hard-links don't work, which is why a move then does a copy and delete).

So, with my script, doing a hard-link actually does half of the move... if you have delete original enabled, it actually does do a link, then delete... so it does a move (but the difference here is it doesn't delete the original file header until we are confident the new file-header has been correctly processed by CP/SB etc)

RPC... In your settings.json, what rpc settings are shown? I suspect the main difference here is going to be the rpc mount point... The Transmission rpc used in my script appears to be hard-coded... but I can try to add an option to pass in a different mount point.

[piejanssens]

So using hard link + delete original = move on steroids because it is going way faster?

I disabled the white listing for testing purposes.

    "rpc-authentication-required": false,
    "rpc-bind-address": "0.0.0.0",
    "rpc-enabled": true,
    "rpc-password": "{scrambles}",
    "rpc-port": 9093,
    "rpc-url": "/transmission/",
    "rpc-username": "",
    "rpc-whitelist": "127.0.0.1",
    "rpc-whitelist-enabled": false,

[clinton-hall]

A move SHOULD be a hard-link followed by an unlink, so if this is actually going faster, it means your "move" is probably defaulting to a copy and delete? If this is the case it may be a limitation to the OS interface or similar... but by forcing a hard-link (as long as no errors are encountered) this will be pretty much instant.

Have you hidden the rpc username or is there none defined... I am thinking this probably need to be defined to work?

How does this compare to the settings you have on Transmission?

[piejanssens]

Yes it's correct because rpc-authentication-requires is false.

I should check somehow if anything is running on that 9093 port..

[clinton-hall]

What happens if you put

"rpc-authentication-required": true,
"rpc-bind-address": "0.0.0.0",
"rpc-enabled": true,
"rpc-password": "admin",
"rpc-port": 9093,
"rpc-url": "/transmission/",
"rpc-username": "admin",
"rpc-whitelist": "127.0.0.1",
"rpc-whitelist-enabled": false, 

I am wondering if the rpc client in my code specifically requires authentication? Are you using authentication on your Transmission (not DS)? Can you add quthentication to DS without breaking it?

[piejanssens]

Used netstat -a | grep 9093 to see if anything was listening on that port. It returned no results... But, it turns out that DS will stop the transmission daemon when all torrents are finished or when all torrent tasks have been deleted. I added a torrent and now:

tcp 0 0 0.0.0.0:9093 0.0.0.0:* LISTEN 5982/transmissiond

So this is used by TorrentToMedia for RPC?

TransmissionHost = localhost
TransmissionPort = 9093
TransmissionUSR = 
TransmissionPWD = 

[piejanssens]

2014-07-10 09:12:13 ERROR ::MAIN: Failed to connect to Transmission

Might try with user/pass now..

[piejanssens]

No success, same error in TorrentToMedia (it also stops processing after it failed to connect). But there is hope because I was able to connect to the RPC from transmission in DS using this python cli: https://github.com/fagga/transmission-remote-cli

I used this connection string: DiskStation> /usr/local/python/bin/python transmission-remote-cli -c user:pass@localhost:9093

[clinton-hall]

Ok... I'll need to have a look at that remote-cli and see if I can use that to replace the existing RPC client?

Have you verified that the existing script works to connect to transmission (not DS)?

[piejanssens]

Yes it works for transmission I saw that a torrent got deleted by your script from transmission yesterday.

[piejanssens]

Hey @clinton-hall,

I cloned a copy to my MacBook and I'm trying to debug the transmissionrpc from TorrentToMedia with PyCharm IDE. Got a 403 and a clear message that whitelist was turned on and my PC wasn't whitelisted. I don't know why it didn't work last time though.. maybe I was editing the settings.json while DS was running and it got reset. On my mac I can't use a torrent from DS so if I want to test with DS/tranmission's arguments I need to use nzbToMedia from my Syno...

So anyway it should be able to connect now, I don't see anything about TransmissionRPC in the log anymore. I'll turn on debug log and see what happens.

[piejanssens]

Giving up.. Connection is fine but TorrentToMedia is never called with any arguments (I guess the arguments are needed to delete the torrent), therefore I called my script with the arguments available by transmission and in the order that TorrentToMedia is expecting it (no category variable available from transmission..): "script-torrent-done-filename": "/volume1/downloads/execTorrentToMedia.sh $TR_TORRENT_DIR $TR_TORRENT_NAME tv $TR_TORRENT_HASH $TR_TORRENT_ID",

Unfortunately did didn't even execute the bash script. This is what my bash script looks like:

#bin!/bin/sh

PATH=/usr/local/python/bin:$PATH                            
python /volume1/downloads/nzbToMedia/TorrentToMedia.py $@

[clinton-hall]

I wonder is Syno calls these environment variables something different?

If you just call the script as you did previously (from DS without the variables being found) but enable the option

[General]
   log_env = 1

This will dump all environment variables into the log so you can see if the same data is used under a different name...

I wonder if TR_TORRENT_NAME is actually DS_TORRENT_NAME or similar?

[piejanssens]

2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_APP_VERSION: 2.42
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_HASH: 09a948d3ace45ef7979bcdcf1f9d04d39aae9e54
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: PWD: /
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TIME_LOCALTIME: Fri Jul 11 23:15:18 2014
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_NAME: Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_ID: 973
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: PATH: /usr/local/python/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_DIR: /volume1/downloads/torrent/tv

A bit further down I do see that it stops (not remove?) the torrent: 2014-07-11 23:15:28 DEBUG ::MAIN: Stopping torrent Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 in transmission while processing

But in fact the torrent is still in DS.

[clinton-hall]

Ok, so it connects fine, but the stop, start, delete calls don't appear to be working...

Have you seen any information to suggest what differences might exist between Transmission and DS?

[clinton-hall]

To confirm... The script should stop the torrent while it does e processing... So the stop is at the beginning.

Then it does the linking, extracting' processing an then at the end it should start/resume the torrent for seeding, or delete the torrent and files (if processed successfully and option deleteOriginal is set)

[piejanssens]

I connected with transmission-remote-cli again and I don't see the torrent in there.. I believe that DS is keeping the torrent or better call it a download task in the list even though it's stopped and removed from the underlying transmission.

[piejanssens]

deleteOriginal was set to '0', but it did remove the files from my download folder..

[clinton-hall]

Can you show the full log from the pp event?

[piejanssens]

2014-07-11 23:15:24 INFO    ::MAIN: Loading config from [/volume1/downloads/nzbToMedia/autoProcessMedia.cfg]
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_APP_VERSION: 2.42
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_HASH: 09a948d3ace45ef7979bcdcf1f9d04d39aae9e54
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: PWD: /
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TIME_LOCALTIME: Fri Jul 11 23:15:18 2014
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_NAME: Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_ID: 973
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: PATH: /usr/local/python/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin
2014-07-11 23:15:24 INFO    ::ENVIRONMENT: TR_TORRENT_DIR: /volume1/downloads/torrent/tv
2014-07-11 23:15:24 INFO    ::MAIN: Checking database structure...
2014-07-11 23:15:24 DEBUG   ::MAIN: Checking Initial Schema database upgrade
2014-07-11 23:15:24 DEBUG   ::MAIN: InitialSchema upgrade not required
2014-07-11 23:15:24 DEBUG   ::MAIN: Checking if we can use git commands: "/usr/local/git/bin/git" version
2014-07-11 23:15:24 DEBUG   ::MAIN: Executing "/usr/local/git/bin/git" version with your shell in /volume1/downloads/nzbToMedia
2014-07-11 23:15:24 DEBUG   ::MAIN: git output: git version 1.8.4
2014-07-11 23:15:24 DEBUG   ::MAIN: "/usr/local/git/bin/git" version : returned successful
2014-07-11 23:15:24 DEBUG   ::MAIN: Using: "/usr/local/git/bin/git"
2014-07-11 23:15:24 DEBUG   ::MAIN: Executing "/usr/local/git/bin/git" symbolic-ref -q HEAD with your shell in /volume1/downloads/nzbToMedia
2014-07-11 23:15:24 DEBUG   ::MAIN: git output: refs/heads/master
2014-07-11 23:15:24 DEBUG   ::MAIN: "/usr/local/git/bin/git" symbolic-ref -q HEAD : returned successful
2014-07-11 23:15:24 INFO    ::MAIN: Checking if git needs an update
2014-07-11 23:15:24 DEBUG   ::MAIN: Executing "/usr/local/git/bin/git" rev-parse HEAD with your shell in /volume1/downloads/nzbToMedia
2014-07-11 23:15:24 DEBUG   ::MAIN: git output: 7ac3d510a299552fc05a3851f2bd58f2e4efdc12
2014-07-11 23:15:24 DEBUG   ::MAIN: "/usr/local/git/bin/git" rev-parse HEAD : returned successful
2014-07-11 23:15:24 DEBUG   ::MAIN: Executing "/usr/local/git/bin/git" fetch origin with your shell in /volume1/downloads/nzbToMedia
2014-07-11 23:15:27 DEBUG   ::MAIN: git output: From https://github.com/clinton-hall/nzbToMedia
   37cc367..85afe09  nightly    -> origin/nightly
2014-07-11 23:15:27 DEBUG   ::MAIN: "/usr/local/git/bin/git" fetch origin : returned successful
2014-07-11 23:15:27 DEBUG   ::MAIN: Executing "/usr/local/git/bin/git" rev-parse --verify --quiet "@{upstream}" with your shell in /volume1/downloads/nzbToMedia
2014-07-11 23:15:28 DEBUG   ::MAIN: git output: 7ac3d510a299552fc05a3851f2bd58f2e4efdc12
2014-07-11 23:15:28 DEBUG   ::MAIN: "/usr/local/git/bin/git" rev-parse --verify --quiet "@{upstream}" : returned successful
2014-07-11 23:15:28 DEBUG   ::MAIN: Executing "/usr/local/git/bin/git" rev-list --left-right "@{upstream}"...HEAD with your shell in /volume1/downloads/nzbToMedia
2014-07-11 23:15:28 DEBUG   ::MAIN: git output: 
2014-07-11 23:15:28 DEBUG   ::MAIN: "/usr/local/git/bin/git" rev-list --left-right "@{upstream}"...HEAD : returned successful
2014-07-11 23:15:28 DEBUG   ::MAIN: cur_commit = 7ac3d510a299552fc05a3851f2bd58f2e4efdc12 % (newest_commit)= 7ac3d510a299552fc05a3851f2bd58f2e4efdc12, num_commits_behind = 0, num_commits_ahead = 0
2014-07-11 23:15:28 INFO    ::MAIN: No update needed
2014-07-11 23:15:28 INFO    ::MAIN: nzbToMedia Version:7ac3d510a299552fc05a3851f2bd58f2e4efdc12 Branch:master (Linux 2.6.32.12)
2014-07-11 23:15:28 DEBUG   ::MAIN: Connecting to transmission: http://localhost:9093
2014-07-11 23:15:28 INFO    ::MAIN: #########################################################
2014-07-11 23:15:28 INFO    ::MAIN: ## ..::[TorrentToMedia.py]::.. ##
2014-07-11 23:15:28 INFO    ::MAIN: #########################################################
2014-07-11 23:15:28 DEBUG   ::MAIN: Options passed into TorrentToMedia: ['/volume1/downloads/nzbToMedia/TorrentToMedia.py']
2014-07-11 23:15:28 DEBUG   ::MAIN: Adding TORRENT download info for directory /volume1/downloads/torrent/tv to database
2014-07-11 23:15:28 DEBUG   ::MAIN: Received Directory: /volume1/downloads/torrent/tv | Name: Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 | Category: 
2014-07-11 23:15:28 DEBUG   ::MAIN: SEARCH: Found Category: tv in directory structure
2014-07-11 23:15:28 INFO    ::MAIN: SEARCH: Found torrent file Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 in input directory directory /volume1/downloads/torrent/tv
2014-07-11 23:15:28 INFO    ::MAIN: SEARCH: Setting inputDirectory to /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:28 DEBUG   ::MAIN: Determined Directory: /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 | Name: Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 | Category: tv
2014-07-11 23:15:28 INFO    ::MAIN: Auto-detected SECTION:SickBeard
2014-07-11 23:15:28 DEBUG   ::MAIN: Stopping torrent Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 in transmission while processing
2014-07-11 23:15:33 INFO    ::MAIN: Output directory set to: /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:33 DEBUG   ::MAIN: Scanning files in directory: /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 DEBUG   ::MAIN: Found 1 files in /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 INFO    ::COPYLINK: MEDIAFILE: [Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4]
2014-07-11 23:15:34 INFO    ::COPYLINK: SOURCE FOLDER: [/volume1/downloads/torrent/tv]
2014-07-11 23:15:34 INFO    ::COPYLINK: TARGET FOLDER: [/volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4]
2014-07-11 23:15:34 INFO    ::COPYLINK: SOURCE AND TARGET folders are the same, skipping ...
2014-07-11 23:15:34 DEBUG   ::MAIN: Checking for archives to extract in directory: /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 INFO    ::MAIN: FLATTEN: Flattening directory: /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 ERROR   ::FLATTEN: Could not flatten /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 INFO    ::MAIN: Found 1 media files in /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 INFO    ::MAIN: Calling SickBeard:tv to post-process:Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:15:34 INFO    ::MAIN: Attempting to auto-detect tv fork
2014-07-11 23:15:34 INFO    ::MAIN: SickBeard:tv fork auto-detection successful ...
2014-07-11 23:15:34 INFO    ::MAIN: SickBeard:tv fork set to failed-torrent
2014-07-11 23:15:34 POSTPROCESS::SICKBEARD: SUCCESS: The download succeeded, sending a post-process request
2014-07-11 23:15:34 DEBUG   ::SICKBEARD: Opening URL: http://localhost:8081/home/postprocess/processEpisode
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Processing folder /volume1/downloads/torrent/tv
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: TV_DOWNLOAD_DIR: 
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: PostProcessing Path: /volume1/downloads/torrent
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: PostProcessing Dirs: []
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: PostProcessing Files: [u'/volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4']
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: PostProcessing VideoFiles: [u'/volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4']
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: PostProcessing RarContent: []
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: PostProcessing VideoInRar: []
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Processing /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 (Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4)
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Found result in history: (<sickbeard.tv.TVShow object at 0x11488db0>, 2, [], 1)
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Retrieving episode object for 2x10
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Snatch history had a quality in it, using that: SD TV
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: SB snatched this episode so I'm marking it as priority
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Is ep a priority download: True
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: File /volume1/TV/Banshee/Season 02/Banshee.S02E10.SD.TV.Bullets and Tears.mp4 doesn't exist so there's no worries about replacing it
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: This download is marked a priority download so I'm going to replace an existing file if I find one
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Found release name Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Destination folder for this episode: /volume1/TV/Banshee/Season 02
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Moving file from /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 to /volume1/TV/Banshee/Season 02/Banshee.S02E10.SD.TV.Bullets and Tears.mp4
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Processing succeeded for /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4
2014-07-11 23:16:39 POSTPROCESS::SICKBEARD: Problem(s) during processing
2014-07-11 23:16:39 DEBUG   ::MAIN: Deleting torrent Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 from transmission
2014-07-11 23:16:44 INFO    ::CLEANDIR: Directory /volume1/downloads/torrent/tv/Banshee.S02E10.HDTV.x264-KILLERS.[VTV].mp4 has been processed and removed ...
2014-07-11 23:16:44 INFO    ::MAIN: The /volume1/downloads/nzbToMedia/TorrentToMedia.py script completed successfully.