-
Notifications
You must be signed in to change notification settings - Fork 176
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TorrentToMedia with Synology - Using temp download directory - not recognising sickrage paths #925
Comments
I don't understand why Synology does this So you actually have everything downloaded to this is the folder that Download Station is telling TorrentToMedia to check... Where do you expect TorrentToMedia should check, and what files should it find there? |
In the JSON settings we have....
This "incomplete-dir" is a hidden temporary download directory and the JSON settings cannot be changed to false, they are overwritten and revert back to the settings above. The files are moved/linked to the directory specified in Sickrage and only become visible on completion....
If there was a way TorrentToMedia.py could use the newest link location specified in Sickrage (which is passed to Download Station) and not the original "incomplete-dir" which stores the files for seeding (even if seeding is disabled) this would possibly fix the issue. Note: Files are deleted from One other thing I have needed to do is when specifying paths in Sickrage >> Torrent Search >> Download File Location, the path needs to be:
The reason for this is if you specify the full path, when you right click the torrent in Download Station and 'Open Folder Containing'..... Download Station GUI cannot find the file as it appends it's own /volume1/ to the path the file has been moved/linked to. Any path in auto process.config would need the absolute path i.e. |
The only way to achieve this is to set autoProcessMedia.cfg
then run the script manually and not called from Download Station. |
Thanks for getting back Clinton. Much appreciated. I've tried this all again with a fresh install of Sickrage (new branch) and I am back to the latest version of Download Station. (Previously I have tried going back to older versions of Download Station app and TorrentToMedia.py scripts as we used to have this working). I can confirm that the Sickrage path is definitly specifided as the final destination for the files. Furthermore, on new versions of Download Station, the I still think there has to be a way for TorrentToMedia.py to pick up the path listed in the GUI which is provided by Sickrage and act on this path. I'll keep trying from my end. |
this is where TorrentToMedia gets the directory |
That makes sense of things, I am sure you are correct with this. Thank you. I had even played around with timing before the script kicked in to no avail. I'll be raising the with Synology. I appreciate your help. I'll update the wiki with any new info I receive. |
A manual run of the script is not working either. I do have watch folders set up. This was working a month or so ago on a manual run. The manual run script would look at the sickrage.db and figure out where to store the final result files which had been renamed. TorrentToMedia.py would at least work with the directories specified in sick rage. I don't believe this is happening now? I have tried changing many options such as Torrent_NoLink = 0 to 1 and dealing with output folders to be appended by the script. My main question is.... on a manual run of TorrentToMedia.py, should the script pick up the final destination listed in sickrage and move the files to this location. I did have this working not so long ago.
As far as I'm aware, this script used to pick up on the final download destination when it is run manually and use the sickrage renamer... which it is not. In the past on a manual run, all of my files were renamed and moved to a final destination folder as specified in sickrage being e.g. "/volume1/video/TV Shows/12 Monkeys (2015)" as specified in sickrage >> edit show >> main settings >> show location. Much appreciated if you have some further questions or input. P.S. Ticket raised with Synology regarding the /var/services/download/xxxx/DOWNLOAD_TR_TMP_DIR |
As per the above post, here is another example from a manual run:
|
So it appears this has just re-processed the files that had already been processed? As per your questions, this script does not get any information from SickRage settings... This script tells SickRage to process files according to the SickRage settings. The main issue is that the script needs to be told what files to process. |
Thanks for getting back to me. For now I'll focus on a manual run (while I wait for Synology to get back to me) Any chance you could please help with the following?...
I did have chmodDirectory = 1 set in autoprocess.config, now I have set this to chmodDirectory = 0 and now the renamer can be called, and the files can be moved to the intended final destination folder "TV Shows" as listed in sickrage. Question: what is chmodDirectory = 1 for? Is it working correctly? Is it needed for the issue below? Furthermore, if a torrent is downloaded without a folder, e.g. The folder is created with these permissions: NOTE: all of my downloading apps and downloaded files are apart of the sc-media group which works really well in Synology. TorrentToMedia.py LOG:
|
As per the above, in summary, this is what happens to permissions when TorrentToMedia.py chmodDirectory = 1
This file is contained within the Monkeys directory... This is what happens to permissions when TorrentToMedia.py chmodDirectory = 0, after resetting everything back to chmod 777
The file contained within the Monkeys directory... Yet the file is locked. Note: I did have an MKV version in the db earlier: I was seeing this in the log when chmodDirectory = 1:
When chmodDirectory = 0, I get the File is locked for reading/writing error. Here's the last part of the TorrentToMedia.py log.....
|
If I chmod 777 the Monkeys directory manually (which the script created) and have autoprocess.confg set to chmodDirectory = 0 , everything works correctly....
|
I have found a part of the problem..... If autoProcessMedia.cfg is set up with the following the script will fail because the Monkeys directory is not created with WRITE permissions on chmodDirectory = 0 (Note: chmodDirectory = 1 strips all permissions to nothing):
If autoProcessMedia.cfg is set up with chmodDirectory = 0 and the following the script will go ahead:
The last problem that remains is that the script does not clean up/delete the original file which was picked up before the 'Monkeys' directory was created.
This leaves us with
All options to cleanup / delete original are set to 1
|
The reason it can't delete (move) the original files is that the files are still seeding. When called from Transmission/DS the script pauses the torrent (releases the file lock) and then does it's thing. At the end, it can resume seeding or delete the torrent (option deleteOriginal). |
Thanks Clinton. I'm sure chmodDirectory = 1 is having undesired results and removing all permissions regardless of seeding. There is definitely a problem with chmodDirectory = 1 at my end. Permissions should not be stripped and affected this way. chmodDirectory = 1 is removing all permissions except for EXECUTE. It cannot be used at all on a manual run. Q. What is the purpose of chmodDirectory = 1 if it removes all permissions from the folder (and original file) to be processed? e.g.
I'd really like to nut this one out and appreciate your input. |
Chmod needs to be set to a valid chmod E.g.
|
AHA! Thank you! (embarrassed that I missed this as I thought it was a 0 or 1 toggle) Note: The default is chmodDirectory = 0 in autoProcessMedia.cfg.spec. I'll update further wiki(s) shortly. P.S... Synology support have responded and are looking in to the DOWNLOAD_TR_TMP_DIR and I am hoping this can be adjusted on the next version update of Download Station. |
Good news... So setting 0 does "toggle this feature off" but a non-zero setting needs to be a valid chmod. Let me know what Syno does. I can browse another environment variable if there is one for the correct path etc... |
@clinton-hall What do you think of including a work around something like the following..... If TR_TORRENT_DIR contains DOWNLOAD_TR_TMP_DIR then match the download ID with the correct location which can be derived from this query.
Note: The other ENVIRONMENT VARIABLES are correct...
Cheers! |
Fixed in #1671 |
Hi All,
I've updated the Download Station wiki to enable scripts to run on Synology Download Station after the DSM 5.1 AppArmor inclusion. This worked for myself for sometime, but now I'm seeing some issues where TorrentToMedia.py picks up on the original DOWNLOAD_TR_TMP_DIR instead of the directory the downloaded files are supposed to be used for post processing.
Download Station will download partial downloads to DOWNLOAD_TR_TMP_DIR. Once complete, the DOWNLOAD_TR_TMP_DIR would normally be used for seeding until files are removed from Download Station. My saved destination for post processing torrents would be /volume1/downloads/process/tv. They are linked to the same file, but the script will always pick up on the DOWNLOAD_TR_TMP_DIR first and class this as UNCAT.
I have seen other users having the same problem here >>>
https://sickrage.tv/forums/forum/help-support/nzbtomedia-support/30815-torrenttomedia-with-synology-using-temp-download-directory
Im using sickrage and not sickragetv.... yet we (other user posting the same issue) are both on Synology NAS. Note: Download Station forces us to use the DOWNLOAD_TR_TMP_DIR. The path is listed in settings.json "incomplete-dir": "/var/services/download", >>> This points to /volume1/@Download.
Is there anyway you can get the TorrentToMedia.py to recognise the chosen downloaded directory and not the DOWNLOAD_TR_TMP_DIR?
I went back to an old commit just to see if it would work again, no luck.
The text was updated successfully, but these errors were encountered: