• Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About btarb24

  • Rank
    New User
  1. Hi Harold. I haven't tried that. Though, during a Check my CPU utilization is only at 2%. The bottleneck is the network @ 90 mbps. Will the setting change still apply to this situation?
  2. 1. I queued up roughly 20 jobs. They all were pointing at an existing ~10gb file that they were going to check and then repair any incomplete pieces on. 2. They were all started. 3. Each job(except for 1) was in a state of "Checking 0%" while they waited for their turn to do their check. The process of checking a file takes 10-20 minutes, so the queue takes a long time to complete. 4. The app was behaving strangely so i closed it. (for description of strangeness see: ) 5. I reopened the app 6. Any files that were presently downloading were resumed. Files that were in a 'Checking' state came up as Stopped. There's obviously the minor inconvenience of having to start the ones that didn't resume their state. Though, there's a heftier problem. We cannot Force-Check a job that's started. We cannot start a job that's checking (if you tell it to start it will still go into a Stopped state when it's done checking)This means that in order to get back into your prior state, you'll need to begin a Force-Check on each job and then wait until they're done checking in order to start them. in the case where the files are stored on a network drive the checking process will take 20 minutes per file. It would be nice to alter one of the rules i bulleted above so that a job can be Started AND Checking without having to delete and re-add the job.
  3. I had a bit of corruption on my unRaid server so i'm now going through all of my video files and using BitTorrent to re-check the files and repair the corruption. The workstation communicates to the unraid server via 802.11AC. My throughput ranges from 80-120 mbps. I have been queuing up 10-20 torrents and telling them all to recheck against the files stored on the unraid server. The files average about 10GB in size. BitTorrent will check one file at a time and while it's checking a file the UI will typically slowdown. In one case it did so to the point of crashing the app. Is there a way to configure the client to do a less aggressive check? Not in terms of accuracy, but moreso in terms of timeframe. It appears that the Check process was coded with the expectation that the file is stored locally. When it's checking over on a remote location it completely saturates the network and slows the bittorrent UI. -the rest of the system is still responsive.