Challenges with post processing

Version 2.0.0.4389
Mono Version 4.2.3 (Stable 4.2.3.4/832de4b Wed Mar 16 13:34:50 UTC 2016)
OS: Raspbian

Hi,

I have recently moved to Sonarr from sickrage and I am really enjoying it - but I’ve come across a problem that I cannot figure out a good workaround for.

This is using autodl-irssi for grabbing torrents (not Sonarr!). My downloads may or may not be archived (rar). I have set up a post processing script to check for rars, make a new folder and unrar in to it, and pass the resulting folder to Sonarr via the DownloadedEpisodesScan API. This works fine and everything processes as I would like

The problem is that when the files are not archived, Sonarr doesn’t post-process the file due to an error:

Couldn’t import episode /home/path/to/episode.mkv: Lock violation on path /path/to/organised/TV/show/Season/renamedepisode.mkv

The torrent is still seeding, so I recognise that this is probably the reason that the file is locked but I am still surprised because when i use Sonarr to grab the torrent via RSS (and therefore subsequently Sonarr takes care of its own post processing by connecting directly with my torrent client). this does not happen - Sonarr is totally OK with post processing it. I guess this might be because Sonarr temporarily stops seeding so it can post process?) Does anyone know of a reason for an apparent difference between when Sonarr post processes using the two different methods (Sonarr API call vs automated through the torrent client’s API)

I have tried a workaround involving making a hardlink copy of the file, and post-processing on that, but I still get the same file is locked error message. It is not possible for me to stop seeding temporarily (I just don’t know how!) so I am a bit stuck. I don’t think the error is a Sonarr problem, but I do think that possibly the fact that the sonarr API doesn’t stop seeding when you pass it a file to post process through the API is… Can anyone tell me if this is a real bug or if there is a workaround?

No, it doesn’t do that.

Maybe the difference is a copy vs a move, unless Sonarr is told which download client ID it’s importing in DownloadedEpisodesScan and it knows of that ID to see if it’s still seeding Sonarr will try to move it, otherwise it will try to Copy/hard link it, but the ((debug logs)) (the ones we asked for to help troubleshoot) will confirm.

Thank you for your response. I’ll get a debug to you shortly. I’m actually rewriting my post-processing script, as I have realised it could do some funny things when the download is a file but the unrar script it is expecting a folder.

I’ll finish rewriting it (in the next hour) and then push some videos (which are seeding) through it manually and see what happens. I can then provide a debug Sonarr log of what happens when it gets the API call…

PS - I am passing back the info hash to Sonarr in all upper case (but Deluge displays them as lower case). I think that’s correct, but it’s the only other reason I can think of for this problem…?

I appear to have fixed this, and it would appear it was my fault along, I guess, since the rewrite solved things. Here’s what I ended up with:

#!/bin/bash
formats=(zip rar)
declare -A commands=([zip]="unzip -u " [rar]="unrar e -o- ")
declare -A postcommands=([zip]=" -d " [rar]="")

torrentid=$1
torrentname=$2
torrentpath=$3
i=0

log()
{
    logger -t deluge-extractarchives "$@"
}

log "Torrent complete: $@"

if [ ! -d "$torrentpath/$torrentname" ] ; then #if the torrentpath/name is not a folder, just post process as if it's a file (which it presumably is)
    curl http://localhost:8989/api/command -X POST -d '{"sendUpdates": true, "name": "downloadedepisodesscan", "path": "'"$torrentpath/$torrentname"'", "downloadClientId": "'"${torrentid^^}"'"}' --header "X-Api-Key:MY_SONARR_API_KEY"
else         #make an extraction folder, extract all zips and rars to it.  Count to see if you actually extract anything (i)
    extraction_dir="/home/user/Temporary/Extracting/$torrentname"
    for format in "${formats[@]}"; do
        while read file; do
            i=$((i + 1))
            log "Extracting \"$file\""
            mkdir -p "$extraction_dir"
            ${commands[$format]} "$file" ${postcommands[$format]} "$extraction_dir"
        done < <(find "$torrentpath/$torrentname" -iname "*.${format}" )
    done

    if [ $i -gt 0 ] ; then #if i is greater than 0, you extracted something!  Pass the extracted folder to Sonarr
        curl http://localhost:8989/api/command -X POST -d '{"sendUpdates": true, "name": "downloadedepisodesscan", "path": "'"$extraction_dir"'", "downloadClientId": "'"${torrentid^^}"'"}' --header "X-Api-Key:MY_SONARR_API_KEY"
    else #otherwise, there was nothing to extract (no zips or rars).  Perhaps this torrent is simply a folder with several episodes.  Get Sonarr to process the whole original folder instead!
        curl http://localhost:8989/api/command -X POST -d '{"sendUpdates": true, "name": "downloadedepisodesscan", "path": "'"$torrentpath/$torrentname"'", "downloadClientId": "'"${torrentid^^}"'"}' --header "X-Api-Key:MY_SONARR_API_KEY"
    fi

fi

It was actually a bit fiddly, as those arrays at the top needed explicitly declaring, but they are not explicitly declared in the Deluge example (otherwise it always used the rar commands and not the ZIP ones). Hopefully this code might help someone else who is coming from Sickrage and would prefer things to be unrared automatically where necessary.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.