altbinz keeps on downloading until hd runs out of space

[icecube]

Okay, so this bug happened to me a few times so i figured I would report  it. Im downloading a ~800meg file and I leave it running while I go eat. I come back and my harddrive is completely full. When I go check my download folder, the ~800meg download is actually like 10+ gigs. Its like altbinz keeps on redownloading the files until disk space runs out. And all the extra downloaded files have many x's attached to the end.

Check the screen shots:






And here is the entire log:
http://rapidshare.com/files/32103171/20070518.zip.html

[snuf]

I have the same problem, i fixed it by letting altbinz delete the nzb file after importing it or else altbinz will import it again and again

greetings

snuf

[madshi]

I have this problem, too, but I'm quite sure it has nothing to do with that alt.binz would redownload the files. It's a different problem. In fact everytime these "something.blaxxxx" files appear, the decoding has f*cked up. I can sometimes see it happening:

Normally the decoding progress bar runs through and afterwards the just downloadeded file gets deleted from the download queue. However, sometimes the decoding stops at e.g. 30%, then starts again from the beginning. This time it goes to 40%, then it starts again. Everytime the decoding restarts, a new "xxxx" file is created.

Next clue: Everytime such an "xxxx" file is created, the previous "xxx" files including the "correct" file without any "xxx"s cannot be renamed, anymore. This can be fixed only by restarting alt.binz. In such a situation repairing and unraring also fails, because alt.binz itself can't open such files for writing, anymore, either.

Next clue: Normally there's always only one "decoding" progress bar at a time. But now and then I'm seeing two bars. One bar is stuck, the other one is running. I think that's not as it was intended.

I think there's some kind of timing problem or some kind of thread synchronization issue or some kind of file handle leak, which is causing all these problems. It has nothing to do with the anti virus software. It happens with AV disabled, too. However, the problems seem to increase if I run a full screen DirectX game while alt.binz is downloading. I may be wrong with that, maybe the game doesn't hurt alt.binz, it's just my impression.

This is about the only thing the troubles me when using alt.binz. Apart from that it's great!

[bcabinz]

Haven't have this problem, but a couple things to check that could be the cause.

1. If you have auto import nzb checked, make sure your import nzb dir and your default (forget the name) nxb dir are different directories.

2. Check the box to pause import of files previously imported

3. Set the option to remember the last so many files downloaded (related to number 2 above)

[koomwah]

I've been having this problem as well. After a bit of searching I think this is related to a previous problem with decoding files that was solved by making sure the alt.binz temp folder is in the excluded list on your av program. So far this seems to have worked for me, I'll let you know if the problem reoccurs.

[madshi]

Yeah, I have noticed in the meanwhile, too, that it is affected by the AV software. If I disable AV, this problem doesn't seem to occur that often. However, I'm quite sure that I saw it happen at least once with AV disabled.

[madshi]

Ok, being a programmer myself, here are a few thoughts about why this problem could happen in the first place:

(1) I think alt.binz opens a file (let's call it file "A") with write access, then it writes something to the file, then it closes file A again.
(2) The AV software sees what alt.binz has done and thinks: "Oh, file A was modified, so I have to check if there's a virus in that file now." So of course the AV software now opens the file with read access (probably with FILE_SHARE_READ/FILE_SHARE_WRITE set) and reads it.
(3) Before the AV software is done with checking the file, alt.binz decides to open file A again with write access, to do some further manipulation to the file. But opening the file with write access fails, because the AV software has already opened the file and alt.binz probably doesn't use FILE_SHARE_READ.

Of course I'm only guessing. But if I'm right with these guesses, I've two suggestions on how to solve this problem:

(1) alt.binz should use FILE_SHARE_READ when opening files for write access. This should already fix the problem, I think.
(2) Additionally, alt.binz might want to keep the file handle open, until everything is done. This should also fix the problem. And it should also improve decoding performance as a side effect.

One thing however, I don't understand: In this situation when opening the file for write access doesn't work, alt.bin seems to leak a file handle to file A. At least nobody can rename/change the file, anymore, until alt.binz is closed and reopened. Don't know why that is happening...

[nl05369]

I'm also having the same problem. Alt.binz ate 106GB (one hundred and six gigabytes!!!) by re-writing the same rar file to the disk again and again adding an "x" to the extention name each time.
I also am a registered user of the program "Usenet Explorer". I used this to look at the problem files online, and the files that keep being written to disk are incomplete RAR sets (they are missing one or more parts). Usenet Explorer downloads them fine, and shows the incomplete RAR files clearly as incompete, but it seems that alt.binz has a problem with them.
Dunno if this helps.... has anyone heard from the makers?

[Varg]

this has happened to me as well...but not as severe as 100gb or more lol will this be fixed in the next version of alt.binz (any release date planned)?

[nl05369]

Hello,
I've been checking the log of one of the RAR files that gets "xxxx etc", and this is what I see:

1) The download finished OK:
[6/2/2007 9:37:00 AM] [T1] Article finished 201/201 Piet Piraat.De Viking.part035.rar

2) ALT.BINZ gets "Exception Access Violations" for certain memory addresses, and the memory addresses increment:
[6/2/2007 9:37:00 AM] [Dec] Exception Access violation at address 00403F30 in module 'altbinz.exe'. Read of address 00000033
[6/2/2007 9:37:00 AM] [Dec] Firstpart=1;NumOfParts=201;Encoding=Yenc;fsize=50000000;fname=Piet Piraat.De Viking.part035.rar;Outputdir=D:\DVDs\Piet Piraat - De Viking;OutputdirExists;Size=50000000;Expandingfile;FreeSpace=26784514048;TempFileCreated;1;2;3;4;5;6;7;

3) The last "Exception Access Violation" occurs for the RAR file:
[6/2/2007 9:37:34 AM] [Dec] Exception Access violation at address 00403F30 in module 'altbinz.exe'. Read of address 0000342F
[6/2/2007 9:37:34 AM] [Dec] Firstpart=1;NumOfParts=201;Encoding=Yenc;fsize=50000000;fname=Piet Piraat.De Viking.part035.rar;Outputdir=D:\DVDs\Piet Piraat - De Viking;OutputdirExists;Size=50000000;Expandingfile;FreeSpace=23534235648;TempFileCreated;1;2;3;4;5;6;7;8;9;10;11;12;13;14;15;16;17;18;19;20;21;22;23;24;25;26;27;28;29;30;31;32;33;34;

4) ALT.BINZ reports back completed.
[6/2/2007 9:37:47 AM] [Dec] Yenc file Piet Piraat.De Viking.part035.rar decoded in 12250ms

If I use QuickPar (0.9.1) to check the relevant RAR file, one of the parts is correct (normally one of the xxxx parts).

Hope this helps the programmer.[/b]

[bcabinz]

see this post:

http://www.altbinz.com/forum/viewtopic.php?t=546

For one user, it was related to directory length.

[nl05369]

Thanks for the idea bcabinz, but this is unfortunately not a solution for me. The base path length of my files is 8 (including colons and slashes and the disk), and for the specific case that I posted, the total length of the path including the rar file name is 73 which is way under the XP max.

[CrashOne]

I've got the exact same problem, alt.binz just used over 100G of mij HD.
This problem has never occured before, but sinds yesterday alt.binz keeps getting "Out of system resources" errors and duplicate filenames.

[nl05369]

okay,
since I told my antivirus (Kaspersky) to ignore alt.binz, the problem has almost not occured again (once, but only in a very minor way). So it's not solved, but massively improved by stopping the antivirus software from sticking it's oar in.

[madshi]

I'm still getting it with AV disabled. Not as often, but it still happens...