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.
TOO LARGE filenames
Forum rules
Help us help you:
Help us help you:
- Are you using the latest stable version of SABnzbd? Downloads page.
- Tell us what system you run SABnzbd on.
- Adhere to the forum rules.
- Do you experience problems during downloading?
Check your connection in Status and Interface settings window.
Use Test Server in Config > Servers.
We will probably ask you to do a test using only basic settings. - Do you experience problems during repair or unpacking?
Enable +Debug logging in the Status and Interface settings window and share the relevant parts of the log here using [ code ] sections.
Re: TOO LARGE filenames
It's definitively not the intention to have "too large" as part of the file name.
I'll look into it.
I'll look into it.
Re: TOO LARGE filenames
Well, I cannot reproduce this issue.
Re: TOO LARGE filenames
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.
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.
Re: TOO LARGE filenames
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
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
Re: TOO LARGE filenames
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.
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.
Re: TOO LARGE filenames
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?
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?
Last edited by shypike on June 7th, 2011, 6:13 pm, edited 1 time in total.
Re: TOO LARGE filenames
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.
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.
Re: TOO LARGE filenames
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.
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.