Stay on decoding 2.6 version

[Gnafron]

hello,

within the 2.6      I got the following problem...

Downloading Ok
and when it starts to decode... it's stay to decode for a while... :cry:

the history shows the message " too long file name "...
here is the name: (I replace the real letters by false   )
"[XCT].xxxxxx.yyyy.uu.xxxx.(nnn.nnnnnn.mmmmmmmmm).
[xxxxx.bb-ccc{Fr-Eng}.Subs{Fr-Eng}.Chaps.Covers].-xxxxxxxxxx.fr.st-.part.sfv" [01/36]

is that too long?
directories were
e:\dwld\undone\....

I solved the problem by finding same files but with other names (shorter of course...) :?

thks for your help

[cr4zyfr4g]

to long file name means the complete path is too long.

do you have subfolders active? then try not to use them

[Gnafron]

thank you cr4zyfr4g  

"crazy frog"?  beware we, in france are frog eater  

what is the longuest name we could have?

my complete name with subfolder were (as I wrote) :
e:\dwld\undone\[XCT].xxxxxx.yyyy.uu.xxxx.(nnn.nnnnnn.mmmmmmmmm).
[xxxxx.bb-ccc{Fr-Eng}.Subs{Fr-Eng}.Chaps.Covers].-xxxxxxxxxx.fr.st-.part.sfv

it was certainly too long , but of what?
wwwhat's the maximum length?

tnks

[Rdl]

I didn't have any problems decoding those with same path you used. Are you sure you didn't used NZB name as subfolder option?

[Hecks]

it was certainly too long , but of what?
wwwhat's the maximum length?

tnks

For Windows, the maximum (non-UNC) I believe is 255, of which the path portion must be less than 248 characters.  Someone less lazy than me can look it up.

-Hecks

[stingbat]

Have also seen this issue. Allthough for me, after a while, ABZ craches! :-/

Will post a screendump + sample.nzb in private, Rdl.

[Rdl]

All that is known issue. It could be detected before raising error. The real question is what to do in that case? Dump files to c:\ ?

[Hecks]

Truncate the name of containing folder? i.e. last part of path, longnzb~1/filename.avi?

-Hecks

[stingbat]

Either do as Hecks says, or simply truncate the filename.

As for the example you got from me, the filename was about 240 chars (as far as I remember). Have no clue why the person had uploaded such large filename, which I find rather stupid.

Anyway, as you could see on the screenshot, it would be nice with at least some "limit" on repeating the error - got huuuge logfiles, due to that ;-) + the crashing part

[SamSwashbuckler]

Subfolders shouldn't need to be disabled.  It's true that people shouldn't post things with names that are stupidly long, but it happens quite a lot, and the program should be equipped to handle it properly. 

This is a pretty serious problem, and fairly likely to happen, especially with the long default download path (C:\Program Files\AltBinz\download) so IMO it should be fixed ASAP. 

I talked in IRC and got a few pointers from Hecks:
Check your log, if it's too large to open, try this: http://baremetalsoft.com/baretail/
You can use this program in C:\Program Files\AltBinz\temp to decode the files: http://www.celebritypwn.com/altbinz/ManYencDecode.rar (you should probably have altbinz closed)

Hope this helps someone.

[Hecks]

A simple workaround while we wait for the check to be implemented is to change the NZB filename to something shorter as you import it.

P.S. As a sidenote, I've been using Alt.Binz for over a year and have never once experienced this problem.