hmmm, editing global_pref.xml is a bad idea as it is a file that is controlled from the website device profile and contains the information from there. Wanna change something, make the change on the website.

That time stamp

<mod_time>115499354020</mod_time>

is the one you last made change to the website device profile (venue in BOINC speak) and is shown in the start up message log of BOINC as a human readable date, which is X seconds after 1.1.1970 at 00:00:00 (which is = 0)?

Question for me is why you consider it a poorly formed date? Mine is presently <mod_time>1217349111</mod_time> btw (38 years after 1970). Sometime this or last week i made the ultimate change. Your value translates like the 3662 years after 1970. That in it self means nothing, but if its your system clock you wont be getting a second of work from any project.

Next time, if you want to edit preferences from locally, do it in the global_prefs_override.xml

ah,

substracting the 2 extra digits, 20 which has some significance, you get 1154993540 is 36.6 years after 1.1.1970.... how odd.

stop client

delete global_prefs.xml

Start client. Not sure if it recreates the file and look in content of the global_prefs.

hit update to fetch a fresh set of parms.

look in file. If malformed again it needs expert attention.

I appreciate the review of my situation by Sekerob and JmBoullier, but I guess I didn't communicate the problem clearly. I'll try again.

1) I manually edited global_prefs.xml and restarted boinc to prove that correcting that file to include the ending tag </mod_time> would make my machines behave correctly.

2) Please consider that even if I correct ed the mod_time tag-pair manually, some process is restoring the incorrect xml record by rewriting the global_pref.xml file.

3) I have deleted all of my boinc profiles (work/home) except (default) using my account at the worldcommunitygrid.org web site.

4) because the end tag </mod_time> is missing after some process overwrites this file, I believe the remaining XML configuration statements are being ignored.

5) my request for help is this:
a) There must be a process that is rewriting global_prefs.xml from some source file not on my computer.
b) how do I change the source data of that process so that it will write a correctly formmated global_prefs.xml file ( which I do not normally change manually).

Hello Didactylos,
yes your analysis is correct, the error is also in the file
sched_reply_www.worldcommunitygrid.org.xml
<mod_time>115499352020mod_time>

Now, could I beg you for a suggestion as how to remove this error from
sched_reply_www.worldcommunitygrid.org.xml
and fix it for all of my machines participating in the Boinc projects?
They are running at 100%cpu on all cores all the time and some are getting
hot on these summer days in Cincinnati.

I don't know how the corrupted mod_time got there, but it was also preventing the BOINC server code from replacing the corrupt value when new prefs were received from the client.

I have manually corrected the issue in the BOINC database and in website database. Please repeat the process Did explains and then do an update and the problem should be resolved.

Please note, that if the client contacts our servers before you take this manual step, the values in the database may get over written again. I'm going to take a look at that code and see if I can make sure it ignores the corrupt global prefs from the client.

thanks,
Kevin