Messages

I select a task and if I'm too slow the selection is cleared.

This is not normal behavior for BoincTasks, which mostly uses the standard Windows GUI functions and mouseology.  Once selected a row will tend to stay highlighted until you act on it again or select another, even after the task's Status changes.  Be sure you are using single click only to select the row.  If you doubleclick a task it will select then quickly deselect.  You might also check the doubleclick speed slider in your Control Panel>Mouse settings.  A maladjustment here might cause unintentional doubleclick, as could a mushy left button switch.

Regarding task list update (Refresh), it is adjustable.  Go to Extra>Boinc Tasks settings>View tab and look for the "Refresh rate" pulldown.  The Slow setting is double the interval of the default (Normal) setting, or ~6 seconds.  But I doubt this has anything to do with your problem.

Best wishes.

I enjoy using my signature with badges & stuff, but I'd really prefer to attach it only once per thread (or maybe once per page).  I'm sure you know that most forums these days have a checkbox option to attach the signature or not, with user-selectable default in the profile.  I've looked in vain for that here, including the "Additional Options."

• a. Am I missing something, and/or
• b. Will we maybe get that feature in a future upgrade to the forum?

Best wishes and happy hiking 

As I said, minor glitch

You can set the History refresh time to say 5-10 seconds, that will improve things.
With a couple of 100 WU's the impact will be low.

Not really necessary; I'm just glad to have the Report function on the context menu   However it might have been worth putting a (*) caveat in the version description that the count is based on History and wouldn't necessarily be UTD

I hope the hikes are going well (no dead burros).

[other]

Filter based on plan class (too):

Primegrid just today deployed a new GPU application user-friendly name Cullen/Woodall Prime Search (Sieve) (cuda23) as a companion to the CPU version which has been around for awhile.  The .exe's (on a 64-bit machine) are primegrid_gcwsieve_1.12_windows_intelx86__cuda23 and primegrid_gcwsieve_1.12_windows_x86_64 respectively.

With work onboard for both apps and the task filter off, individual tasks are correctly displayed as CPU or GPU.  With the filter on, both types are combined into a single line entry

Request you refine the filter parameters to keep the two plan classes separate.  You'll recall we went through this with SETI & SETI Beta tasks also, when both projects were using the same app version number  Note that in the present case, version numbers are also the same (1.12).

I was able to confirm this behavior today with Primegrid's other CPU/GPU application: 1.38 Proth Prime Search (Sieve) [+ (cuda23)] (exe's primegrid_tpsieve_1.38_windows_x86_64 and primegrid_tpsieve_1.38_windows_intelx86__cuda23).  The last time I ran both of these on the same host back in December, the filter was not combining the 2 types together.  But then the version numbers were different (1.36 vs. 1.37).  With both now being 1.38, they are getting combined just like the gcwsieve (Cullen/Woodall).

Normally I don't run the CPU app on the same platform with a GPU except during a Challenge, since it's a dreadful waste of CPU time.  But recently for technical reasons I've been forced to download CPU workunits also and then abort them.

Strange that the task filter isn't picking up the difference in plan class, because I thought we had that problem worked out  

[EDIT] Now running BT 0.98, but the behavior is the same. [/EDIT]

The number is not that recent, in a default setting is should be updated at least ever 2 minutes.
When you set the History refresh rate higher it will take longer.
Polling it more frequent will cause too much overhead.

As I said, minor glitch

[to nil]

Minor glitch in

Added: Report all completed tasks to the toolbar context menu. The number indicates the total number to be reported:

If BT is started with tasks already "Ready to report" the new context menu item shows an accurate count
Newly completed tasks increment the counter correctly
If the "Report all completed tasks" function is then executed the tasks are reported, but the counter does not reset  
The next time a task is completed the counter resets to nil (should now be 1)
Thereafter the counter increments, but continues one number behind

What's in the column Use and Application in both cases.

CPU App:
Application = 1.12 Cullen/Woodall Prime Search (Sieve)
Use = (null field)

GPU App:
Application = 1.12 Cullen/Woodall Prime Search (Sieve) (cuda23)
Use = 0.18C + 1NV (condensed Use column )

While BT kept running, I've updated the client 6.12.10->6.12.11. BT lost connection to it (it was the only connected client, local) and did not get it again even many minutes after the client (in service mode) started. I remember already having seen this in the past.

Interesting.  I also updated localhost today 6.12.10->6.12.11 (all hosts actually) with BT still running. but BT had no trouble reconnecting to local or remotes   But I'm not running in protected (service) mode.

Filter based on plan class (too):

Primegrid just today deployed a new GPU application user-friendly name Cullen/Woodall Prime Search (Sieve) (cuda23) as a companion to the CPU version which has been around for awhile.  The .exe's (on a 64-bit machine) are primegrid_gcwsieve_1.12_windows_intelx86__cuda23 and primegrid_gcwsieve_1.12_windows_x86_64 respectively.

With work onboard for both apps and the task filter off, individual tasks are correctly displayed as CPU or GPU.  With the filter on, both types are combined into a single line entry

Request you refine the filter parameters to keep the two plan classes separate.  You'll recall we went through this with SETI & SETI Beta tasks also, when both projects were using the same app version number  Note that in the present case, version numbers are also the same (1.12).

The Tasks and Stats graphs use the predefined 20 colors. If there is a larger number of projects, then all over the 20th share the last color.

Could please the colors be used again from beginning, starting with the 21st and 41st project etc.?

Not to introduce too much complexity but does the graphing toolkit allow for things like broken lines or maybe alternating strips of color for higher "blocks" of projects beyond 20?

A few years ago, we have lost BoincView in one sudden moment. Sebastian (its author) always said he will keep the sources, writing just for his fun. And once he suddenly vanished  without a farewell  (but i'm convinced to say he continued to be active elsewhere; maybe he just lost interest (or eventually was forced to leave)).

I wish only the best for Fred, and was kidding of course   But I was certainly thinking of Sebastian & BoincView when I posted

I will try to implement that as an extra column in the computer mode.

As for the hiking, excellent. Found another great place to do some cross country hiking. Today a bit too much, got over confident and suddenly got stuck with all steep (dry ) falls and nowhere to go but back up a slippery path.  Excellent for the GPS to find the same way back, easy to go the wrong way and end up a dead Burro, as we followed it's trail.

Pepo's idea is probably a better solution for folks with many hosts; Bravo Zulu, Peter.

Dude, be safe and don't end up the dead burro   But just in case, please arrange to release your source code "in the event of..." 

Two related feature requests:

• Request add a 3rd mode option to the Gadget settings -- Mode: Show all 'Ready to report' tasks,
• Request add the Projects>Report all completed tasks command to the systray context menu.

I hope you're enjoying your hiking holiday

I salute you.

And thanks for your service, too

I have a History / Reported Status  Qestion.
I notice some of the History Reported Work Units Reported: OK  have an
asterisk as Reported: OK *
What is the meannig of the asterisk?
I see no reference to it in the manual.

Thank you

Dave

Fred is on holiday and may be slow to answer, so I'll try:

That was a change introduced in version 0.91

Changed: History: Simplified the internal routines (HistoryItem CString -> char *), for more stability.
Changed: History: (u) Last seen in upload, now *.

The History only updates periodically (typically every 30 seconds).  If a WU was in the process of uploading at the last update and is "missing" at the next update, it is assumed to have uploaded and reported in the intervening period.  A reasonable assumption, else the BOINC client just lost the result, in which case the project server should download it again.  Hence the Status Reported OK* -- before 0.91 it was Reported OK(u).

Best wishes.