snmememe

BitComet 1.20 ADSL2 Billion 7404VNPX UPnP WinXP AVGFree 9.0.801 Teamviewer 4.1 I upgraded from 1.16 to 1.20 a few days ago, but whilst operating on a largely unattended remote monitored machine, traffic ceased and the process was consuming all available time with no window repainting. Killed the process and restarted BitComet, but the new process continued to soak up all processor time with no window appearing and no traffic. I reverted to 1.16 by reinstallation and problem went away. I had a similar problem some months ago upgrading from 1.16 to 1.17, and sidestepped such a problem by returning to 1.16.

Further observation related to process full busy when mouse over torrent view vertical scroll bar: I have already mentioned that I have had the Status column enabled, without which I might not have experienced the herein described process busy condition. Now I ask, what is special about that column? Without access to the sources I can not be entirely definite, but next consider if any other column can cause trouble. A little experimentaion shows that also the "Down Rate" and "Seed/Peer [all]" demonstrate similar behaviour. I further note that each of these columns can trigger mouse over tips. More than that, among the rows of such a column, not all cells will trigger a tip popup, and is only the occasions of the mouse being over a cell that is a candidate to trigger a tip popup that I have observed the the process going full busy when the vertical scrollbar is occluding. Thus I speculate that the busy problem of this thread is related to orchestration of such tip popups. I further note that when certain window resizing events occur the column widths tend to be resized to fill the horizontal measure unfortunately including the width of the vertical scrollbar. Note that this will tend to place the ultimate column so that is occluded by the vertical scrollbar and thus in jeaopardy of the busy symptom occurring if it happens to be a column that spawns mouse over tip popups. This is like begging for trouble, and why the problem has been so persistent for me. Even if I had sized the ultimate Status column to not be occluded, the next auto resize would make it occluded and thus invoke the full busy symptom whenever the mouse was over that vertical scrollbar. Is this speculation on course, or is there still no one else in the world that has experienced such a process full busy condition? Am I so lonely?

Confirmed that in Safe mode on two WinXP SP3 uniprocessor systems, a painting problem was observed when using the torrent view vertical scrollbar page up/down. The cummulative column width didn't seem to matter. Typically the cell border lines look as if misplaced. I have already reported seeing that in safe mode the process can go full busy utilisation, at least when mouse is over the status column occluded by the vertical scroll bar. The machines are 2000MHz class AMD of different types, plenty of memory, different video adapters, and not particulary busy doing anything else.

Sorry, I misunderstood your drift. There are two distinguishable symptoms that I have described in this thread. Evidently you were more focused on painting for that experiment. From memory the painting was still off when booted safe, but it's not convenient to check such again until a few hours time. The mispainting is evident on two very different hardware WinXP systems. Curiously, in a brief experiment on the above mentioned Win7 system I didn't see painting problems, so far at least. That makes me wonder if it is hard to observe on a multi-core machine.

I have not had any difficulity using the mouse to drag widen a column so as to cause the horizontal scrollbar to appear. Now I've tried yet another quite different machine being a recently built Win 7 RTM. The busy symptom didn't show right away until further experimentation produced CPU busy 25%, which is like one of the four cores saturated. Perhaps the main common similarity among all the machines is me and my choice of columns! At least one way that I could make the busy symptom appear was to resize column widths so as to make the column that is being occluded by the vertical scroll bar to be in particular "Status", also with BitComet being the foreground active process, and mouse being over part of the status column occluded by the vertical scrollbar. I looked back to see that the graphic posted some time ago indeed has the Status column occluded by the vertical scroll bar. Regarding the issue of cell painting subsequent to a vertical scroll bar mouse click page up/down operation, I've found that the behaviour is certainly sensitive to the vertical size of that window. I presume that it matters what kind of remainder results from dividing the window height by the cell height. Perhaps it also matters whether a paint message invalid region becomes lost with the huge amount of message activity, including WM_NCHITTEST, hitting that window proc. Try making small adjustments to the torrent list window height and then reattempt vertical scroll bar repeated page up/down operations.

I can emphasise that the busy symptom when mouse is over the vertical scroll bar does not occur for me if the torrent view columns are chosen so as to occupy less horizontal measure than available in the window, excluding that occluded region under the vertical scroll bar, and thereby the horizontal scrollbar is disabled. I can see that the horizontal scroll bar is properly enabled once the total column width has increased up to the full window width minus the vertical scroll bar width, but the busy problem occurs only after the total column required width has been increased yet somewhat further. If the mouse is positioned so as to be over a portion of a column occluded by the vertical scrollbar the process goes busy. I've been able to observe faulty repainting upon repeated vertical scroll bar page up or down (i.e. clicking in the scrollbar above or below the thumb), even when the columns are chosen so that the cumulative width is much smaller than the available horizontal measure and no horizontal scrollbar is present.

In line with being as helpful as possible, I've booted safe. Now the ProcExplorer report is a tiny bit different; it shows 99% processor time consumed by BitComet when I park the mouse cursor over the torrent view vertical scroll bar, instead of only 75%.

Let me point out that I see similar symptoms on two entirely different systems. I don't agree that from the evidence at hand it can be believed to be a problem of these two systems alone. On one machine at least, if I leave the mouse over that vertical scrollbar the processor usage for BitComet rises from negligable to sit at 75% and all net traffic stops. On both machines all traffic stops with the mouse over that scroll bar. I described the spy reports of repeated WM_NCHITTEST as one form of evidence of somthing foul. This is a message used by software to discriminate as to what kind of locality the mouse cursor is at.

Does lack of response from others imply that my observations haven't been reproduced for others? On this subject, I have also observed that when the mouse is over that View_TorrentList window there is a huge burst of repeated messages like WM_NCHITTEST, despite no mouse movement, as if BitComet is spending all it's energy on such messages and can't progress any real work. There also appears to be quite a large amount of message activity at the time of periodic update, even when little or nothing has actually changed, but such isn't necessarily a fault. Similarly lots of periodic messages for the underneath detail list view.

Stangely, that wiki describes green circle as "BT task is stopped and incomplete"!

Sounds like you've reinstated some of your torrents, but they don't know about the portions already obtained? If that is so, perhaps you want to ensure that when you create each task it is associated with the place where your existing download files exist, and use right mouse->Manual Hash Check, which will assess which parts are missing.

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".

Issues continue same in 1.14. Strangely, I have come to utilise placing the mouse over that View_Torrent vertical scrollbar as a pause function, though it remains a hazard when I actually want to use the scroll bar as a scroll bar. I was wondering whether my description of patchy repainting required elaboration. In revisiting this, I found that perhaps the unreliable painting was dependent on having more columns selected than would fit in the horizonal space, and thus a horizontal scroll bar was also active. Here is a sample, after using scrollbar page down:

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?

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.