Sonarr is not reading correct path from torrent downloads, works for some but not all

[neodawg]

Sonarr version (exact version): 2.0.0.4949
Mono version (if Sonarr is not running on Windows):
OS: Windows 7
((Debug logs)):
()
Description of issue:

I have this error with some torrents downloading and CDL is failing to read the correct path.

No files found are eligible for import in C:\Sonarr\StartUp.2016.S02E03.WEB.x264-TBS[rarbg]\StartUp.2016.S02E03.WEB.x264-TBS[rartv]

This is the error in the log file:

Import failed, path does not exist or is not accessible by Sonarr: C:\Sonarr\StartUp.2016.S02E03.WEB.x264-TBS[rarbg]\StartUp.2016.S02E03.WEB.x264-TBS[rartv]

Its not limited to a certain release group, but I think most of the time the problem ones do come from rartv or rarbg. Some downloads work fine and import correctly.
I have to manually import them by going through ‘Wanted’.

When I try to manual import them from the Activity screen I get this error:

Manual Import - StartUp.2016.S02E03.WEB.X264-TBS[Rartv]
No video files were found in the selected folder.

The real correct path is this:

C:\Sonarr\StartUp.2016.S02E03.WEB.x264-TBS[rarbg]\startup.2016.s02e03.web.x264-tbs.mkv

Any assistance on this issue would be most excellent.
Thanks

[markus101]

Please post ((debug logs)) that include the failing import.
Which torrent client are you using?

[neodawg]

I am using Vuze 5.7.5.0

Here are the logs

EDIT: nevermind, debug logging isnt turned on. I will update with a new log once it generates one.

EDIT2: looks like it has put some errors in the log

[markus101]

I think it has to do with StartUp.2016.S02E03.WEB.x264-TBS[rarbg] vs StartUp.2016.S02E03.WEB.x264-TBS[rartv], looks like Sonarr is forced to guess whether it’s been given a folder or a file and uses the output path’s filename and and the torrent name and because those differ I believe it’s appending the torrent name to the path and Sonarr can’t locate the files.

((Trace logs)) will confirm my suspicions, the best way would be to enable trace logging, clear the existing log files then restart Sonarr, which will connect to Vuze and process the items. If you can grab the logs after a few minutes and zip them up (if there is more than one file) and post them, I can take a look.

If Sonarr is treating it as a file it will log Vuze output file: otherwise it will log Vuze output directory: (plus the path).

[neodawg]

Here is the trace log, it looks like your right and its adding the name to the path and calling it a file and not a directory.

Trace Logs

[neodawg]

Anything else you need from me to diagnose what is going on?

[markus101]

Sorry, no, a matter of us seeing if there is anything we can do to work around this (since it may have changed in a recent version).

[markus101]

I took a look at what Sonarr receives from Vuze and I’m not seeing a way to get around this issue. Any ideas @Taloth?

Example pulled from the logs:

{
    "downloadDir": "C:\\Sonarr\\StartUp.2016.S02E01.WEB.x264-TBS[rarbg]",
    "errorString": "",
    "eta": -1,
    "hashString": "0139042E8D97369532EB68A2B682679BB005E402",
    "id": 1272,
    "isFinished": false,
    "leftUntilDone": 0,
    "name": "StartUp.2016.S02E01.WEB.x264-TBS[rartv]",
    "status": 5,
    "totalSize": 411539705
}

[Taloth]

@markus101 The releasename on the site is with rartv, but if you inspect the torrent you’ll see rarbg. I think vuze uses the name in the torrent file metadata as folder name, instead of the releasename we supply.
Solution would probably be to extract the name from the torrent file, but I think we normally use magnets, making that impossible to do reliably.

Vuze supplies a ‘downloadDir’ which is technically correct, but has different implications in single vs multi downloads. Ideally we’d work with Vuze to fix that ambiguity.

There might be another api available in Vuze to get the filelist of the download, we just prefer not to do additional api calls coz at this point in the process we don’t know if we’re even going to import anything.

One way to remedy those additional api calls would be to begin with the TransferProviders framework, exposing an abstraction (virtual filesystem of the download, and only the download) instead of a ‘path to file or directory, good luck’.
The abstraction would use lazy/deferred api calls to vuze to get the file list, and would be a stepping stone to on the fly unrar, async transfers, etc.

/techtalk