BT 0.45

[jjwhalen]

I can confirm that the Tasks tab is much cleaner & easier to interpret without the alternating stripes...bravo to whoever suggested that  Thanks for implementing it.

Best wishes.

[archae86]

I may be inattentive or careless, or possibly there has been a change in BoincTasks.  In any case, there may be an unintended behavior regarding password for localhost.

I believe the first version of BoincTasks I ran was 0.42, and I believe that on that one BT was able to control localhost (such commands as "Project Update" and "Project Allow New Work") without my having populated the password field for it.  I did populate the password fields for my remote hosts.  Without the proper password, my remote hosts displayed the lightning bolt in the host list to the left of the big pane, and no data at all in task list, history, ...

Now, on 0.45, for a couple of days I was puzzled.  I could still do updates and control New Work on my remote hosts, but localhost was ignoring my "commands", though it was displaying data (and no lightning bolt).

I checked, found I had a non-empty gui_rpc_auth.cfg on localhost, put that text into the BoincTasks password field for localhost, and my commands started being obeyed.

Possibilities:

1. my error for having a non-empty gui_rpc_auth.cfg--BT is supposed to act this way, and always has, and I just failed to notice.
2. like possibility 1, save that version 0.45 actually is different from 0.42, but is the actual intended behavior.
3. (the possibility that has me taking your time with this post), this is unintended behavior, and possibly it changed between 0.42 and 0.45.

Anyway, it works fine for me now with the password put in, so I'm not asking for anything.  But I think the documentation implies the behavior I think it used to have (password not required for localhost), so if the behavior is to be left as is, possibly the documentation wants to be reworded a little.

[fred]

I may be inattentive or careless, or possibly there has been a change in BoincTasks.  In any case, there may be an unintended behavior regarding password for localhost.

I believe the first version of BoincTasks I ran was 0.42, and I believe that on that one BT was able to control localhost (such commands as "Project Update" and "Project Allow New Work") without my having populated the password field for it.  I did populate the password fields for my remote hosts.  Without the proper password, my remote hosts displayed the lightning bolt in the host list to the left of the big pane, and no data at all in task list, history, ...

Now, on 0.45, for a couple of days I was puzzled.  I could still do updates and control New Work on my remote hosts, but localhost was ignoring my "commands", though it was displaying data (and no lightning bolt).

I checked, found I had a non-empty gui_rpc_auth.cfg on localhost, put that text into the BoincTasks password field for localhost, and my commands started being obeyed.

Possibilities:

1. my error for having a non-empty gui_rpc_auth.cfg--BT is supposed to act this way, and always has, and I just failed to notice.
2. like possibility 1, save that version 0.45 actually is different from 0.42, but is the actual intended behavior.
3. (the possibility that has me taking your time with this post), this is unintended behavior, and possibly it changed between 0.42 and 0.45.

Anyway, it works fine for me now with the password put in, so I'm not asking for anything.  But I think the documentation implies the behavior I think it used to have (password not required for localhost), so if the behavior is to be left as is, possibly the documentation wants to be reworded a little.

What happens:
A) the password field is empty, the password file (gui_rpc_auth.cfg) is read and that password is used.
B) the password field is not empty, That password is used instead.

2) There are no changes that I.m aware of.

I did changed the default setting from encrypted to non encrypted so there maybe something there.
It may be that the password field was not empty but filled with something or that BT is unable to read the Password file.

On a localhost with a wrong password you may still do a lot of things, like viewing, but some commands are not allowed and simply ignored.

You may do some testing: Go to Help -> Show log, check "enable debug mode".
Remove the local host password and exit BT.
Start BT again and check the log for this line:  Computer = localhost get local password: xxxxxxxxxxxx

the xxxxx should hold the password.

[glennaxl]

Can you re-organize the code in such a way that it will populate the grid upon successful connection of 1 computer rather than waiting for all computers to respond then populate? Its like firefox way of displaying images.

I got computers that i'm connecting thru internet and if there are problems/issues/bottleneck on the other side, BoincTask will be in the Updating or Switching, busy state. Making it useless until I tick off the offender PC, kill boincktask, and re-start.

Or another way to say this, If 1 pc could not get the data back (but can send), don't wait for it, proceed to the next.

[jjwhalen]

Minor bug on the Tasks tab with all or multiple computers selected:

If you select (left click) a row containing Ready to start tasks that are filtered (Combined) on computer X, and computer Y (Z etc.)  has an identical row (same Project, Application, # of Tasks), all such rows will be highlighted.  If you perform a rt-click function on one such row (Suspend, Abort, Project Update, whatever) it will be copied to the other highlighted rows as if you selected multiple rows on purpose.  Also if you try to deselect the 2nd row using Ctrl-click, all rows will be de-highlighted.  The bug doesn't affect Waiting tasks or single-entry Ready tasks.

This isn't new to v0.45, just took me awhile to figure out what the symptoms really are

Best wishes.

[fred]

Minor bug on the Tasks tab with all or multiple computers selected:

If you select (left click) a row containing Ready to start tasks that are filtered (Combined) on computer X, and computer Y (Z etc.)  has an identical row (same Project, Application, # of Tasks), all such rows will be highlighted.  If you perform a rt-click function on one such row (Suspend, Abort, Project Update, whatever) it will be copied to the other highlighted rows as if you selected multiple rows on purpose.  Also if you try to deselect the 2nd row using Ctrl-click, all rows will be de-highlighted.  The bug doesn't affect Waiting tasks or single-entry Ready tasks.

This isn't new to v0.45, just took me awhile to figure out what the symptoms really are

Best wishes.

Added to the bug list. This is the follow tasks feature that locks in on a specific tasks of filtered tasks. But this should also include the computer name, because sometimes the same number of tasks are on 2 different computers.

[fred]

Can you re-organize the code in such a way that it will populate the grid upon successful connection of 1 computer rather than waiting for all computers to respond then populate? Its like firefox way of displaying images.

I got computers that i'm connecting thru internet and if there are problems/issues/bottleneck on the other side, BoincTask will be in the Updating or Switching, busy state. Making it useless until I tick off the offender PC, kill boincktask, and re-start.

Or another way to say this, If 1 pc could not get the data back (but can send), don't wait for it, proceed to the next.

Let me think about that, not that easy. It should timeout, but that may take up to 2 minutes.

[jjwhalen]

--SNIP--
Added to the bug list. This is the follow tasks feature that locks in on a specific tasks of filtered tasks. But this should also include the computer name, because sometimes the same number of tasks are on 2 different computers.

It makes sense that this is a feature gone slightly wrong.  I should amplify by saying that the computer names involved are totally different.

B/W

[tlsi2000]

I would like to add in here that there is a simular 'follow' process that I have run into.
It was not critical, so I did not report it, as it didn't happen often.
But while you are there in that same code, you might want to look at the following circumstance.

When there are more than one Filter operation (such as Suspended and Waiting to run),
and both combined filters are titled the same (like: 25 [Tasks]),
performing some operations that require a refresh of the set of tasks
will result in the follow process to 'follow' to the one that was not previously selected.
It generally just gets the first in the list that has that same title.


Thanks.

[fred]

I would like to add in here that there is a simular 'follow' process that I have run into.
It was not critical, so I did not report it, as it didn't happen often.
But while you are there in that same code, you might want to look at the following circumstance.

When there are more than one Filter operation (such as Suspended and Waiting to run),
and both combined filters are titled the same (like: 25 [Tasks]),
performing some operations that require a refresh of the set of tasks
will result in the follow process to 'follow' to the one that was not previously selected.
It generally just gets the first in the list that has that same title.

Noted.