API Import fails despite series being parsed

tvcollector · August 23, 2019, 3:50pm

Sonarr version (exact version): 3.0.2.607
Mono version (if Sonarr is not running on Windows): 5.18.0.240
OS: Syno
Description of issue: Imported file via API is not recognised.

I’ve got a file called Long.Lost.Family.S09E07.HDTV.540p.x264-GTi.mp4, but when I use the API to get it imported, it seems to recognise the series:

19-8-23 16:43:06.9|Debug|Parser|Episode Parsed. Long Lost Family - S09E07

But then immediately fails to import it

19-8-23 16:43:06.9|Debug|DownloadedEpisodesImportService|Unknown Series for file: Long.Lost.Family.S09E07.HDTV.540p.x264-GTi.mp4

If I go into the ‘interactive import’ screen, the same file, unchanged, is immediately and automatically picked up:

Any ideas why? The same code calling the same API in the same way works for other mp4 files just fine.

Full log snippet here:

19-8-23 16:43:06.6|Debug|Api|[POST] /api/command: 201.Created (1274 ms)
19-8-23 16:43:06.9|Warn|DownloadedEpisodesCommandService|External directory scan request for unknown download SonarrAutoImporter, attempting normal import. [/downloads/Long.Lost.Family.S09E07.HDTV.540p.x264.Subs-GTi/Long.Lost.Family.S09E07.HDTV.540p.x264-GTi.mp4]
19-8-23 16:43:06.9|Debug|Parser|Parsing string 'Long.Lost.Family.S09E07.HDTV.540p.x264-GTi'
19-8-23 16:43:06.9|Debug|Parser|Episode Parsed. Long Lost Family - S09E07 
19-8-23 16:43:06.9|Debug|Parser|Language parsed: English
19-8-23 16:43:06.9|Debug|QualityParser|Trying to parse quality for Long.Lost.Family.S09E07.HDTV.540p.x264-GTi
19-8-23 16:43:06.9|Debug|Parser|Quality parsed: SDTV v1
19-8-23 16:43:06.9|Debug|Parser|Release Group parsed: GTi
19-8-23 16:43:06.9|Debug|DownloadedEpisodesImportService|Unknown Series for file: Long.Lost.Family.S09E07.HDTV.540p.x264-GTi.mp4
19-8-23 16:43:06.9|Debug|DownloadedEpisodesCommandService|Failed to import

If it helps, the JSON response from the API call is here:

{
  "name": "DownloadedEpisodesScan",
  "body": {
    "path": "/downloads/Long.Lost.Family.S09E07.HDTV.540p.x264.Subs-GTi/Long.Lost.Family.S09E07.HDTV.540p.x264-GTi.mp4",
    "downloadClientId": "SonarrAutoImporter",
    "importMode": "move",
    "sendUpdatesToClient": false,
    "updateScheduledTask": true,
    "completionMessage": "Completed",
    "requiresDiskAccess": false,
    "isExclusive": false,
    "name": "DownloadedEpisodesScan",
    "trigger": "manual",
    "suppressMessages": false
  },
  "priority": "normal",
  "status": "queued",
  "queued": "2019-08-23T15:53:15.223772Z",
  "trigger": "manual",
  "state": "queued",
  "manual": true,
  "startedOn": "2019-08-23T15:53:15.223772Z",
  "sendUpdatesToClient": false,
  "updateScheduledTask": true,
  "id": 101588
}

markus101 · August 23, 2019, 4:10pm

The only obvious difference I see if you’re passing the file path to the DownloadedEpisodesScan command instead of the folder path, does passing in the folder name make a difference?

tvcollector · August 23, 2019, 4:25pm

I can try that, but the whole point of this code is to iterate all the files in a folder coming from another download client, and trigger an import for each one. It feels like the API should work consistently on the filename, regardless of Path.

Given this line:

19-8-23 16:43:06.9|Debug|Parser|Episode Parsed. Long Lost Family - S09E07

and this one:

19-8-23 16:43:06.9|Debug|DownloadedEpisodesImportService|Unknown Series for file: Long.Lost.Family.S09E07.HDTV.540p.x264-GTi.mp4

Is there any way to get additional debugging to figure out what went wrong to stop the series being correctly identified? i.e., any trace logging that would show what series are considered etc?

markus101 · August 23, 2019, 5:15pm

I’m not 100% sure what trace logs adds in this case, easy enough to enable and see first hand.

This is actually an issue with the aliases, because someone requested Long Lost Family be added as an alias for the US series:

I’ve fixed that alias so it only applies to releases from certain release groups, so it’ll start working for your case.

Manual Import would work if triggered from the queue if it was already linked to the series since it already has series information.

tvcollector · August 23, 2019, 5:23pm

Okay, thanks for that. My first thought was that it might be looking for Long Lost Family (UK) but I checked the TVDB and it was fine.

Weird though, as it failed even when I removed the group ID. It’s a shame the API import logic can’t work like the manual import logic (i.e., taking into account the list of series that are in the queue).

If only there was a way to manually set aliases (or override the centralised one) within Sonarr locally…

Any chance that
a) We can add more info to the logging so that it says something like “Considered Long Lost Family, but alias => Long Lost Family (US) kicked in” so this would be easier to debug?
b) Extending the import API so I can explicitly extract/pass in the Series name as a hint?

[Edit - just realised your fix was to exclude certain groups, so now I see why removing the group didn’t fix it]

markus101 · August 23, 2019, 5:40pm

That’s not how it works. If you run Manual Import from the queue it passes along the ID of the download and that can be used to look it up, it doesn’t compare the path to things in the queue to find a match.

This is something we have no plans to support, fixing it for one fixes it for all, custom aliases would mean another area to troubleshoot.

More logging could be added in this case I think.

I don’t see this as something we’d do.

tvcollector · August 23, 2019, 5:49pm

If you run Manual Import from the queue it passes along the ID of the download and that can be used to look it up, it doesn’t compare the path to things in the queue to find a match.

Not sure I understand. I downloaded this manually myself and copied it into the downloads folder, so it was never in the queue. I then went into Wanted=>Missing, and clicked ‘Manual Import’. The interactive screen correctly identified the file, which must have been purely from the file/path, since there was no other context for it to get any ID from. Seems like using the API should be no worse than that at recognising shows?

This is something we have no plans to support, fixing it for one fixes it for all, custom aliases would mean another area to troubleshoot.

I know, and I understand the reasoning. I was half-joking. “Fixing it for one fixes it for all” is admirable, right up until the point where it fails like today though. But I can understand the edge cases it would solve would be far outweighed by the support overhead it would generate. I keep meaning to patch a local build to add that functionality for me.

Fair enough re: the API, I guess if we can figure out why the Interactive Import worked, but the API didn’t, it wouldn’t be necessary anyway…

Thanks for the time/help!

system · September 6, 2019, 5:49pm

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