Messages

OK, next try, pick up the Window at the top and move it to e.g. the right.
The window should be floating, adjust the size and move it back and it should snap in again.

I didn't realize the sidebar could be manipulated in that manner. That works as you described, and allows a proper resizing. The new size is also correctly saved upon exit and restart. Looks as though as long as I don't accidentally crash it in future it will be good, and there's a path to recover.

Thanks for your help. I find the visual indication of machine status this provides is very helpful.

I just tested it again and it' works sort of, just click on the divider and next adjust the width, you will be able to make it really wide.

If that worked for me, we would not be having this conversation.
I give up. I tried ... 

Hopefully this will better explain what I'm seeing:
Resize issue

Sorry, no. When I do that here once the computer sidebar is gone, resizing it is not possible. Doing what you suggest resizes the entire window, but the missing column is still missing and cannot be accessed.
I never resize it intentionally, but if it's accidentally sized too small it is not recoverable.

This issue has been around for a while, but I didn't see it listed so thought I'd send a ping. Pardon if it has been raised elsewhere. I have duplicated this on 1.78 and 1.93, don't recall if it was an issue before but I believe it was.

Setup:
In main window select View -> Select Sidebar Computer selection checkbox.
In main window, computers will be listed, but column width may truncate longer computer names.
Attempting to adjust column width interacts with adjusting width of entire window, and results in Computer selection sidebar disappearing entirely. At that point, it is impossible to get the column back.
Closing the main window and reopening it will not restore the missing column. It is necessary to quit  entirely and restart to get the column back and, again it will not be able to be adjusted in width.

Thanks for the info. I'll do as you suggest and post updates, if any. Appreciate it!

Low priority issue to me, definitely. More a matter of curiosity.
I see this 2-3 times per day. Seems to happen when there's a fair amount of traffic caused by activity from project servers (e.g. downloading a slug of new tasks, change of work venue, etc).

03 May 2019 - 01:40:54 OnTimerDlg ---- Thread timeout, will restart.
03 May 2019 - 01:40:54 BoincTasks is closing down all threads, this may take a couple of minutes.
03 May 2019 - 01:40:58 BoincTasks has closed down all threads

Occasionally, one of the computers on the network apparently fails to respond:

03 May 2019 - 01:40:58 ERROR: Not closed down properly ---- [machine name]  Suspended

No real problems result from this, other than the crash itself, and everything restarts in a minute or two. Just wondering what the cause is, and if there's something I can do to minimize occurrences.
At present, given the configuration detailed below, BT is tracking 2000 tasks on SETI, and sometimes added tasks if other projects are active.

Current configuration is as follows:
1 - general use PC
     Xeon 3ghz hexacore
     running BT 1.78 on Win10, BOINC 7.12.1, monitoring dedicated crunchers
     Avg. CPU utilization < 90%,
     plenty of memory and SSD disk space
     3 NVidia GPUs
     LAN stats:
         DL Rate:  5.3 MB/s avg, 8.9 MB/s max
         UL Rate:  112 KB.s avg, 6.0 MB/s max
4 - dedicated SETI crunchers
     2 - Xeon 3ghz hexacore,         Win10, 1 - BOINC 7.12.1, 1 - BOINC 7.14.2, 3 NVidia GPUs ea.
     1 - dual Xeon 3ghz hexacore, Win10, BOINC 7.12.1, 3 NVidia GPUs
     1 - Xeon 3 ghz Core2Quad,     Win7,   BOINC 7.12.1, 4 NVidia GPUs
     Avg. CPU utilization > 90%
     plenty of memory and SSD disk space, LAN stats insignificant
Network - all 1gb wired connects via 2 gigabit switches
    No indication of network blockage or other LAN issues.

While utilization is high, none exhibit slow mouse, kybd or other response or other issues when used at at console.
Just wondering if there's anything I can do to tune this, or if it's just a hard-coded timer a machine intermittently fails to meet due to loading, or 

Would be interested in any thoughts?
Many thanks!

[posted this a couple months ago at 1/75 beta but no response so reposting]
Just loaded 1.75, and decided to test the new ability of editing app_config.xml.
Setup here is as follows:
1) Core2 Q9650, Win10ProX64, BT 1.75, BOINC 7.8.3, Projects: SETI, Einstein
2) Xeon E5450, Win7ProX64,                   BOINC 7.8.3, Projects: SETI, Einstein
3) Xeon X5675, Win10ProX64,                 BOINC 7.8.3, Projects: SETI, SETI Beta, Einstein
4) Xeon X5675, Win10ProX64,                 BOINC 7.8.3, Projects: SETI, SETI Beta, Einstein
Installation file paths are standard for BOINC and BT on all machines.

From machine 1) under Projects tab was able to load and read app_config for Einstein and SETI Beta on all machines (SETI uses app_info on all).
However, after making a change to Einstein on all 4 machines and to Beta on the two machines running it:
Syntax Check passes,
Apply passes,
A subsequent attempt to load app_config yields an "Invalid" window message in each case.

Further checking shows that each app_config is now file size 0 and all data has been lost.

Stupid me, of course, for not having made backups before testing a new feature, and for not having validated everything on 1 machine before moving on to the other three.
But I thought I would mention this for anyone else testing, to see if there's something else I did to screw this up or info I can provide to help find a resolution.
If I might also suggest, perhaps it would be good to have BT make a .BAK backup file of app/cc_config XML files before making changes to them, if that is possible.
Feel free to let me know how I might help! Thanks!

[edit 1]
It seems app_config editor is failing syntax check on <gpu_versions> statement. 
CC_Config editor is failing syntax check on <cc_config> tag.
Falling back to 1.73.

[edit 2]
Unable to fall back to version 1.66 or 1.73, as running installer gives error:
Open file:C:\Program Files\eFMer\BoincTasks\lang\BoincTasks_ENU.btlang
Group: <GroupMenuMain> string header in pos 225, <ExtraEditAppInfo> not found
Group: <GroupDialogRules> string header in pos 951, <EventSuspendNetwork> not found
Group: <GroupDialogRules> string header in pos 952, <EventResumeNetwork> not found

[c]

Hey BeemerBiker.
Maybe I'm totally off-base here, but shouldn't
<appliation>1.46%20MilkyWay@Home%20(opencl_ati_101)</appliation>
be
<application>1.46%20MilkyWay@Home%20(opencl_ati_101)</application>

Don't know anything about this, but it just looked wrong
Jim ...

Just loaded 1.75, and decided to test the new ability of editing app_config.xml.
Setup here is as follows:
1) Core2 Q9650, Win10ProX64, BT 1.75, BOINC 7.8.3, Projects: SETI, Einstein
2) Xeon E5450, Win7ProX64,                   BOINC 7.8.3, Projects: SETI, Einstein
3) Xeon X5675, Win10ProX64,                 BOINC 7.8.3, Projects: SETI, SETI Beta, Einstein
4) Xeon X5675, Win10ProX64,                 BOINC 7.8.3, Projects: SETI, SETI Beta, Einstein
Installation file paths are standard for BOINC and BT on all machines.

From machine 1) under Projects tab was able to load and read app_config for Einstein and SETI Beta on all machines (SETI uses app_info on all).
However, after making a change to Einstein on all 4 machines and to Beta on the two machines running it:
Syntax Check passes,
Apply passes,
A subsequent attempt to load app_config yields an "Invalid" window message in each case.

Further checking shows that each app_config is now file size 0 and all data has been lost.

Stupid me, of course, for not having made backups before testing a new feature, and for not having validated everything on 1 machine before moving on to the other three.
But I thought I would mention this for anyone else testing, to see if there's something else I did to screw this up or info I can provide to help find a resolution.
If I might also suggest, perhaps it would be good to have BT make a .BAK backup file of app/cc_config XML files before making changes to them, if that is possible.
Feel free to let me know how I might help! Thanks!

[edit]
Also, it seems app_config editor is failing syntax check on <gpu_versions> statement. 

Thanks!

I corrected the manual.
This is the latest how to add computers: http://www.efmer.eu/boinc/boinc_tasks/manual_net.html

Perhaps the difference is that, since this was an upgrade from a previous version, I did not and still have not installed or run BOINCToolbox. Didn't see a mention of that as a requirement in http://www.efmer.eu/boinc/boinc_tasks/manual.html, and since it was an ugrade, I didn't look at it as really adding any computers, though I did rerun the Detect as suggested. BOINCTasks already knew about them after the upgrade.
Just to clarify, is running the toolbox a requirement for MAC detection?
Thanks!

From the Manual:
===
Dynamic IP addresses
...
The best way to add a mac address is to use "Find computers".
This works even for existing computers, check xxxin that case only the missing MAC address is added.

If a MAC address is found in the computers tab it is used, regardless if there is an IP address.
Using a static address, you can remove the MAC address (empty it), this will help BoincTasks to connect slightly quicker.
===
On XP32 SP3 here, small home network. If it's relevant, the localhost runs Norton 360 antivirus, the other machines do not have anything other than the default Windows firewall. Router/firewall is a Linksys (Cisco) BEFSR81.
When upgrading from 1.53 to 1.58 (which went smoothly, thanks!), was exploring the new Mac address field in defining computers. When scanning (Find Computers), it finds the existing computers, but does not display MACs and when I select and tell it to add, the computers reconnect just fine, but again no MAC info.
I do run DHCP here, and on 1.53 reconnect was problematic. In some cases, I experienced a case where DHCP reassigning addresses resulted in BOINCTasks showing the same activity under two different machine names, while the "orphan" remained unreported.
It seems to reconnect better on 1.58, so that's great, but if connecting via MAC would be quicker and more reliable than by placing the host names in the IP field, it would be good to do so. It does seem strange to me that BOINCTasks has had trouble resolving machine names, yet a command line Ping returns the IP addresses immediately in all cases. Perhaps 1.58 improved this over 1.53?

Not sure what the "check xxxin" part in the manual excerpt above is, perhaps a note to yourself that hasn't been removed?

Anyway, minor issue here, but I thought you might like to know. Many thanks for authoring such a competent replacement for BOINCView, which I ran before I discovered this. If there's any way I can assist, please feel free to let me know. Jim ...