I find that, especially with daily shows, like Kimmel or Conan, the NZB filename is very, very long, and since I have a two-level folder structure for my processing in SAB (SAB-Folders/SAB-Complete-TV) that the completed download fails to unzip due to the filename / folder name are too long.
I then have to go in and manually unrar the archive, renaming the extraction folder to something much shorter (like Jimmy.Kimmel.Live.2016.06.20) and then place that folder in my Drone Factory folder for it to be picked up.
Since SAB supports the option to rename a NZB/Job while it is downloading, can Sonarr offer this as an option - a checkbox to auto-rename long jobs to something much shorter, please?
For example, this was one of the recent failures due to the length of the NZB Filename:
Jimmy.Kimmel.Live.2016.06.20.Jeff.Bridges.The.Bachelorettes.Bad.Chad.Garbage.720p.AMBC.WEBRip.AAC2.0.x264-monkee
SAB 1.0 added support for long file paths: https://sabnzbd.org/wiki/introduction/known-issues#toc3 Previous versions cna trim the folder length automatically, but the problem with shortening the folder name is the loss of quality information from name which will cause Sonarr to detect it as the wrong quality.
Sonarr trimming the name would have the same issue unless it sufficient effort was done to have it strip out the superfluous information only, which I don’t see being something we want to commit to at this time.
I don’t believe it’s a SAB issue. I believe it’s a Windows File Name Length issue related to the folder depth.
Maximum Path Length Limitation
In the Windows API, the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is “D:\some 256-character path string” where “” represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)
So in my example NZB file (which is a real NZB file) this would be the full path that it is attempting to unzip to:
So the release I’m running, SAB Version:1.0.3, which does appear to have issues with long filenames, as it is what generates the error when it attempts to process the example NZB file. I guess I will have to bring that to their attention.
Thanks for the heads-up. I’ve made the change. This alteration to the naming scheme only affects the folder path, and not the final filename? Just want to make sure Sonarr still picks up the file.