Abnormal CPU Usage & Cant Exit Properly

[Stavr0s]

Hi,

I recently upgraded to 0.24.2 and have currently got 6 things in queue, and 1 active, as soon as i started using this version i noticed my pc was beginning to struggle so checked the cpu usage, and here i believe lies the problem
screenshots http://www.matrixed.myzen.co.uk/Screenshots/Alt.Binz/Alt%20Binz.jpg & http://www.matrixed.myzen.co.uk/Screenshots/Alt.Binz/Alt%20Binz%202.jpg

also when exiting i cant actually do a normal exit without killing the process & at this stage the ram is at 75mb

any suggestions appreciated

and of course if u need more info let me know

thanks

Stav



nevermind gone back to the old one as no one seems to want to reply, all is stable again

[Varg]

is alt.binz by any chance repairing or checking the files?

[malefactor]

Same problem here.  New user, not familiar with this.  Maybe you should have a "what's going on now" screen or similar so that the user can figure out what's actually happening.  I see tons of memory being chewed up, 90% cpu usage, but no clue what's happening.  

In some download directories I see:

FILENAME.rarx
FILENAME.rarxx
FILENAME.rarxxx
FILENAME.rarxxxx
FILENAME.rarxxxxx

... etc.  It seems like the app is in a chasing-its-tail loop of creating these with little to no purpose?

I have a rather large file that could be being worked on in the queue.  Currently it is in an unusable metastate.  Fully downloaded, not in the completed download directory, but nothing apparently happening.  I don't want to lose this file, but I'm not sure what to do now to force it to complete, unrar, or do something!

[malefactor]

Found & fixed the problem.  You should have a FAQ.

There is a log directory, and altbinz will silently fill it up with hundreds of gigs of repetitive messages, if you let it.  In my case, it was complaining that the overall path length of the file it was trying to decode was too long for XP's (NTFS's) standards.

I suggest you put in some checking / limiting when the user is prompted for the name to enter into the download queue.

[Cryptic1]

I'm having the "too long of a filename" problem myself and was wondering if someone would explain how to work around it.

Thanks in advance!

CJ

[malefactor]

Unless something has happened of which I am not aware, there is no real fix.  

You can alleviate this somewhat by creating a tiny directory name off the root (in my case, E:\a\) that is now your download/decode directory.  Set it up as such in altbinz.

Furthermore, manually modifying (shortening) the names of the files you're downloading (as you add them to altbinz) will also seem to help.  But there are files out there that have such obscenely long names that even both these measures will not fix.

Ultimately this is a 2 line code change to fix.  (ok not really, but close)  We have to lobby our sponsor, more than likely with $ (from recent indications), to get this done.  That having been said I'll do so because I think the program is quite useful, although I'd like to have the source code as part of my donation ;-)

[Hecks]

This is clearly a limitation of Windows/NTFS and not Altbinz.  The obvious solution is to shorten the NZB/collection name when downloading and/or don't name folder after NZB and/or use a shorter download path.  This is all pretty standard stuff for Windows users (same problem with Newsleecher, btw).  I doubt there are many actual files out there with close to 255 characters in the actual filename (where did the poster store it?) - and if there are, they're probably not worth downloading in the first place.

A checking function would be nice, though.

-Hecks

[Jäger]

This is not only related to file names that are too long. There is also a "bug" in Alt.Binz that allows for "illegal" characters (which could have been "legal" if the file was created in another manor).

SO I agree, a check should be implemented soon - AND a measure to ensure that the log file will not frow untill the disc is full.

Another thing is some filename extension check in Alt.Binz that result in the same error. This filename is COMPLETELY legal even in a simple test C program. So it must be an internal Alt.Binz thingy :-)

Example:
(the file and directory in this example can be created - and the "" thing points to a parsing issue in Alt.Binz)

Code: [Select]

[15-08-2007 23:59:57] [Dec] Firstpart=1;NumOfParts=20;Encoding=Yenc;fsize=15000000;fname=xxxxxxxx.xxxxxxxs.xxxxxx.xxxxx.xxxxx.xxxxxxxx.xx.xxxxxx.xxxx-xxxxxx.part08.rar;Outputdir=c:\download\news\#Alt.Binaries.MultiMedia on EFNet Presents REQ xxxxx   xxxxxxxx.xxxxxxxx.xxx.xxxxxx [xxxxxx]  xxxxxxxe.xxxxxxxx.xxxxxx.xxx.xxxt.xxxx.xx.xxxxxx.xxxx xxxxxx.nfo yEnc (11)\;OutputdirExists;Size=15000000;Expandingfile;FreeSpace=74670284800;
[15-08-2007 23:59:57] [Dec] Exception Cannot create file "". The filename or extension is too long

[Hecks]

@ Jäger

It's hard to know what the problem is here, since you seem to have edited the path name in your example to make it exactly 259 characters ...  As for illegal characters, I haven't seen Alt.binz spit any of those out.  Do you have an example?

-Hecks