New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ImportApprovedEpisodes | Couldn't import episode: Object reference not set to an instance of an object. #2919

Closed
digitalface opened this Issue Jan 25, 2019 · 29 comments

Comments

Projects
None yet
7 participants
@digitalface
Copy link

digitalface commented Jan 25, 2019

Describe the bug
I have a few different Pi boxes (and 1x OSMC) and they've all (over the last week or so) started getting this error message. Different Mono versions, different Sonarr versions, different episodes, same error...

Logs

https://pastebin.com/U9bpd5DP

System Information

  • Sonarr Version: 3.0.1.351
  • Operating System: RaspberryPi Debian Stretch
  • Mono 5.16.0.220

Additional context
Episodes are imported via a scan initiated from the NZBtoMedia script. As mentioned above, I have a few different devices with this error. They've been working great for 2+ years. I even upgraded from v2 Sonarr to v3 to see if it fixed the issue but no. I'm at a total loss as to what's suddenly changed.

@BRTPOB

This comment has been minimized.

Copy link

BRTPOB commented Jan 26, 2019

I'm seeing the same thing, with the same exact error on two different Ubuntu machines. I'll attach the logs from both of my instances later on today.
System 1:
System Information

” Sonarr Version: 2.0.0.5301
” Operating System: Ubuntu 16.04.5 LTS
” Mono 4.8.1.0

System 2
System Information

” Sonarr Version: 2.0.0.5301
” Operating System: Ubuntu 16.04.5 LTS
” Mono 5.18.0.240

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

Can you include full trace level logs?

@markus101 Related to the OriginalFilePath change, the code assumes the downloadClientItem has a OutputPath, which isn't guaranteed at all since the download is still in the nzbget pp stage.

@BRTPOB

This comment has been minimized.

Copy link

BRTPOB commented Jan 26, 2019

How would I get the full trace level logs?

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

Settings->Log level = Trace

What i'm interested in is the actual api response from nzbget just prior to the import attempt.

@BRTPOB

This comment has been minimized.

Copy link

BRTPOB commented Jan 26, 2019

OK, I don't have NZBGet, I've been using rTorrent/ruTorrent. Not sure if that makes a difference.

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

probably no difference, assuming you're having the same problem as OP

@BRTPOB

This comment has been minimized.

Copy link

BRTPOB commented Jan 26, 2019

Pretty sure I am, but I'm not able to see it in my logs currently. I'll go break the changes I made and get it to break again, then get you the trace level logs.

@markus101

This comment has been minimized.

Copy link
Member

markus101 commented Jan 26, 2019

If it's still in the PP stage then shouldn't it not be importing?

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

if it's called via nzbToMedia after transcoding etc, it will. (That's why BRTPOB's logs will be interesting)

@markus101

This comment has been minimized.

Copy link
Member

markus101 commented Jan 26, 2019

Ahhh, right.

@BRTPOB

This comment has been minimized.

Copy link

BRTPOB commented Jan 26, 2019

OK, so I don't have the same exact error as the OP, but the script I'm using makes use of the downloadEpisodesScan api call. This is the original exception I got. I'm trying to repro, but it's not wanting to work with me in Trace mode.

19-1-26 16:29:13.8|Warn|ImportApprovedEpisodes|Couldn't import episode /home/offspring/process/tv/Cardinal.S03E01.720p.HDTV.x264-aAF/Cardinal.S03E01.720p.HDTV.x264-aAF.mkv
[v2.0.0.5301] NzbDrone.Common.Disk.NotParentException: /home/offspring/process/tv/Cardinal.S03E01.720p.HDTV.x264-aAF/Cardinal.S03E01.720p.HDTV.x264-aAF.mkv is not a child of /home/downloads/torrents/tv/
at NzbDrone.Common.Extensions.PathExtensions.GetRelativePath (System.String parentPath, System.String childPath) [0x00022] in M:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Common\Extensions\PathExtensions.cs:65
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportApprovedEpisodes.GetOriginalFilePath (NzbDrone.Core.Download.DownloadClientItem downloadClientItem, NzbDrone.Core.Parser.Model.LocalEpisode localEpisode) [0x00003] in M:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\MediaFiles\EpisodeImport\ImportApprovedEpisodes.cs:156
at NzbDrone.Core.MediaFiles.EpisodeImport.ImportApprovedEpisodes.Import (System.Collections.Generic.List`1[T] decisions, System.Boolean newDownload, NzbDrone.Core.Download.DownloadClientItem downloadClientItem, NzbDrone.Core.MediaFiles.EpisodeImport.ImportMode importMode) [0x00263] in M:\BuildAgent\work\5d7581516c0ee5b3\src\NzbDrone.Core\MediaFiles\EpisodeImport\ImportApprovedEpisodes.cs:105

@evilhero

This comment has been minimized.

Copy link

evilhero commented Jan 26, 2019

For reference, @BRTPOB (he asked me to comment as well) is using a program called Harpoon which is used to retrieve selected torrents via Sonarr from a remote machine and to store them locally where the localized version of Sonarr is run. It initiates the downloadEpisodesScan API call thereafter (which is what nzbToMedia does as well I'm sure), in order to tell Sonarr that the items are now local instead of remote - which is where it runs into the above problem. This broke in the latest update (minutes before I had a run which worked fine, immediately after the update it didn't).

The only way we've been able to fix the problem for Harpoon is to have a Sonarr Remote Mapping pointing from the remote machine to the local folder where Harpoon drops the local torrents. In doing so, it will import them fine after a short delay (but only if the status is Completed within Sonarr, otherwise it won't). The remote mapping requirement was never needed prior to this last update (and there should be no need for it since the data is all localized).

Hope this helps!

Logs
https://pastebin.com/Gi0Z2Y6S

System Information
Sonarr version: 2.0.0.5301
Ubuntu 16.04.5 LTS
Mono: 5.8.0.127

@markus101

This comment has been minimized.

Copy link
Member

markus101 commented Jan 26, 2019

That error should was already fixed in v3, but not v2.

@evilhero

This comment has been minimized.

Copy link

evilhero commented Jan 26, 2019

So, not to hijack this thread too much- when you say that it's fixed in v3, I'm going to assume there's no intention to fix this in v2 then ? And by mention of your fix - does that mean that the Remote Path Mappings would still be required in v3 ?

@markus101

This comment has been minimized.

Copy link
Member

markus101 commented Jan 26, 2019

Not necessarily, just mentioning it because we'd need to cherry pick the fix back.

No, it's fixed in that it's not required to be a child.

@digitalface

This comment has been minimized.

Copy link
Author

digitalface commented Jan 26, 2019

@Taloth is there a way for me to PM you the trace file? Not sure if there's any personal info contained within it.

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

@evilhero Harpoon should not need to call the Sonarr api. It's better to use the Remote Path Mapping since the api call is a one shot deal and it won't try again if the import is rejected for some reason.

Step 1 is to copy the files from remote to local to some temporary location. Step 2 is to move the file/folder associated with a single download from the temporary location to the local folder as specified in the Remote Path Mapping. This ensure that all files for that download are visible at once.
And yes, we'll deal with the error you're getting. I just wanted to point out a more reliable way of doing things.

@digitalface On Github no, but you can send it to me on our forums, or irc channel or reddit. (if you're going to use the forums, lemme know the username so I can set your userlevel to be able to pm)

@digitalface

This comment has been minimized.

Copy link
Author

digitalface commented Jan 26, 2019

@Taloth , I've just created user on Sonarr forums, name same as here :-)

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

k, you should be able to PM now.

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 26, 2019

Tnx.

"DestDir" : "\/mnt\/Hard_Drive\/NZBget\/intermediate\/Power.2014.S05E01.WEB.H264-DEFLATE.#48",
"FinalDir" : "",

So that confirms the issue for nzbget.

As a side note, what are you using nzbToMedia for? Not transcoding coz it's both mkv.

@markus101 It might be better to pass the starting folder in DownloadedEpisodesImportService ProcessFile and ProcessFolder functions to the Import function, and use that to construct the relative path. That way you don't have to infer it from the item or guess based on parent/grandparent.

@digitalface

This comment has been minimized.

Copy link
Author

digitalface commented Jan 26, 2019

I've always used it. Just habit really, it's not used for transcoding so it notifys sonarr/radarr when the download is finished so it can import it.

What do you think the issue is? Nzbget hasnt updated on any of my boxes, neither has mono etc
The scripts are the same version. Very odd.

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 27, 2019

I've always used it. Just habit really, it's not used for transcoding so it notifys sonarr/radarr when the download is finished so it can import it.

Then you don't need it at all, Sonarr queries the nzbget api to determine which downloads are ready for import.

What do you think the issue is? Nzbget hasnt updated on any of my boxes, neither has mono etc
The scripts are the same version. Very odd.

That one is easy, a new version of sonarr was released a few days ago. The change that introduced the issue was released on the develop branch like 4wk ago and nobody using that branch noticed the issue until this time.

@digitalface

This comment has been minimized.

Copy link
Author

digitalface commented Jan 27, 2019

Cool okay thank you. So would your advice be to stop using nzbtomedia or is it likely a fix will be introduced in Sonarr soon? What if I or someone else did use Nzbtomedia for transcoding, I assume it would still fail?

I've used the script for years as I didn't like the thought of (then sickrage) scanning the completed folder every minute to see if a file had downloaded, causing unnecessary spin up of the HDD. But if youre saying Sonarr queries NZBget via API then I guess it's all fine.

@Taloth

This comment has been minimized.

Copy link
Member

Taloth commented Jan 28, 2019

we'll fix the issue, but it won't be released soon. In your case it's easier to drop nzbToMedia.

@markus101

This comment has been minimized.

Copy link
Member

markus101 commented Feb 3, 2019

The fix has been cherry picked to develop.

@markus101 markus101 closed this Feb 3, 2019

@hmphargh

This comment has been minimized.

Copy link

hmphargh commented Feb 3, 2019

@markus101 Sorry to bump after this is closed, but I'm not clear on the resolution. Is this fix in phantom-develop already? It looks like digitalface has the issue with 3.0.1.351, and I am seeing what I believe to be the same issue on 3.0.1.363. Sorry if this has been explained, but I could not find a clear answer to my question in this issue.

@markus101

This comment has been minimized.

Copy link
Member

markus101 commented Feb 4, 2019

Sorry I mixed this one up, it's not currently fixed.

@markus101 markus101 reopened this Feb 4, 2019

@digitalface

This comment has been minimized.

Copy link
Author

digitalface commented Feb 4, 2019

Fyi I've removed the nzbtomedia script and instead use sonarr's inbuilt download handler and it appears to work just fine.

I had been using nzbtomedia since the days of sickrage etc where the download handling was done via a scan of the download directory which I didn't like. A script at the end of the download process seemed much neater but sonarrs API calls appear just as efficient.

@mrowlinson

This comment has been minimized.

Copy link

mrowlinson commented Feb 6, 2019

Fyi I've removed the nzbtomedia script and instead use sonarr's inbuilt download handler and it appears to work just fine.

I had been using nzbtomedia since the days of sickrage etc where the download handling was done via a scan of the download directory which I didn't like. A script at the end of the download process seemed much neater but sonarrs API calls appear just as efficient.

Same here, since even before then with SickBeard. Also switched off the nzbtomedia scripts and everything has been working fine. It also fixed a problem where, when using the nzbtomedia scripts, occasionally cruft was left behind for the download, like the folder and some junk files like par2 files, etc.

markus101 added a commit that referenced this issue Feb 7, 2019

@markus101 markus101 closed this in c3c6b3d Feb 7, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment