snmememe Posted August 13, 2009 Share Posted August 13, 2009 BitComet 1.14 ADSL2 Billion 7404VNPX UPnP WinXP AVGFree 8.5 I have observed that attempts to exercise time based control of up or down bandwidth use via the scheduler produced no noticable change in rate behaviour. The rates still apparently followed the settings appearing in the first Connection option dialog. Curiously, in an experiment to use a "turn off" period in the scheduler did result in tasks becoming stopped and restarted upon applying such changes. Also in a cursory test, the onset of a "turn off" period did trigger as expected, correlated with the system clock. Link to comment Share on other sites More sharing options...
KurtF1 Posted August 15, 2009 Share Posted August 15, 2009 (edited) have the same problem too with this new version Edited August 15, 2009 by KurtF1 (see edit history) Link to comment Share on other sites More sharing options...
sophia0316 Posted August 18, 2009 Share Posted August 18, 2009 BitComet 1.14 ADSL2 Billion 7404VNPX UPnP WinXP AVGFree 8.5 I have observed that attempts to exercise time based control of up or down bandwidth use via the scheduler produced no noticable change in rate behaviour. snmememe, have you limit the upload and download rate in "Scheduler settings"(Options->Advanced-> Scheduler)? If you keep the default settings, that is, keeping all rate as unlimited, then the rate will not have obvious changes, or other words, it will make no difference between high speed and low speed. Link to comment Share on other sites More sharing options...
snmememe Posted August 18, 2009 Author Share Posted August 18, 2009 snmememe, have you limit the upload and download rate in "Scheduler settings"(Options->Advanced-> Scheduler)? If you keep the default settings, that is, keeping all rate as unlimited, then the rate will not have obvious changes, or other words, it will make no difference between high speed and low speed. I am familiar with using that dialog from prior versions. My settings were not default, but quite deliberately set, and further altered, with no attendant change in observed rates. For example, from near idle conditions, after Applying scheduler up and down limits of 10KBps, within a few seconds of starting a torrent the observed rate was about 100KBps in both directions, and continuing thus, which corresponded to the connection dialog settings with the scheduler disabled. I emphasised "continuing" above because I have been aware in past versions of mystifying rate behaviour upon attempting to alter settings in this area, as if the desired rate didn't take effect for quite some time, or perhaps didn't work if I pressed OK without first pressing "Apply", but I haven't attempted to clarify this. Are you finding that under 1.14 the scheduler rate settings do have affect for you? Link to comment Share on other sites More sharing options...
The UnUsual Suspect Posted August 18, 2009 Share Posted August 18, 2009 Hi, Since this has worked for you in previous versions, lets do some basic things to make sure you don't have some old configuration files that don't like the new version of BitComet. Please record all your preferences and uninstall BitComet. I then want you do delete the bitcomet folder in your "program files" folder, and if your using a windows version that supports user account controls, you'll need to make sure the configuration files are deleted form the folder that stores them. For example, in Vista this will be (default location) c:\users\*your name*\AppData\Local\VirtualStore\Program Files\BitComet (running a good registry cleaner wouldn't be a bad idea at this point) Now that BitComet and all configuration files have been removed, you can install the latest version and set your preferences, then test to see if the scheduler works as it has in the past. I have tested the scheduler in 1.14, but only very basically, I haven't had the time necessary to monitor it for hours/days with active tasks running, but it seems to work for me. Link to comment Share on other sites More sharing options...
snmememe Posted August 19, 2009 Author Share Posted August 19, 2009 Since this has worked for you in previous versions, lets do some basic things to make sure you don't have some old configuration files that don't like the new version of BitComet. In response to your recommendation for a uninstall/reinstall... I broke my system volume RAID mirror, again confirmed the scheduler uncontrolled rate behaviour, uninstalled, rmdir/s D:\program files\bitcomet, reinstalled. Again I quickly observed that setting all scheduler rates something like 10KBps, shortly after starting a task the rates were significantly higher, for example 45 down 90 up. I repeated the uninstall and reinstall starting from C: rather than D: with similar results. From your description and fishing about I observe that the bitcomet.exe is not requestedExecutionLevel level=asInvoker, relying on settings in the installed directory file bitcomet.xml. However I am using a pre Vista system and therefore the Vista virtualization hazards don't arise. Something else: During this process I was able to confirm another issue, which perhaps doesn't deserve another forum thread. Starting with all the scheduler rate settings unlimited, if I assign "High speed download limit" value 4, I then observe the new element in bitcomet.xml: <SchedulerDownloadLimitLow>4096</SchedulerDownloadLimitLow>. Then after opening the scheduler dialog again, I find instead "Low speed download limit" has value 4. A similar muddle is observed when assigning to "High speed upload limit" with the value 6, turning up the element <SchedulerUpdateLimitLow>6144</SchedulerUpdateLimitLow>, then upon scheduler dialog reopen the value shows in field "Low speed upload limit". Link to comment Share on other sites More sharing options...
gavin.wang Posted August 21, 2009 Share Posted August 21, 2009 yeah,it is a bug in 1.14. it will be fixed in next version. Link to comment Share on other sites More sharing options...
Dodgey Posted September 21, 2009 Share Posted September 21, 2009 yeah,it is a bug in 1.14. it will be fixed in next version. so can it be fixed manually? Link to comment Share on other sites More sharing options...
gavin.wang Posted September 22, 2009 Share Posted September 22, 2009 TO Dodgey: it is fixed in 1.15 beta[20090917]. sorry ,can't be fixed manually in 1.14. Link to comment Share on other sites More sharing options...
Recommended Posts
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now