SABnzbd Forums

At first I thought this was a bug in the SABconnect++ extension, because sometimes the chrome extension will send nzbs to SABnzbd+ with a filename that contains a comma. But I missed the "Replace Illegal Characters in Folder Names" switch in SABnzbd+. It is checked, so I guess still using comma's in the path is a bug, clearly SABnzbd+ should have filtered it with that switch checked.

I (wrongly) reported it as a bug of SABconnect++ over here, so I will just copy/paste the info:

What steps will reproduce the problem?
1. Use the sab button of one of these: http://nzbindex.nl/search/?q=supernatural.s04.1080p
2. SABnzbd+ starts downloading them fine (in memory), but can't write the files to disk
(3.) Renaming the entry inside SABnzbd+ doesn't seem to work, I guess that's just to pretty up the list and not to change the actual path.

What is the expected output? What do you see instead?
It looks like the filename of the nzb sent to SABnzbd+ was like this (note comma after GB at the end): SABnzbd+ will use this as the foldername. This can't happen on windows and it will show disk errors like these below, no doubt caused by the comma in the path: It will just keep showing these disk errors and basically stop eventually, I'm guessing when it's at the memory limit (I have it set to download to memory because of the 100+mbit download speed).

Version: SABnzbd+ 0.5.6
Using Chrome extension: SABconnect++ 0.4.9
OS: Windows Vista
Install-type: Windows Installer
Are you using IPV6? no
Is the issue reproducible? yes

A comma is a perfectly legal character on Windows.
The folder name is rather ludicrous though.
How does it get into the queue?

What the.. seems you're right, could have sworn it was an illegal character. I think I've also had the same error with a : in the folder path before, which I think is an illegal character. I guess I assumed this time it was the comma, no idea why it would throw the error on this now though.

I've only had this happen with some nzbs from nzbindex.nl, and using the SABconnect++ extension for chrome. Which from what I understand sends nzbs to the API directly?

I guess I'll have to wait for it to happen again to try and figure out what's really causing this.

Is can be that SABConnect sends a job name that's different than the actual NZB file name.
In pre-0.5.6 releases this name wasn't properly filtered, but it should be handled properly by 0.5.6
The path name as such is legal, I can create it on my system.
I see that the drive is H:.  Is this a networked drive or an external drive formatted as FAT32?
These could have different limits than a local NTFS drive.

Yes it does, it sends the full (post)name instead of filename. The extention does have this option for nzbindex.nl and binsearch: "use NZB filename instead of full name as displayed on website". Which did seem to fix it but you end up getting weird abbreviated titles instead of the full name.

My H: is an local NTFS drive, I just have a bunch of them. I'll report back when it happens again and its reproducible.

I've also had this same problem for some time now but I can't figure out what causes the disk errors.

It is reproducible by adding this nzb via the chrome extension SABconnect++:
http://www.binsearch.info/?q=Stargate+A ... 00&server=

SABnzbd+ then briefly shows that it is fetching the nzb:
Trying to fetch NZB from http://binsearch.info/?action=nzb&52871730=1

In the attached screenshot I added the same nzb file 3 times using different switches.
The first has "replace illegal characters" disabled, the second has it enabled and the third also has "replace spaces with underscores" enabled (which only seems to have effect in the queue since the error doesn't show any underscores)

The strange thing is that I can manually create the folder and file displayed in the errors without any problems.

For some reason SABnzbd tries to use the full URL as a job name.
This is not correct.
I'll look into it.
In the mean time you'll have to rename such jobs manually or save it as a file first.

In an attempt to fix this at the SABconnect++ end I noticed that it sends not only the filename but also the info about the collection (number of files, size, etc). So in the Stargate Atlantis example it would use this as filename:
Stargate Atlantis Seizoen 4 *WEB DL* - [01/15] - "Stargate Atlantis S04E20 WEB DL.par2" yEnc (1/1)
collection size: 1.48 GB, parts available: 2394 / 2394
- 7 rar files
- 8 par2 files
- 1 nzb file

Which is this in the Binsearch source:

Stargate Atlantis Seizoen 4 *WEB DL* - [01/15] - "Stargate Atlantis S04E20 WEB DL.par2" yEnc (1/1)
collection size: 1.48 GB, parts available: 2394 / 2394- 7 rar files- 8 par2 files- 1 nzb file


When only using the part the disk errors are gone. When only using the part the errors are back, so the problem has to be there. Perhaps it is to long?

Anyway I've submitted a patch to SABconnect++ that should fix this for Binsearch (http://code.google.com/p/sabconnectplus ... tail?id=30), though I guess errors like this still have to be fixed at the SABnzbd+ end. I hope this helps identifying it

I was assuming you were sending the binsearch URL to SABnzbd.
It looks like that's not the case, because the URL doesn't deliver NZB files, but just a binsearch page with links to NZB's.
The problem is therefore the info that SABconnect++ sends to SABnzbd.
SABnzbd does some basic filtering on the received nzbname parameter of the API call, but to a certain extent.
It's SABconnect that should send decent titles and not some URL-derived gibberish.
The API is less well "protected" then the normal UI.