Messages

If I change the weight for a project, and update Boinc (by right clicking a relevant task in BoincTasks JS), the weight does not update in the task list, but it does in the project list.

But i cannot resize them, the program is confused and shows the scroll bar even though all the columns are displayed.  Anyway I cannot control the total width of all columns, shrinking one enlarges another.

If I add a lot of columns in task view, a scroll bar appears, even though the columns autoresize to fit the screen:

In the task list, when I right click a task then choose WWW, I often get the wrong project's web page, because it doesn't move the highlight and goes to whatever task was previously highlighted.  It seems completely random whether it does it or not.  I have to left click the task first to be sure.

EDIT: This happens in any view.  I just highlighted every project except LHC and chose suspend.  This worked fine.  Then I right clicked LHC and chose update, but since it remembered the highlight of all the others, it updated everything!  Now I have to wait an hour....

All I know is tasks between the odlk family of projects kept changing project name

this is also happening between time to switch between applications

�I am experiencing an issue where changes made to the Disk Allowance (Maximum Disk Usage) within the BoincTasks JS interface are not being sent to or saved by the BOINC client.
�The Issue:
�The BoincTasks JS interface showed a limit of 1,000 GB after I edited it.
�However, the actual BOINC client continued to operate under a 1 GB limit.
�Upon restarting the BOINC client, BoincTasks JS reverted to showing the 1 GB limit, indicating that the previous change to 1,000 GB was never actually written to the client's configuration files (e.g., global_prefs_override.xml).
�Steps to Reproduce:
�Open BoincTasks JS and navigate to the preferences/settings for a connected client.
�Change the Disk Allowance from a low value (1 GB) to a higher value (1,000 GB).
�Observe that the UI reflects the change.
�Check the local BOINC Manager or the global_prefs_override.xml file; the change is not present.
�Restart the BOINC client/Manager and note that BoincTasks JS reverts to the old 1 GB value.
�Impact:
This caused the GPU scheduler to halt work fetch requests, as it incorrectly believed the disk was full. The only fix was to bypass BoincTasks JS and update the limit directly in the native BOINC Manager.
�Request:
Could you look into whether there is a "silent failure" occurring when BoincTasks JS attempts to write preference overrides back to the BOINC client? It seems the UI updates locally in the browser, but the RPC command to update the client is either not being sent or is being rejected

Sorry if this sounds official or rude, Gemini constructed it for me with technical information:

Bug Report: Critical Project Naming Collision & Data Inconsistency
�Software: BoincTasks JS (Version 2.8.6)
Environment: 24-core Ryzen / High-thread count / Multi-Project Monitoring
Projects Involved: ODLK (Natalia/Termit), ODLK1 (Italy/ice00), and ODLK 2025 (Unlisted).
�The Core Issue
�BoincTasks JS is failing to maintain a unique identity for different projects that share a common directory name. This is causing "Identity Theft" in the UI where distinct projects are merged into one label, making it impossible to distinguish between work from different servers.
�Detailed Observations:
�The "Folder vs. Name" Parser Conflict:
�I am running ODLK (Natalia) and Latin Squares (ODLK1 Italy) simultaneously.
�Both projects use the directory /latinsquares/ on the local disk.
�BoincTasks JS is inconsistently overriding the Project Name with the Directory Name.
�Live "Name-Flipping" on Active Tasks:
�On my 24-core machine, I can see running tasks for the same project being labeled differently at the same time. Some say "ODLK Project" and some say "Latin Squares Project."
�The label appears to flip during the 30-second refresh cycle, suggesting a race condition in the live data parser.
�The "Ready to Report" Identity Jump:
�I have witnessed tasks labeled ODLK while running "jump" to the Latin Squares label the moment they move to the "Ready to Report" status.
�This indicates the software stops trusting the "Friendly Name" from RAM once a task is no longer "Active" and defaults to the disk folder name.
�Identical Application Name Collision:
�Both projects use identical application names (e.g., odlk3@home, odlkmin@home).
�Since the Project Name, Directory Name, and Application Name are all now identical or overlapping in the UI, it is impossible for a user to know which task belongs to which server without checking the Master URL column.
�Impact on User:
�For power users running dozens of threads, the current behavior makes monitoring server health impossible. If one server (e.g., the Italian solar-powered server) goes offline, the UI does not show which tasks are stalled because they are all labeled as "Latin Squares."
�Requested Fix:
�Please prioritize the Project Name provided by the BOINC client's client_state.xml as the primary key for the "Project" column. The software should never fall back to the directory name if a Friendly Name is available, especially in the "Ready to Report" queue.

There doesn't seem to be a way of accessing the list of exclusive applications.

Do we have to have these ok buttons to press everywhere?  Most apps nowadays it's just changed as soon as you click something.  For example when selecting Boinctasks colours, I can change a colour and click out of the colour selector box, and the colour seems to be changed, but then closing the whole box of colours, it's gone!

When right-clicking on the SRBase project (or a task belonging to it) and selecting the "www" option, the internal pop-up window containing the project links fails to appear. No additional button is created in the taskbar, and the UI does not seem to trigger the window at all.
�Observations:
�This appears to be project-specific. The "www" menu opens correctly for other projects (e.g., Einstein@Home, World Community Grid).
�I have tried restarting BoincTasks JS via the system tray, but the behavior persists for SRBase.
�It seems like a script or parsing error occurs when handling the specific URL/XML data returned by the SRBase server.

This shows the collapsed set:



This shows part of the expanded set, where we see GPU tasks in grey and CPU tasks in black:

Milkyway @ home is mainly multithreaded.

The numbers in brackets indicate less than 100% of 4 threads in use.  The correct answer should be 82%, by calculating (CPU time / wall time / CPU threads) * 100

I think what you might have done is forget to divide by the CPU threads, which gives 328%, which was then capped at 100%.

Thanks, I keep forgetting to look down there.  Although you do seem to duplicate these in the right click context menu, perhaps you should add detach?