Crossed in the post. The difference between the repo versions and the BOINC version is that the repo ones are designed to run as a service, and BOINC's sh script is designed to run in user mode. The permissions are different, and - more importantly - the file locations are different.

Since you have a repo distribution already, I wouldn't mix'n'match - use Gianfranco's PPA for consistency.

I used that script to get around a different problem and didn't lose any tasks so presumably running the script as root installs in the usual /var/lib/boinc unlike the older self install scripts which put everything in boinc subdirectory of where you run the script from.

I haven't heard of Neon before, so I went looking for info, and found this: Neon: A Wannabe Linux Distro For KDE Lovers.
The 2nd paragraph says:

Neon looks and feels much like a Linux distribution, but its developers assert quite openly on their website that Neon is not a real Linux distro. It just installs and functions like one -- sort of.

So it may be a case of "Roll your own BOINC" for this OS.

Sorry, I'll have to pass on that one - I'm still a novice when it comes to the difference between various flavours of Linux.

Crossed in the post. The difference between the repo versions and the BOINC version is that the repo ones are designed to run as a service, and BOINC's sh script is designed to run in user mode. The permissions are different, and - more importantly - the file locations are different.

Since you have a repo distribution already, I wouldn't mix'n'match - use Gianfranco's PPA for consistency.

Before going much further, can I ask you to do one more thing?

Yes, there are bugs in BOINC. We do our best to resolve them, when we are presented with sufficient and relevant diagnostic data. Keith Myers and I successfully argued for two successive improvements to the scheduling logic last time round.

So, please update your copy of BOINC from the rather old v7.9.3, to one of the development versions v7.16.6 or v7.17.0 - who knows - we may even have solved your problem even before you posted it ;-)

And with the new version, use the 'priority_debug' event log setting to show us a little more of what's going on with the work fetch logic.

As a developer yourself, you will be aware that legacy versions of software eventually drop out of long term support.

It's actually multiple bugs because the manual Update button should be forcing a retrieval if there is any space in the queue.

You have a project with 500,000 computers doing your work. Your server manages to adequately give work to 10,000 computers at the same time, maybe 15,000. One day 100,000 of your users work out a prank and they massively at the same time start hitting their Update buttons, every second. You know what that is? That's a DDOS attack. That will bring your server down. And that's exactly the reason why the Update button does not have precedence over the back-off procedure that runs in the background. As that will try to spread the load of the amount of computers and certainly not allow for several presses of the Update button to all go through.

This is a scheduler bug.

And your only proof is a picture. Not even a log (look through stdoutdae.txt and stdoutdae.old in your data directory for older messages). Not even a log with a work_fetch_debug flag on at the time (And I did ask for it before you started changing your preferences! You quoted my post but did absolutely nothing with its contents)

We have a client simulator: https://boinc.berkeley.edu/trac/wiki/ClientSim. Go test your scenarios in that. Or go back to the previous situation if you can (may take a while) and then test correctly.

I've not written one line of code for BOINC

And not looked up any code to substantiate your claims either: https://boinc.berkeley.edu/trac/wiki/SourceCodeGit

I've written an awful lot of code

Now you are advertising your book site and so a moderator can take your whole post down just based on that. Can even kick you for however long they feel is necessary. Might be useful so you take the time to check how you properly report bugs, instead of sprouting your amount of years as code writer as irrefutable proof that you know what you're talking about while you haven't read one line of BOINC code or produced a log with the correct debug flags set.

I agree with BobCat: these two lines together explain the 'problem'.

Wed 08 Jul 2020 06:29:11 PM CDT | | [work_fetch] target work buffer: 8640.00 + 604800.00 sec
Wed 08 Jul 2020 06:29:11 PM CDT | | [work_fetch] shortfall 4562751.58 nidle 0.00 saturated 22834.00 busy 0.00

Any time the first entry for 'target work buffer' is less than 'saturated', BOINC will say that no work is needed, and won't fetch any by itself.

Set the first figure for 'store at least' to a large enough figure to tide you over the gaps in your internet connection: add a small 'additional' figure if you wish, to tide you over any unexpected problems. But keep the two figures together well below the minimum deadline for any of your projects. BOINC will run much more smoothly then.

I agree, you need to sort out your Internet first before tackling other issues.

I don't see any output from the work_fetch_debug logging option. But that is because you haven't successfully contacted any scheduler yet because of the connection issues.

Your BOINC or OS also has some issues obviously as your screenshot of the logging options is truncated.

I would look into your KDE Window Manager and its environment because it is not drawing all the elements of the Manager.

All those "can't resolve hostname" entries point to something being seriously mis-configured in your computer's internet connection - specifically, your (or your internet provider's) Domain Name Service resolver.

Take a good, hard, look at your TCP/IP stack and sort that out, before dealing with the secondary issue.

P.S. 'www.cosmologyathome.org' resolves to 194.57.221.148 without problems, from here.

Is this the correct interpretation?

No, because https://www.nvidia.com/Download/index.aspx?lang=en-us doesn't have commercial outings and if it had, it would be a problem when someone from Nvidia themselves would post with links to their own material. That you had those links in your signature for absolute ages only shows that no one thus far looked at them, or that you didn't have those books on there until just shortly before you started posting again with your account (as before you posted with it in 2018, before that 2015).

Can you please remove the URLs in your signature? We do have the rule "No commercial advertisements." and since you're asking money for those books, you're making it a commercial advertisement.