SABnzbd Forums

Version: 0.6.1
OS: XP SP3
Install-type: Windows Installer
Skin (if applicable): Default
Firewall Software: None
Are you using IPV6? No
Is the issue reproducible? Yes

For my first few days of using the software, I used the .ini size_limit to set all incoming nzb to "paused".  The file would then be prefixed with (sometimes replaced with) "TOO LARGE / ", which was fine in itself, except the "TOO LARGE" seemed to become a permanent part of the filename.  The resulting file would be saved as 'Too Large.ext', 'Too Large.1.ext', and so on.  Which made things a bit difficult to organize.

I've since dropped using the size_limit, so I'm not bothered by it anymore, but figured I'd mention the behaviour regardless.

It's definitively not the intention to have "too large" as part of the file name.
I'll look into it.

Well, I cannot reproduce this issue.

I'll see if I can come up with something more concrete for reproduction steps.

About the only thing I can think of offhand is that I used a fairly small size_limit (100K I believe), and they would probably have been added via a watched folder, as I did an export of the queue of the previous client.  But I'm having trouble believing the the size threshold would make a difference to the name later.

I do have them in the history yet, if that is at all useful.

If you see it in history, then it must have happened.
However, there must be some special circumstances to cause it.
Can you send me a screenshot of the details of one of the items?
(The details popup when you click the title in the Plush skin)
bugs at sabnzbd.org

Sent!

In addition to the screenshot requested, I've also included the history xml node for the same file, along with the logs of where the file was imported.

Nothing in the files has any clue in it.
I see that at some point "too large" is used as the job name,
but nothing says where this happens.
The XML files mostly contain what they should.
The log doesn't cover enough.
This must be going wrong at the post processing stage, which isn't covered.

Mostly I need a specific scenario that reproduces the error.

BTW: are you using a pre-queue script?

Heh, I do wish I could provide full steps to reproduce it.  I did look through the logs to see if I could spot anything for post processing that I should have included in the email, but didn't find anything.

No pre-queue scripts.  Or post, for that matter.

The affected files would probably have been paused and resumed the next day via the scheduler, but that seems a bit of a grasp.

I still have a number of TOO LARGE / jobs queued, I'll see how they behave.  It may be that this one will just need to be written off as "one of those things" until more details come to light.

Experience learned me that there's no such thing as "one of those things".
It happened and it happened for a reason.
Maybe it's a very unusual scenario or a race condition (less likely in this case),
but it will happen again to someone.
I'll do some more checks over time and should you encounter it again,
please keep me posted.