[SOLVED] Import fails for some files both automatic and manual

Sonarr version (exact version): 2.0.0.4472
Mono version (if Sonarr is not running on Windows): 4.2.3 Stable 4.2.3.4/832de4b
((Debug logs)): Yes, more available on request
Description of issue:

Sonarr is running on Ubuntu 16.04. Started in a ‘screen’ using ‘mono /opt/NzbDrone/NzbDrone.exe’. The user that starts sonarr is the owner of /opt/NzbDrone/.

Everything is configured correctly using SABnzbd on a remote server. The remote directory’s are mounted using sshfs by the same user that is running sonarr and owns all the media.

Sonarr is connected to SABnzbd using its full api and they communicate perfectly, files are grabbed from the rss feed and the status is shown correctly.

However, some files, not all, but around 70% fail to be imported both automatically and manually.

If I download the files to my machine using FTP and then try to manually import them, everything gets parsed correctly, all the correct show name and season/episode number is correct, but the import fails anyway.

All the files that sonarr fails to import are reported as complete by SABnzbd and the media can be played locally using vlc.

Example of a failed manual import, debug log: http://pastebin.com/iS8LNKq8
Example of a failed automatic import, debug log: http://pastebin.com/MxKmzr7n

The usual error is “File Not Found”, the files do exist and are parsed correctly by sonarr. The user that runs sonarr has full ownership of the files and even changing the file properties to ‘777’ doesn’t help, so I really don’t think this is a permissions issue.

Hopefully someone can help me with this.
Thanks in advance!

What’s different between the files that import and the ones that fail to import?

This one shows Sonarr was able to read the file and process it until it tried to move it and then it failed with the error:

System.IO.FileNotFoundException: Could not find file ""

I’d expect the path to be populated there, but that could be a bug in mono.

Does Sonarr have the proper access to the destination path?

17-1-26 20:14:53.0|Debug|DiskTransferService|Move [/mnt/nzb/tv/Its Always Sunny in Philadelphia S12E04 Wolf Cola A Public Relations Nightmare 720p WEB-DL AAC2.0 H.264-Oosh/Its Always Sunny in Philadelphia S12E04 Wolf Cola A Public Relations Nightmare 720p WEB-DL AAC2.0 H.264-Oosh.mkv] > [/mnt/pool/tv shows/It's Always Sunny in Philadelphia/Season 12/It's.Always.Sunny.in.Philadelphia.-.S12E04.-.Wolf.Cola-.A.Public.Relations.Nightmare.WEBDL-720p.mkv

I honestly cant find a difference between the files.

When SABnzbd tries to re-download the same file, just adding a .1 to the directory name, then sometimes this file gets imported, yet the original fails.

Its also inconsistent with the manual import, I can try several times to manually import the same files, without changing anything, and on the third or forth attempt it will succeed.

Sonarr, or at-least the user running sonnar has full ownership of the entire media library, the sonarr /opt/NZBDrone dir and the remote mounted directories.

If there a development version of mono or sonarr that I should try, or you need any more information or log files just let me know.

Thanks in advance.

Something with the sshfs mount maybe? That sounds like something is unreliable and failing more than it is succeeding. The import process is Sonarr stays the same regardless of how the import was started, the only difference would be copying/hardlinking vs moving.

I’m not sure that upgrading would help, but you could look at upgrading mono.

I have fixed the problem, it wasn’t anything to do with Sonarr.

I use mergerfs to pool my drives and it appears there is a bug in either mergerfs or fuse, so when you set the ‘user.mergerfs.category.create’ to ‘eprand’ it wont allow creation of new files if the randomly chosen drive is full, it’s supposed to automatically choose another drive to write too, but for some reason it didn’t.

Setting this flag to ‘epmfs’ has fixed all my issues.

Thanks for your help!

Author of mergerfs here.

eprand, as the docs state, will call epall and randomize. epall filters out drives which don’t have the existing path, which are mounted read only, and have less than minfreespace available. There is no fallback listed.

So if all the drives with the path in question are beyond minfreespace… there is nowhere to create the file.

epmfs has fallbacks so it will choose a drive at some point even if minfreespace is not available.

One can argue that it should have a fallback but it doesn’t currently and is documented as such.

1 Like

My apologies for not reading the documentation thoroughly, I should have taken more time to investigate the issue before complaining, but none the less, everything is working fine now, mergerfs and sonarr are both working perfectly together!

No worries. And like I said it can be argued that all policies should result in a drive being selected no matter what. Unfortunately, both behaviors could be confusing.

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