Can't mix strings and bytes in path components >> Python 3.5.6 on Synology #1671
Comments
clinton-hall
added a commit
that referenced
this issue
Nov 12, 2019
|
Can you update to Looks like not too many people have been testing the manual processing with Python3 |
|
This worked well, thanks very much Clinton. |
4 tasks
clinton-hall
added a commit
that referenced
this issue
Nov 13, 2019
|
Ok, I have merged that into nightly. If you switch to nightly, you'll get further updates. I hope to merge everything up to master and do a new release soon. |
|
Although I had previously tested using [[tv]] & Sickchill, Is there a chance this could also be occurring with a manual run of TorrentToMedia.py for [[movie]] using Radarr? |
|
where was the error logged? This error is different to the OP, but never the less I would like to fix this. I just need to know where the error is ocuring. |
|
There's no error being logged here unfortunately. |
|
@MrCee |
|
As a warning in the log..... It causes the script to hang for 5 minutes with the message .... followed by: |
clinton-hall
added a commit
that referenced
this issue
Dec 3, 2019
|
Can you switch to |
|
@clinton-hall This has worked, but only when Radarr in autoconfig.cfg is set to 'Copy' It might be good to note now that MYMOVIEFILE.mkv gets copied to a newly created directory e.g. When Radarr in autoconfig.cfg is set to 'Move', the files are not moved to the final library destination. |
|
Do you have logs to show the behavior for both move and copy? Please also check autoProcesMedia.cfg if this value is set to copy, that will over-ride, or conflict, with the setting in Radarr. Also, when set to move, check the Radarr logs at the time of postprocessing to see if there are any errors reported in Radarr. I suspect from what you are describing, the script handles these the same... to remove the |
|
I managed to get Move & Copy both working by checking Radarr logs thank you. The This isn't a current issue with SickChill or when I had previously used CouchPotato for Torrents. I have since carefully gone through the Radarr config to minimise potential conflicts and I am not setting permissions in Radarr. I do have final files all moved to the final destination on the same volume, but just can't seem get rid of the original file which is not contained in any folder and don't really understand the I have really tried not to miss anything here. I'll keep my config as is for the time being just incase there is something I have overlooked. This is the result when This is the result when One last example I have for you. RADARR LOG nzbtomedia.log |
|
ok, the whole copylink thing shows that teh files are linked into their own unique (temp/staging) directory. The annoyance is that because you are doing a "manual" run (Downlaod station not fully supported) this does do the linking twice (but second time skips because it finds that the directory already exists). I will see if I can tidy this up, but it isn't actually a problem, just additional over-head in checking the file structure and logging. So from what I'm seeing everything is working except for the deletion of the original torrent . With this I note that the copyLink section is actually doing a which should move the files (not hard-link) and therefore all cleanup should work fine... BUT... So this all comes down to the need to receive details from Downlaod Station. if this does now work, then that should fix all issues. |
clinton-hall
added a commit
that referenced
this issue
Dec 7, 2019
|
Thanks Clinton. I believe that Synology's 'Download Station' is at the 90% mark of being supported, but it would require changes to your script, so I'm happy if anyone else with Synology DSM & python skills can go though the wiki as I'll bring this up to date as much as possible. |
|
Sorry about that. To be honest I didn't pay attention to who updated that... I just had a vague memory of it having been tested. If 90% there, what isn't working? |
|
Ok, read your edits. |
clinton-hall
added a commit
that referenced
this issue
Dec 10, 2019
|
I just added a new this is currently in based on guidance at https://forum.synology.com/enu/viewtopic.php?f=10&t=88918 and https://forum.synology.com/enu/viewtopic.php?f=38&t=92856 I am hoping this will make this work for you.... if it does, I'll merge up to nightly and eventually master... and you can add some more to the wiki :) |
|
@clinton-hall On the exact moment of completion, the file is moved from the Synology temp directory + system generated number As you can see below, TorrentToMedia.py is grabbing the original environment temp location which does not contain tv or movie in the path, and at this stage (I believe before or at the same time the script runs), the file has already been moved. So as Sickchill / CouchPotato / Radarr are able to specify the completed downloaded location and parse that to Download Station so the file can be post processed, in this case my SickChill setting is e.g. |
|
ok... so this SHOULD use the synology api the problem here is that I have no way of testing, so it is completely theoretical, and assumes that the also, here nzbToMedia/core/utils/parsers.py Lines 91 to 92 in a8d7f85 I am assuming that this is the correct syntax to parse the results returned from the api... again no way of testing. To enable this, update the latest SynoDS-patch-1 branch and set this is based on https://github.com/N4S4/synology-api with reference to https://global.download.synology.com/download/Document/Software/DeveloperGuide/Package/DownloadStation/All/enu/Synology_Download_Station_Web_API.pdf |
|
Making progress, I believe I get a connection to Download Station using Although it switches to manual run mode, I probably require help debugging |
|
ok, I just made a small change to remove a "try". can you update, try again, and post the error? |
|
Here's the log: |
clinton-hall
added a commit
that referenced
this issue
Dec 23, 2019
|
I'm so sorry for all this... I checked again against the syno api docs and the example results they provide work for me.... so I am assuming their documentation is incorrect (changed version) and therefore I can only do this by printing the return code to the log... I have done this now, so if you update to latest and run, the log should show the data returned by syno.... this should then allow us to determine how this needs to be parsed to get the directory. |
|
@clinton-hall It's no problem at all. All good. Here's the manual run result: Here's the Synology Download Station triggered result: |
clinton-hall
added a commit
that referenced
this issue
Dec 23, 2019
|
The main issues here are: So now we need to find a way to get the correct download id!!! so, what I am now doing is listing ALL downloads, and trying to match the download where the title matches the download name. This should then return the download id and the download destination... try updating and run again (from DS)... Unless the title and torrent names are different, surely this has to be close now! |
|
This is almost there! So with this environment being set: We can now see the ID for the first time...... |
|
@clinton-hall |
|
interesting.... so the script does indeed find the correct torrent details, and stop the torrent. I could just make the conversion from TR_TORRENT_ID to id by appending the issue is we get the directory do you know if there is a way I can confirm where this is relative to? i.e. is there a default symlink I could just hard-code /volume1 to make it |
clinton-hall
added a commit
that referenced
this issue
Dec 24, 2019
|
ok, I have added a test to see if the path exists in case DS can be configured with absolute paths for categories.... which if possible would be my recommendation. e.g. instead of Sonarr category having destination If the path doesn't exist, this will then add This change I think should get things working for you. If there is a better way to handle the relative paths, please let me know. |
|
I was thinking that appending Re: relative directories... I had a search around Synology NAS trying to find a way to determine the path of the relative directories, and tried to look at how SickChill does this, but always keep coming back to this.... Anyone else using TorrentToMedia.py would set this in autoProcessMedia.cfg in case of a manual run.... (usually?)..... Here is the log from an updated TorrentToMedia.py triggered by Synology Download Station completing the download: |
|
great news, glad to hear it worked. this should work for most syno configs unless people have really customized things, however I'm still keen to tidy up a few things here: |
|
@clinton-hall I thought I could quickly test a manual run with many other items in the queue that are not complete, and there are no issues with that either. Vikings was post-processed manually. |
|
re: outputDirectory = /volume1/downloads/ This is the directory that is set in nzbToMedia to "stage" the downloads to be processed by SickChill etc... this is not the directory that Syno DS downloads to (although in your case this is the same). Usually the files are either sym-linked, hard-linked, copied, moved, (or in the case or zip/rar... extracted) FROM the synology DS (or downloader location) TO the outputDirectory... because your Syno DS destination is the same as outputDirectory you get I do note the 1 error you got orriginally The main reason for flattening (from memory) is to bring all sub-foldered videos up to top level so sickbeard could see them all (processing an entire season directory etc). I am not even sure if this is still required for more modern variants. The other error, in your last run, |
|
Just going through some detail, there maybe something useful here... In Synology Download Station GUI we can select a "Temporary Location" pick list e.g. "Volume 1", "Volume 2", "Volume3". Only the volume. There is also a "Default Destination Folder" which is a catch all for manually added files and in the GUI it could be any shared folder no matter which volume. In the GUI my folder is set to If SickChill/Radarr/CouchPotato/others add a torrent to Download Station, the "Default Destination Folder" is overwritten by the location specified in the client. e.g. SickChill overwrites the default location and it is shown against the file in the Synology Download Station GUI as RE: |
clinton-hall
added a commit
that referenced
this issue
Jan 4, 2020
|
ok, if you could check again... this should make manual processing a lot cleaner. I have also limited this to search by dbid_Toreent-id and I have alos checked for relative paths in volume1 to volume4 (from what I read, these must be shares which sit on a volume... and 4 should be enough for most users). |
clinton-hall
added a commit
that referenced
this issue
Jan 13, 2020
* Add Syno DS parsing #1671 as per https://forum.synology.com/enu/viewtopic.php?f=38&t=92856 * add config guidance * add syno client
|
Hi Clinton, So should I now be testing this on nightly? I'm currently stuck at this on nightly... |
|
Sorry that was a silly error on my part when I went back to using download ID. Can you test again? This will hopefully do what you want. |
clinton-hall
added a commit
that referenced
this issue
Jan 21, 2020
|
Unfortunately it's still the same... |
|
nope... that's different... we didn't get returned data from Syno this time... |
|
@clinton-hall Not sure what I did last, recently re-installed DSM. Just for your notes, I'm still working on a solution regarding altered Apparmor profile loaded at start-up, as it seems that Synology use a pre-complied profile at start-up which doesn't include the additional permissions we require for Wiki has been updated. |
|
great news... I was just looking over the code and couldn't see what was going wrong... so good to see it is working and I'm not loosing the plot! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Processing stops due to message in the logs 'Can't mix strings and bytes in path components'
Technical Specs
Expected behavior
Since linking python to 3.5.6 on Synology DS415play, TorrentToMedia.py has started throwing 'Can't mix strings and bytes in path components' error. I tested the script after changing the python version to the new location a few days ago, everything was working fine for a while. Now processing has stopped.
I use TorrentToMedia.py on a scheduled task every 30 minutes.
Log
The text was updated successfully, but these errors were encountered: