Lidarr + Sabnzbd + nzbToMedia: Post Processing failiure.

[gibxxi]

As the title suggests, post-processing with the above fails. The message provided by nzbToMedia is as follows:

[02:14:17] [WARNING]::LIDARR: No scan id was returned due to: u'id' [02:14:17] [ERROR]::MAIN: A problem was reported in the /share/Download/nzbToMedia/nzbToLidarr.py script.

I can't post contents of my autoprocessmedia.cfg here, but be assured, the API key / credentials, paths, etc. are correct.

If nzbToMedia is disabled for the "music" category in sabnzbd (i.e: set the script to "none") Lidarr automatically picks up & processes the album anyway within 60 seconds of completion, so maybe nzbToMedia is redundant with regards Lidarr?

Dan / Gib.

[clinton-hall]

Yes, there are ways to work without this script. The original advantage of using the script is that the media management Apps (SickBeard and CouchPotato etc) didn't have to keep asking SAB for the status of the download (as this tended to slow things down on lower power processors etc).

To be honest, I can't recall what other advantages/features are supplied using the script for Lidarr, but I do know it was requested.

So, certainly having this disabled will still work, and doesn't bother me if the script is not needed. If you do want it running, I am certainly happy to try and get this fixed...

When the error happened, this error appears to be after the script asked Lidarr to rename, so it should have actually done the rename anyway. The error appears to be with trying to interpret the response that was received by Lidarr... So it would be worth checking the logs in Lidarr to see what they show at around 02:14:17.

Also, can I assume you are using Python3? the u'id' looks like it may be related to python3 interpreting/receiving the response as byte code and not a string...

[gibxxi]

Hi Clinton,

I was the one who made the request. At that time, I was unaware that Lidarr would be able to directly communicate with Sabnzbd, as I'd not long got it installed myself.

I have both python 2 and 3 installed I think. I've not removed 2.7 as yet for fear of it breaking some other python-based apps I have running, that i'm not entirely sure are python 3 aware. I may try pulling out 2.7 this weekend and see what happens.

I would say if it can be fixed, better to do that. Coverage for the other apps is present, and works well, so no reason Lidarr should be left out of the mix. You'll have quite a few people sending you messages as to the reason why it's not supported if it's dropped. Path of least resistance and all that.

I'll check the logs and see what I can find, but right now I have a different tech crisis to fix, so it may be a few days.

Dan / Gib.

[cwaddilove]

Hello, long time lurker, first time poster. Hoping I can add something useful.

I've been experiencing this near same issue for some time but coming up empty in my searches. My error is slightly different but ultimately looks the same, only happened to stumble across this while expanding my search.

Similarly I have nzbToMedia working for everything else just fine, would love to get it working for Lidarr. I am also similarly using python 2.7 & 3 (default 3). Can see Lidarr is receiving the actual exit code from nzbToMedia in the logs so I'm thinking connection / api are okay. Triple checked permissions and ran tests to confirm. The only real difference I can see is the lack of "u" in my error.

nzbtomedia.log 42-2019-12-17 21:01:23 DEBUG ::LIDARR: Opening URL: http://localhost:8083/api/v1/command with data: {"name": "Rename", "path": "/storage/Array1/sabnzbd/complete/Music/Boysetsfire-While A Nation Sleeps-CD-FLAC-2013-NBFLAC.1"} 43:2019-12-17 21:01:23 WARNING ::LIDARR: No scan id was returned due to: 'id'

Lidarr.txt 19-12-17 21:01:23.9|Info|Auth|Auth-Unauthorized ip 127.0.0.1 url 'http://localhost:8083/api/v1' 19-12-17 21:01:23.9|Fatal|LidarrErrorPipeline|Request Failed. POST /api/v1/command

Quite stumped at this point.

[clinton-hall]

are you able to change autoProcessMedia.cfg

[Lidarr]
    [[music]]
        host = 127.0.0.1

and see if that makes any change to either log?

[clinton-hall]

do you have reverse proxy enabled? https://github.com/lidarr/Lidarr/issues/837

[cwaddilove]

No reverse proxy enabled, I have Lidarr listening on * (default) similar to Radarr. I did change the default port on Lidarr, and the logs reflect that change successfully. This is a dedicated media server for LAN access only, firewalled off with a separate appliance. I don't have any other things running beyond Radarr, Lidarr, Medusa, SabNZBD, rtorrent, apache2 for rutorrent, and basic linux services. I have Radarr set to localhost and Medusa <~> SickBeard set to localhost (not using Sonarr yet). They're both working just fine.

Default host for me was "localhost"

Tried changing to "127.0.0.1" - Same thing ultimately [22:36:51] [DEBUG]::LIDARR: Opening URL: http://127.0.0.1:8083/api/v1/command with data: {"name": "Rename", "path": "/storage/Array1/sabnzbd/complete/Music/Boysetsfire-The Misery Index Notes From The Plague Years-CD-FLAC-2006-FATHEAD.1"} [22:36:51] [WARNING]::LIDARR: No scan id was returned due to: 'id' 7004:19-12-19 22:36:51.3|Info|Auth|Auth-Unauthorized ip 127.0.0.1 url 'http://127.0.0.1:8083/api/v1' 7005-19-12-19 22:36:51.3|Fatal|LidarrErrorPipeline|Request Failed. POST /api/v1/command

Tried changing to "192.168.0.3" (LAN IP) - Ditto [22:40:47] [DEBUG]::LIDARR: Opening URL: http://192.168.0.3:8083/api/v1/command with data: {"name": "Rename", "path": "/storage/Array1/sabnzbd/complete/Music/Boysetsfire-The Misery Index Notes From The Plague Years-CD-FLAC-2006-FATHEAD.2"} [22:40:47] [WARNING]::LIDARR: No scan id was returned due to: 'id' 7025:19-12-19 22:40:47.3|Info|Auth|Auth-Unauthorized ip 192.168.0.3 url 'http://192.168.0.3:8083/api/v1' 7026-19-12-19 22:40:47.3|Fatal|LidarrErrorPipeline|Request Failed. POST /api/v1/command

Tried changing listen in Lidarr from * to 192.168.0.3 - [22:45:41] [DEBUG]::LIDARR: Opening URL: http://192.168.0.3:8083/api/v1/command with data: {"name": "Rename", "path": "/storage/Array1/sabnzbd/complete/Music/Boysetsfire-The Misery Index Notes From The Plague Years-CD-FLAC-2006-FATHEAD.3"} [22:45:42] [WARNING]::LIDARR: No scan id was returned due to: 'id' 7060:19-12-19 22:45:41.9|Info|Auth|Auth-Unauthorized ip 192.168.0.3 url 'http://192.168.0.3:8083/api/v1' 7061-19-12-19 22:45:42.0|Fatal|LidarrErrorPipeline|Request Failed. POST /api/v1/command

[FrancisHG]

Same +

[didyouexpectthat]

Hi there. Came across this problem today as I just restarted using Lidarr. I'm using Lidarr + nzbget + nzbToMedia + haproxy + lxc. I get the unauthorized IP from Lidarr regardless of whether I ask nzbToMedia to go through haproxy or using the direct IP address of Lidarr (all things run independently in lxc containers). I asked Lidarr to search for a specific album, it send it correctly to nzbget. Here are some additional things from my setup. I have no similar/observable issue with Sonarr or Radarr.

Debian 10 Python 3.7.3

ERROR   Sun May 24 2020 18:37:56    Post-process-script nzbToMedia/nzbToMedia.py for $artistalbumflacyear failed
INFO    Sun May 24 2020 18:37:56    nzbToMedia: Lidarr: Failed to post-process - Unable to start scan!
INFO    Sun May 24 2020 18:37:56    nzbToMedia: -- Cleanup finished --
INFO    Sun May 24 2020 18:37:56    nzbToMedia: Returning to directory: /
INFO    Sun May 24 2020 18:37:56    nzbToMedia: No folders to clean
INFO    Sun May 24 2020 18:37:56    nzbToMedia: -- Cleaning folders: ['libs', 'core'] --
INFO    Sun May 24 2020 18:37:56    nzbToMedia: b'Removing __pycache__/\n'
INFO    Sun May 24 2020 18:37:56    nzbToMedia: b'Removing __pycache__/\n'
INFO    Sun May 24 2020 18:37:56    nzbToMedia: -- Cleaning bytecode --
INFO    Sun May 24 2020 18:37:56    nzbToMedia: Changing to directory: /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:56    nzbToMedia: [18:37:56] [ERROR]::MAIN: A problem was reported in the /opt/nzbget/scripts/nzbToMedia/nzbToMedia.py script.
INFO    Sun May 24 2020 18:37:56    nzbToMedia: [18:37:56] [WARNING]::LIDARR: No scan id was returned due to: 'id'
INFO    Sun May 24 2020 18:37:56    nzbToMedia: [18:37:56] [DEBUG]::LIDARR: Opening URL: http://172.31.5.248:80/api/v1/command with data: {"name": "Rename", "path": "/downloads/lidarr/$artistalbumflacyear"}
INFO    Sun May 24 2020 18:37:56    nzbToMedia: [18:37:56] [DEBUG]::LIDARR: path: /downloads/lidarr/$artistalbumflacyear
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::SERVER: Server responded at http://172.31.5.248:80/api/v1
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::SERVER: Attempting to connect to server at http://172.31.5.248:80/api/v1
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: Calling Lidarr:lidarr to post-process:$artistalbumflacyear
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: Auto-detected SECTION:Lidarr
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Adding NZB download info for directory /downloads/lidarr/$artistalbumflacyear to database
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: Script triggered from NZBGet Version 21.0.
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Options passed into nzbToMedia: ['/opt/nzbget/scripts/nzbToMedia/nzbToMedia.py']
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: #########################################################
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: ## ..::[nzbToMedia.py]::.. ##
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: #########################################################
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: nzbToMedia Version:f5e4ec0981ab2f6fd97b14b24aa363a393396073 Branch:master (Linux 5.3.18-3-pve)
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: No update needed
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: cur_commit = f5e4ec0981ab2f6fd97b14b24aa363a393396073 % (newest_commit)= f5e4ec0981ab2f6fd97b14b24aa363a393396073, num_commits_behind = 0, num_commits_ahead = 0
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: "/usr/bin/git" rev-list --left-right '@{upstream}'...HEAD : returned successful
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Executing "/usr/bin/git" rev-list --left-right '@{upstream}'...HEAD with your shell in /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: "/usr/bin/git" rev-parse --verify --quiet '@{upstream}' : returned successful
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Executing "/usr/bin/git" rev-parse --verify --quiet '@{upstream}' with your shell in /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: "/usr/bin/git" fetch origin : returned successful
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Executing "/usr/bin/git" fetch origin with your shell in /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: "/usr/bin/git" rev-parse HEAD : returned successful
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Executing "/usr/bin/git" rev-parse HEAD with your shell in /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: Checking if git needs an update
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: "/usr/bin/git" symbolic-ref -q HEAD : returned successful
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Executing "/usr/bin/git" symbolic-ref -q HEAD with your shell in /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Using: "/usr/bin/git"
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: "/usr/bin/git" version : returned successful
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Executing "/usr/bin/git" version with your shell in /opt/nzbget/scripts/nzbToMedia
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Checking if we can use git commands: "/usr/bin/git" version
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: InitialSchema upgrade not required
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [DEBUG]::MAIN: Checking Initial Schema database upgrade
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: Checking database structure...
INFO    Sun May 24 2020 18:37:55    nzbToMedia: [18:37:55] [INFO]::MAIN: Python v3.7 will reach end of life in 1129 days.

lidarr mono[114]: [Info] Auth: Auth-Unauthorized ip 172.31.5.243 url 'http://172.31.5.248/api/v1'
lidarr mono[114]: [Fatal] LidarrErrorPipeline: Request Failed. POST /api/v1/command
lidarr mono[114]: [v0.7.1.1381] System.InvalidOperationException: Sequence contains no matching element
lidarr mono[114]:   at System.Linq.Enumerable.Single[TSource] (System.Collections.Generic.IEnumerable`1[T] source, System.Func`2[T,TResult] predicate) [0x00091] in <13c0993ff82548209b09f271bd5e6a78>:0
lidarr mono[114]:   at Lidarr.Api.V1.Commands.CommandModule.StartCommand (Lidarr.Api.V1.Commands.CommandResource commandResource) [0x00022] in <2883fe04aa0a46f687bad43f547ee0c6>:0
lidarr mono[114]:   at Lidarr.Http.REST.RestModule`1[TResource].<set_CreateResource>b__42_0 (System.Object options) [0x0000d] in <26a7215ffa4844618987ce6727897136>:0
lidarr mono[114]:   at (wrapper dynamic-method) System.Object.CallSite.Target(System.Runtime.CompilerServices.Closure,System.Runtime.CompilerServices.CallSite,System.Func`2<object, object>,object)
lidarr mono[114]:   at Nancy.Routing.Route+<>c__DisplayClass4.<Wrap>b__3 (System.Object parameters, System.Threading.CancellationToken context) [0x00049] in <bb3027f50b35411088f45475912cc2ff>:0

[didyouexpectthat]

https://github.com/clinton-hall/nzbToMedia/blob/5a6837759d90285664b3cb596662adb5bfbcb2a2/core/auto_process/music.py#L115 From Lidarr's API documentation on /api/v1/command, I can't find any command called Rename. Just RenameFiles and RenameArtist

RenameFiles
Instruct Lidarr to rename the list of files provided

Parameters
files (int[]) List of File IDs to rename

Where does the command Rename come from? I can reproduce the same call in Postman when using Rename or any other made-up value .

[clinton-hall]

ah... #1404

it looks like way back in 2018 I added this (on request) based on Sonarr/Radarr and noted that rename was not a command in the api at that time and suggested this needed to be requeted from Lidarr.

Since then I believe I had received confirmation that it was working, and I merged it... but that must have been a false report.

Basically, there is no methodology I can see to ask Lidarr to rename files from a directory. So basically you would need to use Lidarr to scan the download directory and not use this script.

Or, you can ask Lidarr to see if this is something they would be willing to support, or if they can suggest any way of interfacing to call the rename.

[didyouexpectthat]

Thanks for your time to review and confirm, @clinton-hall. I'll open a request with Lidarr if one isn't already open to see if they can support something like Rename. Would it be good to remove support for Lidarr until Lidarr can support this type of request?

[gibxxi]

With regards Lidarr and Sabnzbd, Lidarr has no need of this script (I can't comment on interaction between Lidarr and Nzbget as I don't use it). Lidarr is able to actively watch Sabnzbd's progress (or so it seems), and automatically post-processes anything it's sent to Sabnzbd once downloading completes. There is a bit of a delay, before this occurs, but it does post-process all downloads assuming category folders are used, as I have mine setup.

I don't know if this has always been the case, but as it stands, Lidarr and sabnzbd work fine without this script needing to act as a middleman in my experience.

[clinton-hall]

so a few comments:

1. I need to clearly show that (until such time as this is supported by Lidarr, if at all) this script is NOT compatible with Lidarr.

2. Lidarr is fully able to post-process albums/songs downloaded by SABnzbd and NZBGet. I believe the same is true for some/most Torrents. So this script is not REQUIRED.

3. The benefits of this script (perhaps somewhat historical) if it is to be made compatible: Not requiring Lidarr to keep "asking" the downloader when it has finished. For smaller CPU systems (ARM NAS etc) this extra overhead when downloading a large queue can bog the whole system down. (Probably not a huge issue on a full/modern architecture. Also more of an issue with TV/Movie downloads. Some extra extraction (that isn't supported by some torrent downloaders) Some extra safety checks - ensure the file is valid/playable (again probably more of an issue with video files)

If none of those are issues for your music downloading then no need to worry about this script... If however those are issues and Lidarr are able to provide a rename command (or similar) via api, I can make this compatible quite easily.

[gibxxi]

Hi Clinton,

While I personally don't have any need for compatibility between Sabnzbd, Lidarr and nzbToMedia (at this time), I expect there will be others who would welcome such changes.

As the previous poster (didyouexpectthat) commented, the post-processing aspect of nzbToMedia doesn't work with Lidarr, and given that (unlike Sonarr & Radarr) we will always be dealing with multiple files, I doubt very much a "Global Rename" function will be forthcoming, just for the purposes of compatibility with nzbToMedia, but I wait to be proven wrong on that score.

I would keep an eye on the progress of it (Lidarr) and add what support you can, as & when possible, but highlighting what does (and what doesn't) work. Anyone using Sonarr or Radarr, will more than likely also be using nzbToMedia, and Lidarr, so it makes sense to me, to support what can be supported, and expand on that, as Lidarr matures.

FWIW, I was the one who made the initial support request in 2018 Clinton, but at that time, I simply assumed that it would work identically to Sonarr & Radarr, and thus require nzbToMedia for post-processing to work. I've since realised this isn't strictly the case, but forgot to relay this fact back here, so apologies for that.

[mautobu]

Was this ever address? I started a new library with a fresh Lidarr instance and successfully downloaded ~300 GB of (royalty free) music, but after that it stopped processing with this error:

LIDARR: No scan id was returned due to: 'id'

Trying to figure out if it stopped working when I pulled a new version of nzbtomedia, or the db just got too big and is locking near constantly.

[gibxxi]

You don't really need this script for the *arr apps any more. They will automatically monitor chosen download / category folders for content (as downloaded by SABnzbd) and process them automatically, without the need for 'bridge' scripts. This obviously assumes you have Lidarr / Sonarr / Radarr set up correctly in the first place.

[mautobu]

Yup, ended up on the lidarr Discord. They advised me to disable the script and everything just started working. Thanks.

On Tue, Mar 22, 2022 at 10:42 AM Dan Morgan @.***> wrote:

You don't really need this script for the *arr apps any more. They will automatically monitor chosen download / category folders for content (as downloaded by SABnzbd) and process them automatically, without the need for 'bridge' scripts. This obviously assumes you have Lidarr / Sonarr / Radarr set up correctly in the first place.

— Reply to this email directly, view it on GitHub https://github.com/clinton-hall/nzbToMedia/issues/1655#issuecomment-1075435618, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJUY5V3S5CNGRTES225FBGTVBIBBPANCNFSM4IY4OWXA . You are receiving this because you commented.Message ID: @.***>

--

Justin Engwer