nzbToCouchpotato reports failure when status was already success.

[juniorz]

For some reason, the processing had succeeded in couchpotato but was reported as a failure to nzbget. My default behavior is to re-trigger the post-processing from nzbget.

nzbToMedia logs tell me:

2017-02-11 21:25:42 POSTPROCESS::COUCHPOTATO: Checking for status change, please stand by ...
2017-02-11 21:25:42 DEBUG   ::MAIN: Opening URL: http://localhost:5050/api/82598af25cab4bdba364bc4dc9250ade/media.get with PARAMS: {'id': u'8bd736c53a274f229f7993ed3d79075e'}
2017-02-11 21:26:02 WARNING ::COUCHPOTATO: **** does not appear to have changed status after 2 minutes, Please check your logs.

The url mentioned returns "success": true, but if you look at core/autoProcess/autoProcessMovie.py (line 333) the script expects a status change.

Why does not it expect the status to be success (rather than a change)?

[clinton-hall]

this api call asks for the status of the movie (status = snatched, downloaded, available, wanted, done etc)

The general expectation is that the initial status should be either snatched or wantedm but after renaming the status should be done. this is how we know the renaming has been completed.

The "success":true is the result of the api call to get the status.

The reason this is done this way is to prevent accidental deleting of files that have nor been renamed (or not yet finished renaming).

Basically, to be in the situation where status doesn't change, I suspect the following:

1. The movie was not in CP wanted list, and was manually snatched.
2. The movie was already done, but you snatched another release manually.
3. The renamer had an error, and did not complete.
4. There is dome other issue with CP database or movie name matching.

So, can you post full renamer logs and confirm if this movie was snatched from CouchPotato, and if the movie was already "done" in couchpotato? Does this happen for every movie, or was this a once off?

Other than reporting "failure" are there any other issues?

[qorron]

I think I can add to this: I just pulled the git repo since it was very old and then I experienced the same issue. every media processor (pochpotato & sickgear) is set to hardlink the files instead of moving them. hence the downloaded file never changes. I experience the same imdb fail

[09:26:36] [INFO]::MAIN: Calling CouchPotato:movie to post-process ...
[09:26:36] [INFO]::MAIN: Attemping imdbID lookup for ...
[09:26:36] [INFO]::MAIN: Searching folder and file names for imdbID ...
[09:26:36] [INFO]::MAIN: Searching IMDB for imdbID ...
[09:26:36] [INFO]::MAIN: Unable to determine imdbID: No api key provided for omdbapi.com.

meanwhile CP is happy:

[09:26:42] [POSTPROCESS]::COUCHPOTATO: SUCCESS: Finished renamer scan for folder /data/storage/Media/...

then the filter for CP has nothing and the status change never happens

[14:20:54] [POSTPROCESS]::COUCHPOTATO: Checking for status change, please stand by ...
[14:20:54] [DEBUG]::MAIN: No information available to filter CP results
[14:21:14] [POSTPROCESS]::COUCHPOTATO: Checking for status change, please stand by ...
[14:21:14] [DEBUG]::MAIN: No information available to filter CP results

perhaps.. nzbToMedia could just be happy with the reported success and not try extra stuff?

this test case was of a file I sent to sabnzbd via the nntp indexer, so it was not pushed by couchpotato

[clinton-hall]

The main issue I see is that [09:26:42] [POSTPROCESS]::COUCHPOTATO: SUCCESS: Finished renamer scan for folder /data/storage/Media/... simply means the Renamer PROCESS started, and doesn't confirm that in-fact the movie was renamed (or indeed identified). Hence the additional checks to see if the status changed and or files moved (when using move).

Potentially there is a risk of reporting a movie as Successful when in fact it was not renamed...

[qorron]

yes.. the risk is only potential and sabnzbd should not care anyway if CP does its job or not. on the other hand, as it is now it wrongfully reports a failure in every case if one uses hardlinks. I want to keep hardlinks becuse sometimes the media processors screw up things and replace a good file with a bad one in that case I have a backup. and who can say no to a backup that only needs space once it is needed and not one second earlier.

I'd really appreciate if that check could be turned off via a config switch. (or a working solution for hardlinks as I do want to keep them) for me its enough if the media processors report a failure. sabnzbd is for downloading, verifying, repairing and unpacking (and finally telling the MP: "hey, here is work for you!"). it only should report a failure if one of its own steps fail.

edit: it also happens if movie downloads are triggered from CP. so for me it reports every movie as failed.

[clinton-hall]

Try latest nightly branch in autoProcessMedia.cfg

[CouchPotato]
    [[movie]]
        no_status_check = 1

[qorron]

thank you! it now works like a charm.

some thoughts: I had to set wait_for = 0 because otherwise the script waits until the end. perhaps skip the checks altogether if no_status_check = 1? (motivation is: "why check if the config states that the result of the check is to be ignored?")

I noticed that the response to the few CP api calls I tried: media.get?id=... the media->title was missing every time. even though there was a media->files->movie[] entry which included a well-formed title. I have no idea on why this happens but nzbToMedia checks for media->title and I believe it fails because the title is missing. perhaps it could check for the files instead or media->status? note: media->title for the same movie is included in media.list though.

[clinton-hall]

Yeah, I'll take a look at it. I was struggling last night to think of a logical name. I was really aiming to not flag as failure when we can't confirm status, but still expecting to be able to verify status for those occasions that do (and not skip completely).... wait_for = 0 was a good call!

having a quick look, media.get not returning a title shouldn't be an issue. We only really rely on, and use, the id for the release anyway.

The flow of CP api checks is:

We check for a release id using movie.get and using the imdb id -if we have it in the file/folder name... as is done with CP Snatched downloads, then we also match the download id -if we have the idmdb from ombdapi (you need an account) Otherwise we look at all movies using movie.list and trying to match other parameters. (Honestly this is pretty much never going to work)

In the case of a manual download, this isn't going to match any snatched releases in CP so we don't have the initial release id.

After calling the renamer, it then:

tries the movie.get using the release id to then see if the release status has changed. When no release id exists is tries to see if it can determine any recent changes, but obviously this doesn't appear to have much luck.

Basically, Media status and files are not much help to us if we can't confirm the media... the renamed files can't be matched to the download name since this is dependent on your CP renaming. Status and recent changes are dangerous since this would assume no other changes can happen due to other automation or front-end access in CP.

The safest way is to determine the imdb id. but currently I can only do this using ombdapi. There are other tools (i.e. using similar identifying algorithms as CP itself.... but that is a lot trickier to implement)

[clinton-hall]

I moved this no-status check so that it now by-passes all status checks when set. In latest nightly branch.

[qorron]

works great! I tested movies triggered from CP and others that I sent from the indexer to sabnzbd. both cases worked. I also got myself an ombdapi key but this did not affect the behavior in a way that I could notice.

slightly OT, but CP no longer seems to be maintained. sooner or later debian will drop python2.7, so time to look for an alternative?

[clinton-hall]

yeah.... I've been happily using CP for years and it continues to do what I want. RuudBurger has pushed a few fixes and is still maintaining the api server etc.

Given my history with CP, I'd love to see it updated to py3 support. I just don't know that RuudBurger is going to find the time for that...

Now, my scripts have supported Radarr for some time... and Looking at recent commits to SickChill indicate pending (I don't know how far away) support for movies.

I'll reach out to Ruud to see what his intentions are for CP.

[qorron]

I'd love to see CP staying alive (=runable without too much headache on a debian stable) for a while longer because it looks nice and I can't think of any feature I miss.

[clinton-hall]

Same here... I do recall SickChill indicated they would have a "Select your CP Database" option to import existing CP data (and config??) when setting up movie support... so that may make things a bit easier... I was involved in some discussions back in the day (before the rise of SickRage/SickChill) around Adding TV support into CP... so this has kinda gone the other way.

From RuddBurger, I get the impression that a Py3 update to CP is unlikely. It will either be maintained as Py2 for so long as it can be, and then eventually un-supported, or it would be replaced by a different/new code base completely. Again that is all subject to his time...