Auto un-monitoring of Episode failing with error in Sonarr
In which file is the bug? sonarr/unmonitor_downloaded_episodes.py
Describe the setup (arguments and their values, how it was run, etc.): Setup as per instructions (IP/port/API); to tested enabled in the Custom Script for "Import (previous download", "upgrade" and the "TEST" button in sonarr showed all ok; failed with real file testing (post small file download).
Describe what the bug is: The episode upon download was not un-monitored and the log-event was showing following error:
SonarrErrorPipeline | Request Failed. PUT /api/v3/episode/monitor: Could not convert string to integer: None. Path 'episodeIds[0]', line 1, position 22. (Json snippet 'episodeIds": ["None"<--error-->], "monitored": fals')
Describe what should be happening: Episode should have un-monitored successfully
I know what the problem is but I'm not sure yet what's causing it.
The error is that it's trying to unmonitor an episode with a certain id, but the id of the episode isn't passed along by sonarr when running the script.
So we need to find out why :)
This script never worked, right?
You parse episode id as a string str() when sonarr's API asks for a integer.
episode_id = str(getenv('sonarr_episodefile_episodeids'))
https://sonarr.tv/docs/api/#/Episode/get_api_v3_episode__id_
Well that could be it.
First of all, since when are there v3 docs of the api? The must be very new.
Secondly, it used to be that you needed to parse strings. The script worked fine for months. But it might've been changed to integers now.
dunno, I tried the script yesterday and it didn't work. I landed on this bug report yesterday, and today when I checked the API page and saw it asked for an integer.
I just checked the old/legacy API also asks for an int but parse it between double quotes "". Go figure.
https://github.com/Sonarr/Sonarr/wiki/EpisodeFile#parameters-1 https://github.com/Sonarr/Sonarr/wiki/API
I just checked the old/legacy API also asks for an int but parse it between double quotes "".
Yeah... so a string. "2" is a string, 2 is a integer. They used to ask for a string and now they want an integer.
Changing str to int didn't cut it. sadly.
2022-11-02 11:40:15.2|Debug|CustomScript|Executing external script: /home/(removed)/.config/unmonitor_downloaded_episodes.py
2022-11-02 11:40:15.2|Debug|unmonitor_downloaded_episodes.py|Starting /home/(removed)/.config/unmonitor_downloaded_episodes.py
2022-11-02 11:40:16.8|Error|unmonitor_downloaded_episodes.py|Traceback (most recent call last):
2022-11-02 11:40:16.9|Error|unmonitor_downloaded_episodes.py| File "/home/(removed)/.config/unmonitor_downloaded_episodes.py", line 46, in <module>
2022-11-02 11:40:16.9|Error|unmonitor_downloaded_episodes.py| episode_id = int(getenv('sonarr_episodefile_episodeids'))
2022-11-02 11:40:16.9|Error|unmonitor_downloaded_episodes.py|TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
2022-11-02 11:40:16.9|Debug|CustomScript|Executed external script: /home/(removed)/.config/unmonitor_downloaded_episodes.py - Status: 1
2022-11-02 11:40:17.0|Debug|CustomScript|Script Output:
11/2/2022 10:40:16 AM - Error - Traceback (most recent call last):
11/2/2022 10:40:16 AM - Error - File "/home/(removed)/.config/unmonitor_downloaded_episodes.py", line 46, in <module>
11/2/2022 10:40:16 AM - Error - episode_id = int(getenv('sonarr_episodefile_episodeids'))
11/2/2022 10:40:16 AM - Error - TypeError: int() argument must be a string, a bytes-like object or a real number, not 'NoneType'
I poke around the API later. The last time I wrote anything python related it was for my calculator.
No see I was right. It's not a problem of int or str. The whole problem is that sonarr doesn't parse the id of the episode when running the script.
From a previous comment:
The error is that it's trying to unmonitor an episode with a certain id, but the id of the episode isn't passed along by sonarr when running the script.
Yes, something with the environment and ids not being passed/parsed correctly. If you wrote it for an old version of the API and they changed how to scrape from Sonarr with APIv3, it's probably something silly. I'll try to mess around with the API later this afternoon.
It's most likely that the global variables that sonarr runs the script with have been renamed.