Jump to content
Comet Forums

Tin Ching

  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About Tin Ching

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. There is a chance your files are hashing due to an improper exit of the program, i havent upgrade to 1.68 so not sure 1.68 has an issue. If theres no hashing, i cant explain why it will slow just starting a task. If this is the case, u need start one by one as hashing do intensive reads.
  2. Also, you may want to set this to a lower number, as the default (1000) is way to high! Setting this too high will jam your Internet connection.
  3. If all your files are on an SSD drive, way to go! There shouldn't be any more hang.
  4. It has nothing to do with the RAM and CPU, we are on top end machines with heaps of RAM and CPU. You can try this option, I've managed to solve the hang issue. Go to Advanced settings, and set this to true. No more hanging on my machine, and the XML files each is less than 1MB as it will only save those peer IPs that is connected to you. With SSD and heaps of RAM, it won't even cause my machine a sweat.
  5. Just tried v1.67, still have freeze when it writes the current tasks into the xml files. I saw the changelog some other torrent history xml file got migrated to sqlite, I wonder if they can do the same for the current active tasks as it may help to remove the freeze.
  6. Nah, I think this is a software issue, not hardware, particularly relates to the algorithm/architecture of how these XML files get read / written. The UI freeze is when the program started triggering the xml writes (but hasnt actually started writing to disk yet). During this time its busy doing something else which I'm not sure what it is, could be busy gathering all the peer IPs and writing to memory. I would say if this issue gets fixed, most of the UI hang bug tickets in the past would be solved.
  7. Attached below is screenshot of 2 large xml files causing UI to freeze at regular intervals.
  8. Yeah, even we have a very powerful machine, but the current architecture of BitComet is not scalable. The xml config file writes is killing it.
  9. More details: - A lot of users in the past has mentioned the UI freeze every 5 minutes, this coincides the every 5 minute writes for the task xml config files - Users also mentioned they get the freeze if you have enabled DHT, this is because you will find a lot more peers if you enabled DHT, and this will bloat up the xml config files In my opinion, this is the most critical performance issue for BitComet. Why? BitComet writes these files every 5 minutes, but it doesn't write them all at the same time, it writes one by one. As time goes on, the time gap of each write of file increases and spread to different times. Imaging you have 5 torrent files like this and evenly spread across, on average you will get a GUI freeze every minute. If you have 10 files like this, you will get a freeze every 30 seconds on average. This will make the program hardly usable. During the time it freezes, all uploads/downloads will be jammed/halted (goes to 0) Possible solutions: I do not think writing these xml files is time critical. - Write these xml files in it's own thread separate from the GUI, or - Maybe have an advanced option where we can adjust the auto save frequency? or even have the option to only save these files upon closing the program.
  10. BitComet UI not responding A lot of users has already brought this up, but I think so far no one has located the root cause of the issue. I personally experience this issue and have dig deep into the root cause of the issue. Some user may not have experienced this and it really depends on how "popular" your torrent file is. The torrent file I download has 15,000+ users in the network. Every 5 minutes exactly, BitComet writes xml configuration files for the tasks into the AppData folder. Two of my files in my download list has 15,000+ users and this is where BitComet UI freeze up during the time it starts writing these gigantic xml files (each 150MB+ in size). This causes the UI freeze for 30+ seconds. Can these config file writes to be put into a background thread so that it doesn't freeze the UI? Same applies to program startup, BitComet reads all these xml files which makes the program unresponsive. I can also confirm that the freeze is not coming from a disk bottleneck, as my hard disk is an SSD drive and disk activity is very low, I suspect the UI freeze happens when the program writes the XML data into memory OR it's busy gathering all the info for the task (e.g. peer IPs etc) I hope this helps the community, and the info I have provided should allow the issue to be easily reproduced.
  • Create New...