eFMer - BoincTasks and TThrottle forum

Two issues found, one major:

• Quote from: fredAdd: A rule that triggers when a computer or all computers loose connection.

  A "Connection =<>" rule was probably not intended - just the equal sign?
  
  
• On one computer, my local "history_ComputerName.cvs" files got emptied! All three files (just the running tasks are there), I'm not sure when exactly, but evidently after the upgrade. History files for a not connected remote machine are partially untouched - all contain the historical data.
  Today I had to cold-reset the machine, afterwards with BT 1.03 I could see the most recently logged results from two days ago at the morning - the complete history was there. Later the day (after 15:22 - the download time) I've replaced BT 1.03 with 1.04. When I've checked the History tab, it contained just entries for a remote host.
  After using a 3 weeks old copy of history file, it was accepted, but the initial lines suddenly contain one overlong string in form

1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
BoincTasks History
Project Application Version .......

where the "machine name" line is 0x07DB2 bytes long!!
The remote machine's history files - just the "current" got modified this way, the  "machine name" line is "merely" 0x1A0 bytes long! The two older files (cvs1+cvs2) are still dated prior to 15:22 - the installation moment, the current file gets regularly refreshed.[/li]

Additionally, it is possibly already some longer time ago (more than 3 weeks - my backup copy), but my localhost's history files begin on 22.10.2010, although my history settings were always 365+23. The remote computer's log starts correctly on 29.5.2010.

Regarding Tasks refresh times - on my machine it looks like Fast=2s, Normal=3s, Slow=7s - maybe the Normal time is too tight on the Fast time?

=<> is cryptic for connected not connected = connecting lost  http://www.efmer.eu/forum_tt/index.php?topic=449.0 (http://www.efmer.eu/forum_tt/index.php?topic=449.0)

I can't reconstruct what happened with the history files, the 3 way setup should be safe.
But when the history isn't read back properly, the others are cleared as well.

But something funny is going on with the computer name, it looks like its added to the old one, causing it to grow.
I don't think it's really used at all, but when it gets that big, something nasty may happen.

The refresh times are highly dependent on the nr of tasks.
I only changed the moment the timer activates and that move to after everything is shown on the screen, this should affect only computers with loooooots of tasks.

Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, it is possibly already some longer time ago (more than 3 weeks - my backup copy), but my localhost's history files begin on 22.10.2010, although my history settings were always 365+23. The remote computer's log starts correctly on 29.5.2010.

How much CPU time/day are you using with that large a history?  I found that my 13 hours/day of CPU time for BT was seriously related to History (which was set at 1 day).  Disabling History resulted in BT using almost no CPU.  Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.  I do run a lot of MilkyWay which generates many WUs.  Yes I tried different History options like different Maximum update times and Smart mode on and off.  For a while I even ran BoincView for a 1 day history and BT for everything else and that resulted in a total of about 2 hours/day of CPU.  Kind of a PITA though.

Quote from: Beyond on May 30, 2011, 07:31:12 PM

Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, it is possibly already some longer time ago (more than 3 weeks - my backup copy), but my localhost's history files begin on 22.10.2010, although my history settings were always 365+23. The remote computer's log starts correctly on 29.5.2010.

How much CPU time/day are you using with that large a history?  I found that my 13 hours/day of CPU time for BT was seriously related to History (which was set at 1 day).  Disabling History resulted in BT using almost no CPU.  Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.  I do run a lot of MilkyWay which generates many WUs.  Yes I tried different History options like different Maximum update times and Smart mode on and off.  For a while I even ran BoincView for a 1 day history and BT for everything else and that resulted in a total of about 2 hours/day of CPU.  Kind of a PITA though.

It is usually not that bad (although I remember it being more than I'd like, in the past, but I do not remember any hard facts). Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. Maybe because of fairly low number of longer-running tasks, I have mostly some 15 active and 5-10 ready to start. One more reason could be that my history is (today again) smaller than 1 year, thus there is no need to discard older entries from the files (OK, I think that the files are being completely written anyway) and if the History tab is written correctly, there is also no need to do any (major) sorting upon adding new data for newly coming running and finished tasks... Thus, thinking naively, the CPU consumption should, in my opinion, depend just on the number of active tasks and slightly on the (maintained) file length, but not primarily on the (displayed) history length?

I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.

Quote from: Beyond on May 30, 2011, 07:31:12 PM

Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, it is possibly already some longer time ago (more than 3 weeks - my backup copy), but my localhost's history files begin on 22.10.2010, although my history settings were always 365+23. The remote computer's log starts correctly on 29.5.2010.

How much CPU time/day are you using with that large a history?  I found that my 13 hours/day of CPU time for BT was seriously related to History (which was set at 1 day).  Disabling History resulted in BT using almost no CPU.  Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.  I do run a lot of MilkyWay which generates many WUs.  Yes I tried different History options like different Maximum update times and Smart mode on and off.  For a while I even ran BoincView for a 1 day history and BT for everything else and that resulted in a total of about 2 hours/day of CPU.  Kind of a PITA though.

Can you check this with 1.04, see if there are any improvements.

Quote from: Pepo on May 30, 2011, 04:17:05 PM
After using a 3 weeks old copy of history file, it was accepted, but the initial lines suddenly contain one overlong string in form [/list]

Code Select Expand

1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName
[/quote]
I checked this, and it was probably a leftover, of times long gone.
At this point all elements dump the computer name, this was probably for a test and I forgot to remove it.
In 1.05 the computer name is only written once, from the first element. But it's not used at all, just for human use.
Never a good idea to let the file grow unnecessarily.

Quote from: fred on May 31, 2011, 06:48:13 AM

Quote from: Pepo on May 30, 2011, 04:17:05 PM

• After using a 3 weeks old copy of history file, it was accepted, but the initial lines suddenly contain one overlong string in form

Code Select Expand

1.04
TheMachineNameTheMachineNameTheMachineName............TheMachineNameheMachineNameTheMachineName

I checked this, and it was probably a leftover, of times long gone.
At this point all elements dump the computer name, this was probably for a test and I forgot to remove it.
In 1.05 the computer name is only written once, from the first element. But it's not used at all, just for human use.
Never a good idea to let the file grow unnecessarily.

Indeed _;D
And it grows and grows... _:))

Quote from: Pepo on May 30, 2011, 08:52:24 PM

Quote from: Beyond on May 30, 2011, 07:31:12 PM

Quote from: Pepo on May 30, 2011, 04:17:05 PM... my localhost's history files begin on 22.10.2010, although my history settings were always 365+23...

How much CPU time/day are you using with that large a history?  I found that my 13 hours/day of CPU time for BT was seriously related to History (which was set at 1 day).  Disabling History resulted in BT using almost no CPU.  Setting history of 1 or 2 hours kept CPU fairly low...

Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. [...]
I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.

After 20 hours the CPU consumption is 21:49 kernel + 57:51 user = 1:19:42 total, which extrapolates to 1 1/2 hours daily. (History settings is 365+23, 3-20 seconds, smart checked. The files' lengths are 4050 + 50 lines now.)

Quote from: Beyond on May 30, 2011, 07:31:12 PM
...Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.

I would not set my history refresh time that high (except when being absolutely desperate _::)), because it would completely miss all tasks with a shorter runtime (my switching time is also around 2 hours). But "It started increasing dramatically when set to 3 hours or more" makes me really _:o wonder - this CPU usage increase should not depend on the history IMHO...

Quote from: Beyond on May 30, 2011, 07:31:12 PM
I do run a lot of MilkyWay which generates many WUs. For a while I even ran BoincView for a 1 day history and BT for everything else and that resulted in a total of about 2 hours/day of CPU.

Approximately, in a rough average: how much active/all tasks do you have and what is their run time? How many tasks are finished daily (or hourly, does not matter)? I assume I'm playing in a diffident league with my 15+10 tasks _:)) My system is finishing merely 15-30 tasks daily, thus hard to compare the histories' behavior without knowing its implementation and possible reasons for higher CPU usage.

I'm trying the torrent link and after being searching for sometime and when started to download, it gives my one error,
and after that download is stopped and cancelled.

same error when trying TT or BT, client utorrent beta 3.0 x64 build 25329

here is the error:

QuoteFinished receiving metadata for 'setup_32_64_boinc_tasks_1_0_4.exe'
Error opening "E:\Peli_tmp\magnet:?xt=urn:btih:45739E88FA0032420DEC58FE9010087136803C34\setup_32_64_boinc_tasks_1_0_4.exe.!ut":
Error: setup_32_64_boinc_tasks_1_0_4.exe - El nombre de archivo, el nombre de directorio o la sintaxis de la etiqueta del volumen no son correctos.

translated: name of file, directory name or volume label wording is not correct.

Quote from: Pepo on May 31, 2011, 12:09:07 PM
Approximately, in a rough average: how much active/all tasks do you have and what is their run time? How many tasks are finished daily (or hourly, does not matter)? I assume I'm playing in a diffident league with my 15+10 tasks _:)) My system is finishing merely 15-30 tasks daily, thus hard to compare the histories' behavior without knowing its implementation and possible reasons for higher CPU usage.

2000/day on all computers.
18000 in stock, so a pretty good test case.

Quote from: Corsair on May 31, 2011, 01:07:06 PM
I'm trying the torrent link and after being searching for sometime and when started to download, it gives my one error,
and after that download is stopped and cancelled.

same error when trying TT or BT, client utorrent beta 3.0 beta x64 build 25203

Depends on the error, I test the magnet on an other computer if it wants to download.

Quote from: fred on May 31, 2011, 01:08:30 PM

Quote from: Pepo on May 31, 2011, 12:09:07 PM
Approximately, in a rough average: how much active/all tasks do you have and what is their run time? How many tasks are finished daily (or hourly, does not matter)? I assume I'm playing in a diffident league with my 15+10 tasks _:)) My system is finishing merely 15-30 tasks daily, thus hard to compare the histories' behavior without knowing its implementation and possible reasons for higher CPU usage.

2000/day on all computers.
18000 in stock, so a pretty good test case.

indeed an other league ₈₎. (I'm feeling irrelevant... _:-X) Then I should assume that a) my BT's CPU usage is pretty high _;D, or b) the CPU usage mostly depends on something else but the history refresh time.

Quote from: Pepo on May 31, 2011, 01:14:21 PM
Then I should assume that a) my BT's CPU usage is pretty high _;D, or b) the CPU usage mostly depends on something else but the history refresh time.

When BT is closed, it only runs the history, and below 1000 the impact should be quite low.

Quote from: fred on May 31, 2011, 01:13:10 PM

Quote from: Corsair on May 31, 2011, 01:07:06 PM
I'm trying the torrent link and after being searching for sometime and when started to download, it gives my one error, and after that download is stopped and cancelled.

same error when trying TT or BT, client utorrent beta 3.0 beta x64 build 25203

Depends on the error, I test the magnet on an other computer if it wants to download.

My uT 3.0b25307 successfully downloaded BT 1.04 some 15 hours ago and has so far seeded 192 kB of it to someones around (possibly to Corsair?) From the previous versions, 1.00 got sent 4.539 times, 1.01 and 1.02 never.

Quote from: Pepo on May 31, 2011, 12:09:07 PM

Quote from: Beyond on May 30, 2011, 07:31:12 PM
...Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.

I would not set my history refresh time that high (except when being absolutely desperate _::)), because it would completely miss all tasks with a shorter runtime (my switching time is also around 2 hours).

You forgot your morning coffee again.  It's not history refresh time, it's total history log kept.

Quote from: fred on May 31, 2011, 06:31:11 AM

Quote from: Beyond on May 30, 2011, 07:31:12 PM

Quote from: Pepo on May 30, 2011, 04:17:05 PMAdditionally, it is possibly already some longer time ago (more than 3 weeks - my backup copy), but my localhost's history files begin on 22.10.2010, although my history settings were always 365+23. The remote computer's log starts correctly on 29.5.2010.

How much CPU time/day are you using with that large a history?  I found that my 13 hours/day of CPU time for BT was seriously related to History (which was set at 1 day).  Disabling History resulted in BT using almost no CPU.  Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.  I do run a lot of MilkyWay which generates many WUs.  Yes I tried different History options like different Maximum update times and Smart mode on and off.  For a while I even ran BoincView for a 1 day history and BT for everything else and that resulted in a total of about 2 hours/day of CPU.  Kind of a PITA though.

Can you check this with 1.04, see if there are any improvements.

Fred, your changes in v1.04 seem to have done the trick.  I increased the history to 1 day and so far BT CPU time is only 11 minutes in 4 hours run time (of course there's only 4 hours in History at this point).  I'll report back again when more time has elapsed.  To answer Pepo's question, it looks like I'm averaging 5-6 WUs completed per minute.

Quote from: Beyond on May 31, 2011, 03:51:02 PM

Quote from: Pepo on May 31, 2011, 12:09:07 PM

Quote from: Beyond on May 30, 2011, 07:31:12 PM
...Setting history of 1 or 2 hours kept CPU fairly low.  It started increasing dramatically when set to 3 hours or more.

I would not set my history refresh time that high (except when being absolutely desperate _::)), because it would completely miss all tasks with a shorter runtime (my switching time is also around 2 hours).

You forgot your morning coffee again.  It's not history refresh time, it's total history log kept.

Ah ??? we are talking about different 2 hours, from the same beginning?  :-\ :-X :-[
Indeed, no coffee today :(

One hour ago I've observed my SETI cuda task (http://setiathome.berkeley.edu/result.php?resultid=1926981126), approaching its end. Now it is gone, but the History tab weirdly states it was finished yesterday and reported now, 1/2 hour ago:

QuoteSETI@home   6.10 SETI@home Enhanced (cuda_fermi)   04mr11aa.27560.5384.3.10.174_1 (http://setiathome.berkeley.edu/result.php?resultid=1926981126)   Elapsed(CPU): 03:51:40 (00:06:03)   Finished: 30.05.11 17:16   Reported: 01.06.11 10:54   Use: 0.56C + 1NV   Reported: OK

While the Messages log says:

Quote6573   SETI@home   01.06.11 10:30   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6670   SETI@home   01.06.11 10:34   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6783   SETI@home   01.06.11 10:38   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6913   SETI@home   01.06.11 10:43   [checkpoint] result 04mr11aa.27560.5384.3.10.174_1 checkpointed   
6956   SETI@home   01.06.11 10:45   Computation for task 04mr11aa.27560.5384.3.10.174_1 finished   
6958   SETI@home   01.06.11 10:45   Sending scheduler request: To fetch work.   
6959   SETI@home   01.06.11 10:45   Requesting new tasks for NVIDIA GPU   
7029   SETI@home   01.06.11 10:47   Scheduler request completed: got 1 new tasks   
7167   SETI@home   01.06.11 10:52   Sending scheduler request: To report completed tasks.   
7168   SETI@home   01.06.11 10:52   Reporting 1 completed tasks, not requesting new tasks   
7182   SETI@home   01.06.11 10:52   Scheduler request completed   
7925   SETI@home   01.06.11 11:16   Starting task 02ap11ab.3996.4157.11.10.161_1 using setiathome_enhanced version 610   

Otherwise BT is displaying correct times (tasks' Deadlines, Times received). There were no time jumps in the OS.

Quote from: Beyond on May 31, 2011, 03:58:00 PM
Fred, your changes in v1.04 seem to have done the trick.  I increased the history to 1 day and so far BT CPU time is only 11 minutes in 4 hours run time (of course there's only 4 hours in History at this point).  I'll report back again when more time has elapsed.

1 hour 54 minutes CPU in 24 hours with History set to 1 day.

Quote from: Beyond on June 01, 2011, 12:43:04 PM
1 hour 54 minutes CPU in 24 hours with History set to 1 day.

Of course this depends what the time is all about.
1 hour on a 8 core is something different from 1 hour on a single core.

2:54 hours in 2 days on 4 cores, 365+23 - albeit with just a handful of tasks.

Quote from: fred on June 01, 2011, 12:44:40 PM

Quote from: Beyond on June 01, 2011, 12:43:04 PM
1 hour 54 minutes CPU in 24 hours with History set to 1 day.

Of course this depends what the time is all about.
1 hour on a 8 core is something different from 1 hour on a single core.

Athlon 620 quad.  Big improvement, with v1.03 it was 13 hours.

Quote from: Pepo on May 30, 2011, 08:52:24 PM

Quote from: Beyond on May 30, 2011, 07:31:12 PM

Quote from: Pepo on May 30, 2011, 04:17:05 PM...my history settings were always 365+23.

How much CPU time/day are you using with that large a history?

Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. Maybe because of fairly low number of longer-running tasks, I have mostly some 15 active and 5-10 ready to start. My system is finishing merely 15-30 tasks daily.

I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.

To try the CPU consumption out, I've lowered my history (4100 lines in the local history file) from 365+23 to 15+23, assuming that it will keep approx. 150 lines in the local history file. Got the warning, but nothing obvious happened in the History tab - kept until October 2010. A look in the file - it got shortened by 1/2 (to 2080 lines). After restarting BT, the history finally got clipped, both in the History tab and file - to today (for local machine, 5 finished results, some active results) or two left results from a slow remote machine (but! they are from 25.12.2010 and 11.10.2010!).

I've tried the "keep history for" value down to 5 days, but the file got never clipped to much less than 192 kB (1080 lines). For 3 days, I've got 102 kB (580 lines), for 2 days 58 kB (330 lines), still approx. some 15 days of results. The History tab was still complete, until restart. Finally I've upped the limit to 20 days and restarted BT again - history file went down to 35 kB (200 lines) and the History tab displayed 63 results for the past 3 days (=2d+23) and 120 more results from 13.5.2011 down to 24.10.2010 - approx. 1 result for each 2-3 days ??? Even after multiple restarts. My history is set to 20 days.

The shortening of the history smells to me :-X somehow indeterministic?

Never mind, I'll be checking the CPU consumption now. History is set to 20 days, the file contains past 3 days + some dust from previous half year...
BTW, the computer name string size rises darn fast! :))

Quote from: Pepo on June 01, 2011, 05:21:08 PM

Quote from: Pepo on May 30, 2011, 08:52:24 PM

Quote from: Beyond on May 30, 2011, 07:31:12 PM

Quote from: Pepo on May 30, 2011, 04:17:05 PM...my history settings were always 365+23.

How much CPU time/day are you using with that large a history?

Today after 5 hours run time (localhost only) the CPU consumption is 22 minutes -> under 2 hours daily. Maybe because of fairly low number of longer-running tasks, I have mostly some 15 active and 5-10 ready to start. My system is finishing merely 15-30 tasks daily.

I could tell more after running for a couple of days uninterrupted, or sometimes make a test with a 1 week history buffer.

... I'll be checking the CPU consumption now. History is set to 20 days, the file contains past 3 days + some dust from previous half year...

After 3 hours, BT mostly idle except a few minutes at the beginning and now, CPU usage 1:22 minutes 8)
Let's see tomorrow.

Quote from: Pepo on June 01, 2011, 05:21:08 PM
... I'll be checking the CPU consumption now. History is set to 20 days, the file contains past 3 days + some dust from previous half year...

Date Time		Runtime		CPU usage
June 01, 2011, 08:39:36 PM		3 hours		1:22 min
June 02, 2011, 09:44:36 AM		16 hours		13:23 min

I found an inconsistancy in the way the update completed tasks works.  If you block off the ready to report WUs and use the right mouse button to get to the menu and press "Project UPdate" the timer for all tasks is reset to the maximum time to update.  If you go to the projects drop down menu, and press the report all  completed tasks, the timer is not reset.   This may be the way its supposed to work. I just noticed it today.  Its no biggie, just  thought I would bring to your attention.  Keep up the great work.

Quote from: idahofisherman on June 02, 2011, 06:55:00 PM
I found an inconsistancy in the way the update completed tasks works.  If you block off the ready to report WUs and use the right mouse button to get to the menu and press "Project UPdate" the timer for all tasks is reset to the maximum time to update.  If you go to the projects drop down menu, and press the report all  completed tasks, the timer is not reset.   This may be the way its supposed to work. I just noticed it today.  Its no biggie, just  thought I would bring to your attention.  Keep up the great work.

Strange on my computers it shows updating in Projects.
And it's doing the same thing, except when there are not task to report it skips the project, otherwise it does an project update.

again with export colours, looks like that some colour patterns are not exported or imported, and referring to projects colours, not transferred from one to another, as for the 4th and up project/computer depending of the view if combined or not.

the other thing should be that when exported the colour settings file should be asked the path for save it, and when imported should be asked for the path of importing, instead the default one that sometimes is not easy to remember/find.

this I've noticed as I've retired one computer "the server" for BT and upgraded with a new one, and wanted to import colours and some of then were missing.

I think that it's still in the wish list for of all settings + computer layout of an old installation as export/import.

If I want to stop BOINC/S@h I disable computation/network in BoincTasks. Then finish client and exit BT. I do this for to be sure, that no UL/DL/scheduler contact is running and a well checkpoint is set for CUDA WU. In past I suspended a CUDA WU in the preparation time on CPU, when I restarted BOINC the CUDA WU finished immediately with an error.

If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

Maybe a BUG?

Quote from: Sutaru Tsureku on June 06, 2011, 01:46:24 PM
If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

It may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.

Quote from: fred on June 06, 2011, 04:09:12 PM

Quote from: Sutaru Tsureku on June 06, 2011, 01:46:24 PM
If I start BT and start the client, I can't enable computation/network.
I need to do then exit of BT, restart BT and then the menu is available and I can enable again the computation/network.

It may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.

I tested it again.. I start BT, connect to the client..
It looks like it last ~ 2 mins until the menu is clickable.
It's possible to speed up this?


BTW.
Maybe it's possible that you could add a feature, that in the 'Stderr output' at S@h we could see that we use your nice BT? Advertisement for your nice software! ;)

Maybe something like:
<core_client_version>6.12.28</core_client_version>
<core_manager>boinctasks V1.04 by eFMer</core_manager>
<![CDATA[
<stderr_txt>
Windows optimized S@H Enhanced application by Alex Kan
Version info: ...
(...)

Quote from: Sutaru Tsureku on June 09, 2011, 02:32:28 PM
It may take some time before the menu is available. Initially it's grayed out and becomes active after communicating with the client.

I will take a look why this takes so long, should be better than 2 minutes.

But to be sure this is the localhost were are talking about.
And this happens when you startup BT when the client is already running or when BT is starting up the client (so at login).

Anyway you have to wait, for all computers to report is, so when one of them is a bit slow.
Using the Priority program will certainly make the the response longer.

Yes, it's the localhost.

After a reboot of the PC.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.

Currently I can't/don't use the remote function (only one machine running currently).

Your Priority tool shouldn't disturb, because no CUDA app running - until the menu is clickable.

Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PM
Yes, it's the localhost.

After a reboot of the PC.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.

Ok I've seen this before, I will add it to the bug list.
But what happens, BT starts first, than the client starts (this may take some time) and it may take a while before the client reports back everything.

Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PM
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.

Can you try File->Exit and than start BT again and see if it happens, probably not.

Quote from: fred on June 09, 2011, 02:54:09 PM

Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PM
Yes, it's the localhost.

After a reboot of the PC.
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.

Ok I've seen this before, I will add it to the bug list.
But what happens, BT starts first, than the client starts (this may take some time) and it may take a while before the client reports back everything.

From my experiences..
Reboot of PC. I start BT, connect to the client, after a few seconds I see the messages of the client in BT/Messages.
Then it last ~ 2 mins until the menu is clickable.

Quote from: fred on June 09, 2011, 03:00:53 PM

Quote from: Sutaru Tsureku on June 09, 2011, 02:49:40 PM
I start BT, connect to the localhost client.. ~ 2 mins until the menu is clickable.

Can you try File->Exit and than start BT again and see if it happens, probably not.

I had all running. Computation/network set to never. Exit BT. (In Windows Task-Manager boinc.exe was shown). BT start and menu immediately clickable.

O.K. ..

Reboot of the PC.
Start of BT 1.06 .
Connect to localhosts client (DEV-V6.12.28).
I click to all tabs - computer/projects/tasks/transfers/messages/process/notes.
The menu (computation/network) isn't grayed out, I can choose then both 'always'.
My currently going round. ;) So I don't need to wait ~ 2 mins.

Maybe a hint for to debug?