Multiple Errors within Post Processing

[phybersplice]

Describe the bug Post Processing failure with nzbToMedia.py

Technical Specs

1. Running on (Windows, Linux, NAS Model etc) 'Synology 1821+ in a docker container'
2. Python version 'Python 3.9.5'
3. Download Client (NZBget, SABnbzd, Transmission) 'NZBGET'
4. Intended Media Management (Radarr, Sonarr) 'Radarr/Sonarr'

Expeted behavior Post processing seems to fail on everything that Radarr and Sonarr grab.

Log Please provide an extract, or full debug log that indicates the issue. The.Water.Horse.2007.MULTi.REMUX.1080p.Blu-ray.AVC.TrueHD.DTS-HD.MA.5.1-LEGi0N.log

[clinton-hall]

your /app/nzbget/scripts/nzbToMedia/autoProcessMedia.cfg is corrupt. Did you try editing this manually? if so, just delete it and do the config within NZBGet.

[phybersplice]

I believe I already tried that but I can try again. When I enter the config via NZBGET, do I need to do nzbToRadar + nzbToMedia as well or just nzbToMedia?

[clinton-hall]

You only need to configure the script that is called by NZBGet.

So you can set each category to call a specific script (nzbToRadar), particularly if you wan/need different settings for each category, oryou can set categories to call nzbToMedia all using common settings.

[phybersplice]

It's strange. After a fresh install of the docker image the scripts work. After the first instance of it running, the .cfg is created and it won't run properly the 2nd time.

[clinton-hall]

ok, sounds like something that is being written into the config uses a special character that causes the config file not to load? are you able to email me the generated .cfg file? fock_wulf@hotmail.com

[phybersplice]

I opened the .cfg file and checked the line numbers the errors were showing up. I noticed this:

[Lidarr]
    #### autoProcessing for Music
    #### LiCategory - category that gets called for post-processing with Lidarr
    [[music]]
        enabled = 0
        apikey = ""
        host = localhost
        port = 8686
        ###### ADVANCED USE - ONLY EDIT IF YOU KNOW WHAT YOU'RE DOING ######
        web_root = ""
        ssl = 0
        delete_failed = 0
        # Enable/Disable linking for Torrents
        Torrent_NoLink = 0
        keep_archive = 1
        extract = 1
        nzbExtractionBy = Downloader
        wait_for = 6
        # Set this to minimum required size to consider a media file valid (in MB)
        minSize = 0
        # Enable/Disable deleting ignored files (samples and invalid media files)
        delete_ignored = 0
        ##### Enable if NzbDrone is on a remote server for this category
        remote_path = 0
        ##### Set to path where download client places completed downloads locally for this category
        watch_dir = ""
    [[""]]
        host = ""
        apikey = ""
        port = ""
        ssl = 0
        web_root = ""
        delete_failed = 0
        wait_for = 6
        remote_path = 0
        enabled = 1

Notice the [[""]]. This happened 3 times in the file with the exact entries specifically where CP, Watcher and Lidarr are. I don't use those three programs - I'm using Radarr and Sonarr.

Also, whenever I make an adjustment to the config of nzbToMedia in NZBGET, the .cfg does NOT get updated to reflect the changes. Not sure exactly where to go from here.

/app/nzbget/scripts permissions are: drwxrwxr-x 1 abc abc /app/nzbget/scripts/nzbToMedia are: drwxrwxr-x 1 abc abc

root@DiskStation:/app/nzbget/scripts/nzbToMedia# ls -ltr
total 300
-rwxrwxr-x 1 abc abc  3849 May 16 09:10 tox.ini
drwxrwxr-x 1 abc abc   110 May 16 09:10 tests
-rwxrwxr-x 1 abc abc  3738 May 16 09:10 setup.py
-rwxrwxr-x 1 abc abc  7462 May 16 09:10 nzbToWatcher3.py
-rwxrwxr-x 1 abc abc  7580 May 16 09:10 nzbToSickBeard.py
-rwxrwxr-x 1 abc abc  7581 May 16 09:10 nzbToSiCKRAGE.py
-rwxrwxr-x 1 abc abc  7469 May 16 09:10 nzbToRadarr.py
-rwxrwxr-x 1 abc abc  7369 May 16 09:10 nzbToNzbDrone.py
-rwxrwxr-x 1 abc abc  3378 May 16 09:10 nzbToMylar.py
-rwxrwxr-x 1 abc abc 33003 May 16 09:10 nzbToMedia.py
-rwxrwxr-x 1 abc abc  6979 May 16 09:10 nzbToLidarr.py
-rwxrwxr-x 1 abc abc  3413 May 16 09:10 nzbToLazyLibrarian.py
-rwxrwxr-x 1 abc abc  3824 May 16 09:10 nzbToHeadPhones.py
-rwxrwxr-x 1 abc abc  2993 May 16 09:10 nzbToGamez.py
-rwxrwxr-x 1 abc abc  7699 May 16 09:10 nzbToCouchPotato.py
-rwxrwxr-x 1 abc abc 35127 May 16 09:10 license.txt
drwxrwxr-x 1 abc abc   320 May 16 09:10 libs
-rwxrwxr-x 1 abc abc   517 May 16 09:10 getffmpeg.sh
-rwxrwxr-x 1 abc abc  5475 May 16 09:10 eol.py
drwxrwxr-x 1 abc abc   334 May 16 09:10 core
-rwxrwxr-x 1 abc abc  6369 May 16 09:10 cleanup.py
-rwxrwxr-x 1 abc abc  1693 May 16 09:10 azure-pipelines.yml
-rwxrwxr-x 1 abc abc 25595 May 16 09:10 autoProcessMedia.cfg.spec
-rwxrwxr-x 1 abc abc    26 May 16 09:10 _config.yml
-rwxrwxr-x 1 abc abc 16974 May 16 09:10 TorrentToMedia.py
drwxr-xr-x 1 abc abc    28 May 16 09:41 logs
-rw-r--r-- 1 abc abc 26469 May 16 13:29 autoProcessMedia.cfg.old
-rw-r--r-- 1 abc abc 27166 May 16 13:29 autoProcessMedia.cfg
-rw-r--r-- 1 abc abc 16384 May 16 13:30 nzbtomedia.db

[clinton-hall]

ok. There are probably 2 ways to deal with this.

1. In NZBGet, nzbToMedia, set a (unique) category for each of those (CP, Watcher, Lidar) even though you don't use them... or
2. In NZBGet, set the Radarr Category to call nzbToRadarr.py and set the Sonarr Category to call nzbToNzbDrone.py and configure each of these scripts as appropriate.

[phybersplice]

Option 1 worked.

These messages don't seem new - but still come up every time.

INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: NzbDrone:tv Could not create a fork object for default. Probaly class not added yet.
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: NzbDrone:tv fork set to default
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: Attempting to verify tv fork
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: Calling NzbDrone:tv to post-process:This.Is.Us.S06E17.720p.WEB.H264-PLZPROPER
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: Auto-detected SECTION:NzbDrone
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: Script triggered from NZBGet Version 21.1.
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: #########################################################
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: ## ..::[nzbToMedia.py]::.. ##
INFO    Wed May 18 2022 05:21:07    nzbToMedia: [05:21:07] [INFO]::MAIN: #########################################################
INFO    Wed May 18 2022 05:21:06    nzbToMedia: [05:21:06] [INFO]::MAIN: nzbToMedia Version:27669389216902d1085660167e7bda0bd8527ecf Branch:master (Linux 4.4.180+)
INFO    Wed May 18 2022 05:21:06    nzbToMedia: [05:21:06] [INFO]::MAIN: No update needed
INFO    Wed May 18 2022 05:21:06    nzbToMedia: [05:21:06] [INFO]::MAIN: Checking if git needs an update
INFO    Wed May 18 2022 05:21:06    nzbToMedia: [05:21:06] [INFO]::MAIN: Checking database structure...
INFO    Wed May 18 2022 05:21:06    nzbToMedia: [05:21:06] [INFO]::MAIN: Python v3.9 will reach end of life in 1236 days.
INFO    Wed May 18 2022 05:21:03    nzbToMedia: warning: unable to access '/root/.config/git/ignore': Permission denied
INFO    Wed May 18 2022 05:21:02    Executing post-process-script nzbToMedia/nzbToMedia.py for This.Is.Us.S06E17.720p.WEB.H264-PLZPROPER

warning: unable to access '/root/.config/git/ignore': Permission denied was covered in this reported issue and does eliminate the error but I don't see that it's been fixed yet from a fresh GIT PULL.

Just remember, these logs are read from the bottom -> up. Not sure what's going on about the Fork error.

[clinton-hall]

The Fork error is simply stating that I haven't yet got around to creating a separate Class for that (A few of the Sick* forks have been converted to have their own class instead of a mass of if statements in the main code...)

Yes, the permission denied error is something I still need to look into. That issues you linked is still active and I need to get back onto that...

[phybersplice]

Otherwise, the scripts seem to be working properly again. I believe we can close this off.

Thanks for the help @clinton-hall.