Crashes when over 256 characters in queue...

[opentoe]

I'll queue up many things and throw them in the download queue. If I forget to change or shorten the path names of where everything is saved the program will crash when it tries to write. Is there a way to bypass or ship that error and just isolate that particular job not downloaded rather than crash?

Thnks

[FlatulentFox]

Best way for now is to just make your initial paths as short as possible. For example, I put my AltBinz folder in the root of my C drive.  Of course it would be nice if AltBinz would check for this condition and pause the download instead of being all crashy.

[opentoe]

Yea, I have had to do this also. Some people just love making huge filenames on usenet and when automatic downloads happen and it crashes binz it gets frustrating. I've been trying to work around this best I could.

[mano3m]

As I was directed to the requests forum from the bug reporting forum on this issue I'll have a go at a solution:

In my case (with the create subfolder based on nzb name enabled) the issue usually happens when the file I am interested in is already in a sub-directory in the rar file.

Therefore I'd like to do the following feature request:

Add an option to check if the rars contain a sub-directory. If so, unrar directly to download folder, if not unrar to nzb name folder.

Several scenario's exist, like:
 - all files (like .mkv, .nfo, .jpg) are in the subdirectory
 - only the most significant file (like .mkv, .avi, etc.) is in a subdirectory and the .nfo is in the root of the .rar
 - no subdirectories

In the first two cases I'd like to unrar to the unrar folder without any subdirectory created, in the last case I'd like a directory created based on the nzb name.

Hope this helps,

Cheers,

Mano3m

[Hecks]

The fiddly thing is that there are many variables here, and many different use cases.  Some users wouldn't appreciate their dir names being shortened automatically by Alt.Binz, I would imagine, especially if the shortening is needed still further up the path.  And the issue affects download folders differently from destination folders, as the suggestions above indicate.

It's still not a good thing that Alt.Binz falls over so spectacularly in this situation, though. I've said before, but as a minimum Alt.Binz should pause downloading of the NZB and wait for user intervention with suitable warnings.

[MegamanNL]

+1
This has always been one of the few annoying things about alt.binz. It should never crash because it can't create a directory or file. My download dir being C:\Incoming isn't that many characters at all. But some post subjects are just so darn long...

The best solution IMHO would be to check the combined length of what will be the working directory BEFORE the download starts. And if that results in too many characters put the download in a paused or error state. That way the user will know that there is a problem before the temporary directory is flooded with un-decoded parts, the collection is ruined and the application eventually freezes or crashes...
It could optionally shorten the subjects automatically is the user wants it to.

[Rdl]

As a first step dealing with this problem, I've implemented maximal download path length variable (setup->Download) Default value is 200 (characters)
When importing/renaming/changing download folder of the collection, length of the path will be checked. If it is longer then variable, warning will popup and collection will be paused.

Dealing with filenames is next step. Just remember filename is not known before downloading (subject is irrelevant). Any thoughts on that subject?