Issue Importing NZB's

[e324121]

Setup on Windows Server 2012 R2, importing from Sonarr to Sab 0.7.20.

Importing this fails:

[ TOWN ]-[ http://www.town.ag ]-[ ANIME ]-[Usenet Provider >> http://www.ssl- <<] - [Commie] Aldnoah Zero 18 [234C8FC7]

Debug Logs:

2015-03-20 23:14:49,257::INFO::[__init__:628] Adding [ TOWN ]-[ http://www.town.ag ]-[ ANIME ]-[Usenet Provider >> http://www.ssl- <<] - [Commie] Aldnoah Zero 18 [234C8FC7]
2015-03-20 23:14:49,257::ERROR::[__init__:638] Cannot create temp file for [ TOWN ]-[ http://www.town.ag ]-[ ANIME ]-[Usenet Provider >> http://www.ssl- <<] - [Commie] Aldnoah Zero 18 [234C8FC7]
2015-03-20 23:14:49,257::INFO::[__init__:639] Traceback:
Traceback (most recent call last):
File "sabnzbd\__init__.pyo", line 634, in add_nzbfile
File "tempfile.pyo", line 302, in mkstemp
File "tempfile.pyo", line 236, in _mkstemp_inner
OSError: [Errno 22] Invalid argument: 'c:\\users\\censored\\appdata\\local\\temp\\1\\tmpfrsw8z.ssl- <<] - [Commie] Aldnoah Zero 18 [234C8FC7]'

Process Monitor:


Help - looks like a parser issue?

[shypike]

As you can see, the title is full of characters that Windows does not allow in file names.
SABnzbd should filter those out.
I suspect that Sonarr manages to squeeze in such a name through a path that ins't checked
by SABnzbd for illegal characters.
The debug log misses the part where Sonarr sends the NZB to SABnzbd.
Can you try to find that spot in the log?

[e324121]

Whoops, as per: http://pastebin.com/Wkb32kfS

[shypike]

Thanks.
This is a bit of a weird issue.
SABnzbd creates a temp file to store the received NZB data in.
For some reason that temp file contains part of the original title as sent by Sonarr.
(The "<<" part is the problem, Windows doesn't want that in a file name.)
That should not happen and is a genuine bug.

I'll fix this at least for 0.8.0Alpha1
Currently there's not work-around, unless there's a way to tell Sonarr to use cleaned-up names.

[shypike]

Solved for 0.8.0
The problem is triggered by Sonarr because it doesn't send a proper file name
with an extension (like .nzb or .zip).
Of course SABnzbd should handle that, but it doesn't now.
Apparently Sonarr is an exception with this behaviour.
The lack of an extension normally doesn't hurt, but it does when there are also illegal characters in the name.

[Taloth]

Looked at it on our end, we generate a clean filename... but then used the wrong variable and sent the release title instead. Fixed that, should be available on the develop branch soon.
Been like this for forever, never ran into the bug because normally indexers cleanup that stuff, after all, the parts of the article header that is supposed to be used comes from a filename in the first place.

Looks like animenzb cleaned this one wrong, prolly coz of the provider name in there: http://animenzb.com/?q=Aldnoah+Zero+18&cat=
Hover over the titles to see the original headers.