When the TRACKER tab is changed by deleting a tracker, BitCommet automatically refreshes the tab by re-scraping all of the remaining trackers immediately.
I request that this refreshing behavior not be done anymore, and that the client instead wait until the next regular scheduled scrape of each tracker.
Refreshing erases the response data which is often needed when one is deleting unresponsive trackers.
Lately, torrent creators are adding in a corresponding UDP tracker url for every http tracker that they list. However, most trackers do not support UDP, so these urls result in a no-response error.
When deleting a non-responsive tracker, the automatic refresh makes the responses for the remaining trackers disappear. It’s necessary to wait until the refresh for all of the trackers occurs (needlessly hammering the valid trackers) to see the remainder of the unresponsive urls.
Instead, the list should not refresh itself when a tracker is removed. If the user desires to refresh the list he can do that manually.
I’m just curious but, what is the purpose of this behavior anyway? There’s an “Update tracker” option that does this too. It looks like an unnecessary duplicate to me.
@ Kluelos: Yes I agree with you, the remaining trackers should not be refreshed when one tracker is deleted. This issue has been reported to the development team. Thank you.
I doubt very much that it has a purpose, Wiz. It think it just comes from re-entering the routine at an inappropriate point, but which may be the only entry point that exists.
The method that redraws the window comes right after the method that gets the data from the trackers. If that’s all one method – get the data and redraw – then this would produce what we see.
If refreshing is necessary because of the way bitcomet is designed, then perhaps a “tracker edit” function, where you can remove whichever you like (or add), then when you save the changes, only then will it refresh.
