#Tracker update error vuze Offline

But it still tells me to increase the concurrency. Notice I didn't go all the way down to 25, I used 128, down from the 1024 before. Tried the numbers you suggested, here is what it looks like: (Along with not scraping inactive torrents.) My stats graphs always look about like Ok, I am getting this again. Personally, I use 15 seconds for the connect timeout, 35s for the read timeout, and a concurrency of 25.

#Tracker update error vuze Offline

Short timeouts ensure that busy trackers or ones that are having network connectivity issues can be treated the same as offline trackers, and passed over in favor of more responsive ones. The whole point of having multiple trackers for each torrent is that connecting to any one of them is unimportant - there's always the next one on the list. I'd probably drop that way, way down - if a tracker isn't able to respond to a connection attempt within a few seconds, even if the connection would eventually succeed, it's probably so overloaded (or having other issues) that you're better off just bailing on it and moving to the next one in the list. With that kind of window, every attempt to contact an unresponsive tracker is going to potentially delay a subsequent connection to a working tracker by up to 120 seconds. 'Manage tracker activation to reduce load' could also possibly help (though I don't know if that will affect scraping at all).Īlso possibly related: Two minutes is an incredibly long connect timeout. If you have a significant number of inactive torrents (and it seems you do, specifically all of the torrents in various 'Queued' states), there's not a lot of value to scraping them all. I'd probably start with turning off 'Scrape torrents that aren't running', personally.