1
0
Fork 0
Go to file
Xavier Fontanet bf7504caf1 slight clean 2024-07-25 15:38:23 +02:00
.idea setup repo and project 2024-05-19 12:57:23 +02:00
misc some proofs of runtime 2024-07-23 15:34:32 +02:00
src slight clean 2024-07-25 15:38:23 +02:00
test/torrents/Star Trek (1987) S01 [1080p] unit tests in da house 2024-05-25 18:09:37 +02:00
.gitignore add config 2024-05-19 13:08:51 +02:00
Dockerfile refining run configs & params 2024-05-19 18:25:10 +02:00
README.md some proofs of runtime 2024-07-23 15:34:32 +02:00
docker-compose.yml put the user in docker-compose 2024-07-25 15:37:40 +02:00
pom.xml new repo integrated on gitea 2024-06-16 20:43:01 +02:00
push.sh some refactors, ready to copy the files 2024-05-19 21:29:56 +02:00

README.md

Motivation

Common error

image

Why this happens?

The truth is I don't know. I have alternative ways to add new content to my flows which take a different path (instead of be added to Sonarr first I download them manually) but this happens in the normal path. I mean, I add a TV show to Sonarr, he identifies a download related and downloads it. Once finished he complains about not being able to continue. This has been happening to me quite much the last year.

Manual solution

image Ok, there is a way to solve it manually, which is click the import icon and fulfill the form (which always asks to input a "Release Group" description), but it means that I have to enter Sonarr regularly to check if there is some "blocked download" and do this repeated action over and over, which after many times it becomes quite tedious.

The workaround

I definetly don't want to spent more time ever on manual repeated process when I can make a robot do it for me. So here is the trick!

  1. Ask to Sonarr API the elements on Activity > Queue that has the matching warning
  2. For every "blocked download" with this problem
    1. Note it's related torrent download folder
    2. Note it's destination folder (the one that Sonarr copies to when all works fine)
    3. Copy, using hardlink option, all the episode video files to destination
  3. Clean from queue the elements fixed successfully
  4. Refresh the series related to the changes be reflected

This basically imitates the "correct" Sonarr behaviour, skipping the error.

Result

Here is an example execution: image

We can see in the logs that it seems the things have went well. If I check the Sonarr queue, the warning has gone:

image

And if we check the TV show detail, we see that now a recognized episode appears (the one related with the download), showing its filesystem fingerprint.

image