BT 1.21

[Pepo]

Add: If a user switch occurs, the BOINC client will be stopped and restarted when the other user logs in.

Do you mean "suspend computation", or really, literally "stop client"   

Changed: Projects: Tasks a week now shows 2 digits.

Maybe unnecessarily too much, 1 digit would be enough? But still, thanks.

Fixed: The icon isn't blinking while snoozing.

Have you finally found the culprit??


A re-test from 1.20:

• When (repeatedly) trying to trigger displaying the <ClientNotStartedBT> dialog ("The BOINC client wasn't started by BoincTasks and is still running"), I've (always) succeeded to terminate my client (launched by BOINC Manager) without any warning. Should this have happened?

Still happens in 1.21, is it intentional?

Checked again. After stopping the local client, I do see a STOP sign to the left of the computer, on the comp select sidebar. However, an automatic reconnect does not happen, even many minutes after starting the client again.

Please activate connection logging: C:\Program Files\eFMer\BoincTasks\examples\log
<log> <options> <connecting> 1 </connecting> </options> </log>
And see what is logged.

I've checked it just once, BT shut down the client, with messages:

17:12:36 Shut down BoincTasks ---- The BOINC client is shutting down
17:13:01 Shut down BoincTasks ---- The BOINC client has shut down

then some 3:40 minutes later (the timeout is set to 120 seconds) it successfully tried and connected to a newly started client:

17:16:41 Connect ---- Lost connection to: Host: localhost, Pavilon6, Port: 31416
17:16:41 Connect ---- Try to connect to: Host: localhost, Pavilon6, Port: 31416, Thread ID: 9484
17:16:41 Connect ---- Connected to: Host: localhost, Pavilon6, Port: 31416, BOINC Version: 6.12.34

Other two machines are regularly attempted for a connection in other 12-minute cycle.

I'll try to check it again later. But it was the first time it jumped in immediately 

[fred]

Do you mean "suspend computation", or really, literally "stop client"

Stop client, but that is a problem with BOINC running as a service. So I will make this optional.

Still happens in 1.21, is it intentional?

It is, if the client isn't started by BT it isn't stopped by BT.

17:16:41 Connect ---- Lost connection to: Host: localhost, Pavilon6, Port: 31416

The connection timeout is hard to predict, I set a timeout, but it's sometimes ignored by Windows.
But this one is easy to correct. If the client is stopped, flag it as a lost connection.

[Pepo]

Fred, you've possibly misunderstood me... so I'll try to reformulate my posts:

If start the client using BOINC Manager and later I'm trying to stop it using BT, it is being stopped without any complaint (I'd expect seeing the new warning dialog "The BOINC client wasn't started by BoincTasks..." popping up).

Still happens in 1.21, is it intentional?

It is, if the client isn't started by BT it isn't stopped by BT.

But I do see that BT is stopping the client, although it has been started by BOINC Manager... ??

[thebestjaspreet]

I just have got the computer restart after power shutdown and on restart of boinc tasks all the previous history was gone and also the number of tasks per week/day was reset. Will it not be better if it writes to disk after some reasonable period and start from the last checkpoint after restart so that data loss can be minimised.


Will it be helpful to BTasks use more Ram for 64 bit version so that it can perform better even when number of tasks are large as for some projects tasks duration is very small and hence the number of tasks in buffer/history goes high.

Just curious to make BTasks run more faster but i am not a programmer and hence do not know much about use of memory to speed up application.
I observed that even after few hours of running when switching to messages or history tab it starts reading from disk or whatever and takes some time to show the results.I wish if it could do the work in the background while running and when switching to a particular tab it should show current results,if possible.

[fred]

1) I just have got the computer restart after power shutdown and on restart of boinc tasks all the previous history was gone and also the number of tasks per week/day was reset. Will it not be better if it writes to disk after some reasonable period and start from the last checkpoint after restart so that data loss can be minimised.

2) Will it be helpful to BTasks use more Ram for 64 bit version so that it can perform better even when number of tasks are large as for some projects tasks duration is very small and hence the number of tasks in buffer/history goes high.

1) BT uses 3 history files, so if one is lost the other one is used. So all 3 have to be corrupted for all to get lost, should be very very rare.
And they are regularly updated as well.
What could happen is that the files can't be read for some reason. E.g. locked by another program or another copy of BT in another user session. This should show in the logging.

You could check the logging C:\Users\username\AppData\Roaming\eFMer\BoincTasks\log

See if there is any error or warning close to the time this happened.

2) Memory management is a OS thing. Normally some memory that is'n in use is backed up to disk and becomes virtual.
If you show BT or switch, it may take some extra time to get everything back to ram.
But BT isn't very memory hungry so more memory wouldn't help much.
Another thing what happens, if BT request the messages, they are read from file by the client. As this isn't a recent event, the file is read from the disk itself.
If the event is more recent the date is probably read from cache (ram) instead of the disk.

In the next version I will allow the moving parts of the history to long term history. This should speed things up if you have a large history.

[thebestjaspreet]

1) BT uses 3 history files, so if one is lost the other one is used. So all 3 have to be corrupted for all to get lost, should be very very rare.
And they are regularly updated as well.
What could happen is that the files can't be read for some reason. E.g. locked by another program or another copy of BT in another user session. This should show in the logging.

You could check the logging C:\Users\username\AppData\Roaming\eFMer\BoincTasks\log

See if there is any error or warning close to the time this happened.

2) Memory management is a OS thing. Normally some memory that is'n in use is backed up to disk and becomes virtual.
If you show BT or switch, it may take some extra time to get everything back to ram.
But BT isn't very memory hungry so more memory wouldn't help much.
Another thing what happens, if BT request the messages, they are read from file by the client. As this isn't a recent event, the file is read from the disk itself.
If the event is more recent the date is probably read from cache (ram) instead of the disk.

In the next version I will allow the moving parts of the history to long term history. This should speed things up if you have a large history.

Yes,I looked at log and found

"29 September 2011 - 16:11:11 CHistory::ReadFile ---- Unable to read to history file: C:\Users\Jaspreet\AppData\Roaming\eFMer\BoincTasks\history\history_Jaspreet-PC.cvs, copy 1
29 September 2011 - 16:11:11 CHistory::ReadFile ---- Unable to read to history file: C:\Users\Jaspreet\AppData\Roaming\eFMer\BoincTasks\history\history_Jaspreet-PC.cvs1
29 September 2011 - 16:11:11 CHistory::ReadFile ---- Unable to read to history file: C:\Users\Jaspreet\AppData\Roaming\eFMer\BoincTasks\history\history_Jaspreet-PC.cvs1"

But I noticed that in History folder there are 3 files viz  *.cvs, *.cvs1, *.cvs2

In the log there is no reference to *.cvs2 but in place it refers to *.cvs copy 1

[fred]

"29 September 2011 - 16:11:11 CHistory::ReadFile ---- Unable to read to history file: C:\Users\Jaspreet\AppData\Roaming\eFMer\BoincTasks\history\history_Jaspreet-PC.cvs, copy 1
29 September 2011 - 16:11:11 CHistory::ReadFile ---- Unable to read to history file: C:\Users\Jaspreet\AppData\Roaming\eFMer\BoincTasks\history\history_Jaspreet-PC.cvs1
29 September 2011 - 16:11:11 CHistory::ReadFile ---- Unable to read to history file: C:\Users\Jaspreet\AppData\Roaming\eFMer\BoincTasks\history\history_Jaspreet-PC.cvs1"

But I noticed that in History folder there are 3 files viz  *.cvs, *.cvs1, *.cvs2

In the log there is no reference to *.cvs2 but in place it refers to *.cvs copy 1

The reason why the history was lost is that BT couldn't read the cvs files. Why? Do you have any idea.

In V 1.22 I fixed a bug that didn't read .cvs2. It should try cvs, cvs1,cvs2 but it did cvs,cvs1, cvs1. Not that this would have mattered.....