BitComet Crashes After Completion of a Task

[DIABLO]

I don't recall from which version of BitComet this issue popped up. It surely was there in v 1.26, today I upgraded to 1.27 and the same story continues.

I had enabled 'Move completed tasks to' (another folder in the same partition) option and since some time, whenever a task gets completed successfully (DL only) the application simply crashes with error report option, and it restarts. Moreover, sometimes the completed files are marked with that yellow triangle with an exclamation mark, saying 'some files are missing' (a false positive, I got EVERY single file that I intended). Thing with this 'restart' is that the whole queue gets disabled, and unless am around to check and kick-start it again, no DL/UL will commence :(

Is this a bug ? Not that it is a BIG deal leaving the completed files as they are (disabling the 'move' option), but it was quite a useful thing to have.

Last but not the least, does it have anything to do with the free space in that partition ??

-Thanks-

[The UnUsual Suspect]

First thing, please disable moving the completed files and see if the problem persists.

As for the free space, it's very possible that Windows operating system objects to moving (for example) a 1gB file if there isn't 1gB of free space available.

If the problem isn't present with out the option to move completed files, then try turning the option on and make sure you have enough free space to accommodate the file being moved. Naturally, moving a file within a partition can be done by simply readdressing the harddrive space to a different folder, but in some cases windows will actually write the entire file, confirm it's integrity, then delete the original. I've seen it display this behavior when cutting and pasting files from one windows explorer window to another, even if in the same partition. I can't explain why it does this, you'd have to ask microsoft, but it may have been an older windows version I experienced this condition on (perhaps XP?).

[greywizard]

What's your OS?

[DIABLO]

@ The UnUsual Suspect & greywizard

Sorry for not mentioning the OSs that I was using. I'm using multiple OSs on two PCs, Win 7 & XP SP3, both showed the same issue. And as far as the free-space left on the partition, there was about 7 GB or so left, when the application was trying to move a file nearly 3 GB in size (no compression enabled too). And in case of moving files, the OS always reserves space and still uses the buffer/temp to cover a possible interruption. Considering THAT fact too, things do not add up.

If I disable the 'move to' option, things are fine. Now I got to check the .BC extension to pin-point the finished DLs (without turning the application on). I guess after moving, BC is unable to track the file (somehow) in order to seed. I get the audio & pop-up alerts on the successful completion and BANG! application crashes (leaving the file in the default directory itself). I tried disabling & removing PC security tools (NOD & KAV on each machine) along with turning the firewall off.

Is it a bug ? I didn't find anything similar in related threads. Should I go with a fresh installation after cleaning the traces ? I just upgraded the application this time, you know. I'll also try rolling over to an older version.

Anyway, thanks for the help. Been using this awesome piece of software since 2006, and am seriously satisfied with it's performance (and the OL support!). Apart this lil thingy, everything else works perfectly in both OSs (Logging in, auto shut-down, seeding, scheduler, everything)with no tweaked advanced options.

Edited May 1, 2011 by DIABLO (see edit history)

[The UnUsual Suspect]

Are you using a very large disc cache size? also what is the amount of installed RAM memory, and is either computer using the x64 bit version.

[DIABLO]

Have not tweaked the def' cache size on both machines. One is equipped with 3 GB DDR 1 (533) & other with 3 GB DDR 3 (1600); and so on 32b OS in both cases. I had a file copying assistant (teracopy 2.12) installed in both machines, tried uninstalling that too even though BC uses the windows def' copying agent.

Did uninstall the v1.27 y'day. Will try rolling over to 1.25 & then 1.26 and will post the result. Also will do a surface scan on HDD & use another partition to move. Thanks.

[The UnUsual Suspect]

ok, it would be nice to track this down, as we haven't seen it before.

[DIABLO]

:mellow: I guess I found the cause (I think !)... after every possible routine checks showing no issues in related area, I simply used another HDD (partitioned by OS) and went with the 'move' option in BC. And guess what, no issues there ! What (I think) I did wrong was I used partition wizard in both cases to 'merge' two partitions when I was running out of space. That is the only possible reason that I can find.. And with the new HDD (not new, simply partitioned without the assistance of PW) no sign of the old error message (at least nothing yet). Though, one thing I forgot to try is defragmenting the 'save' directory.

Will try downloading something big with the 'move' option enabled. Thanks for the assistance.

Edited May 4, 2011 by DIABLO (see edit history)

[The UnUsual Suspect]

It's always wise to scan and defrag your data after changing partitions on a drive.

Thank you for reporting this, it may help others with the same problem.

[DIABLO]

Pleasure is all mine.

But I still wonder if that merging was the real culprit. As you mentioned, the fragmentation could have been the one behind the issue, as even with ample free space shown, that partition had 79% of fragmented files. I didn't bother to defrag thinking that as am downloading (multiple)torrent files, defrag might not do anything good. Anyway, thank God it is ok now kz I just love this 'move finished files' option :lol: Bye.

[The UnUsual Suspect]

winchestr3030, Please make your own topic after reading the link in my signature. Also, please don't type in ALL CAPS, it's rude and considered to be "SHOUTING", it's also more difficult to read.

ps. on another note... I never did care for that round, one thing is that they are often "tube feed" so you can't use a pointed bullit or you can chain react, causing damage to the gun and the poor soul holding it. The .308 is the same caliper and is much more powerful, and is available in many fine weapons, both bolt action and semi-auto, or even the trusted 30-06, somewhat larger but still used after over 100years. My personal favorite is the 338 Lapua though, it give a range close to that of the 50bmg, but more accurate and unlike the 50bmg, is actually possible to fire from a hand held weapon with out use of tripod/bipod, or risking injury to the shooter. I have both though.

[zaknalfein]

I too get the constant crashes after a task is completed, it normally happens when the task stops and goes into auto hash checking. I'm running win7 home premium 32b OS AMD athlon duo core 2.5g, with 3g ddr2 mem and got over 162g free of drive space, I do not use a file mover as it goes directly into a seprate folder on my HD. I too have noticed this problem since 1.26. The compu is 6 months old and I always check for HD problems and have an auto defrag using Norton 360 and various other programs in my pc I have installed. Could this possable be related to the emule plugin? Any advise would be welcomed thanks

[The UnUsual Suspect]

I don't think emule would cause this. I use emule plugin and never seen this issue, however it would be easy enough to disable emule as a test.

I'd also try using a different download location. Try the default c:\downloads, or perhaps in your "my documents" folder, see if this makes a difference.

The only known issue with crashing on 32bit version is related to extremely large disc cache size. If you're trying to stop repeated harddrive read/writes by using an abnormal disc cache size, then you should get the 64bit version, it's ideally suited for this (note that it's a windows operating system limitation)

[zaknalfein]

I tested many configs over a week and I am happy to say Bitcomet is working perfectly no more crashes on auto hash checking, Emule wasn't the cause of the crash you was correct my disk cache size was musch to big I believe when I downloaded and installed 1.27 it was set for 50 my cache size is 32 for my sata drive so i set it to 30 and it solved the problem. Perhaps the install or my pc confused the disk size cache and set it for 50. Any how thanks for the advise

[The UnUsual Suspect]

The disc cache size you select depends on many factors. In most situations, disc cache is kept small and is only used to lighten the load on your harddrive, but in some extreme cases, users who have a computer dedicated solely to running torrents may want to have their torrents operate primarily within the disc cache, which means your disc cache size would need to be equal or greater then the sum of the tasks being run. With a 32bit app, it's "total" amount of memory it can address is 2GB. BitComet would never need so much memory, but if a user wanted to force a huge disc cache size (our analysis of crash reports have shown many users are doing this), then it is possible to reach this limit resulting in an unstable condition. The 64bit version of bitcomet doesn't have this restriction and can support disc cache sizes upto 16GB.

As to why your system became unstable with only 50MB disc cache is unclear. Assuming you have enough installed RAM memory, you should be able to run a much larger disc cache, but since your problem is resolved, I'll close this topic, since it appears the original author has abandoned it.