SABnzbd Forums

The excessive naming (and repeat naming) of certain groups makes filenames way too long for windows to handle.

I read that relative has a low max and absolute has higher, but I am using absolute.

Because of this the files are being marked as _FAILED_ a lot, any work around for this other than renaming the nzb length? I don't really see why we should have to rename the length when we want the whole process to be automatic.

Any possiblity for a name crop? not taking the name of the folder from the nzb file etc? What does everyone else do?

Easier said then done...
We'll look into the matter.
Filed as Ticket #139

not taking the name of the folder from the nzb file

That's a bit difficult isn't it?
We could generate a random number, but I'm not sure everybody would like that 

Hate to bump this old thread but I occasionally run into this (user) problem along with pathname length limitation - and it hurts.  I read the assembla ticket and understand why it may never get implemented.  Similarly, if the destination path is too long the file is detroyed when SAB hands the file over to the file system even though the file gets written/downloaded at some point.  SAB knows a problem occurred because an error appears in the LOG.

- How about a checkbox with max filename/pathname input that will truncate filenames/pathnames on final write that are longer than the length in the configuration?  File renaming would have to be stored in the log or history.  The disk error and problem path are already recorded in the log.

- dump just the file or truncated file to the temporary download folder or an error directory.

- add an option to perform another step or call another program to handle the file when SAB knows a disk error has occurred (SAB already logs the disk error).  Then someone could use fastcopy or rar.exe (user-supplied) to maintain full file/pathname.  (Although rar.exe might require file enumeration also)

- Don't delete file on disk error!

Currently anything would be better than vaporizing completed files.  Since it is a minor and user preventable issue even a fix that relies heavily on the user to reconstruct the pathname/filenames by searching through the log file would seem to be an improvement.

Related posts:
http://forums.sabnzbd.org/index.php?topic=1360.0
http://forums.sabnzbd.org/index.php?topic=1151.0
http://forums.sabnzbd.org/index.php?topic=31.0

It will be tackled.
The main problem is finding an acceptable way to shorten the path without ending up with duplicate names.

The problem of saving downloaded files in the temporary download folder is
the most urgent one.
Problems with unpacking in the final folder is more difficult, due to the fact
more paths may be embedded in the rar-files.

Didn't realise someone replied again.

But surely if you truncate a very long folder (better to truncate the folder first rather than the file, surely?) the length left is still going to be almost enough to differentiate between downloads?


It honestly would help if we didn't have to have all this scene tagging in the first place, specially when they duplicate folders inside themselves.


A pre-processing script setup could be nice, a bit like post processing, but before the nzb file is loaded. This would give people the option to build their own functionality for this issue, even having "scene tag" stripping scripts to roughly cut them down.


I actually started something like this to execute nzb files against to copy the nzb into your watch folder and strip some useless crud out of the title, although I got busy with another few projects, and it doesn't help when I load nzb using other methods (saving the file directly, remotely via web interface, etc).

One other open request is a list of words that should be removed from titles.
You'll get what you want, but it will take a while.