If this is okay, which would you recommend I delete first? Perhaps the sched_reply for SETI?

Neither of those will help, because each request/reply file is used one time only: they are generated afresh for and by each separate scheduler connection.

sched_request or sched_reply files

Not sched_request or sched_reply but global_prefs.xml (and not global_prefs_override.xml). You are using local prefs so you shouldn't see anything change if you delete the global prefs file.

Running file system scan might not be a bad idea either.

Unfortunately, the file is about 13K. Here it is:

I just copied and saved the file you posted - it came to 63KB, not 13KB.

Cherokee edited the post to 84K. Summing the bytes from http_xfer comes to 86096 bytes so that should be ok.

there may be a 64KB limit per post here

I'm pretty sure we have that limit.

Both of you are right. The Forum software or it's settings did truncate the last approximately 20K of the file.

Here is the last part of the file, picking up with the last displayed <platform> listed in the truncated post, which was for task 10au10ab.15067.14791.13.40.103.vlar_1_0:


<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.103.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.103.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.103.vlar_1</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.103.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.131.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.131.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.131.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.131.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.233.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.233.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.233.vlar_0</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.233.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.34.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.34.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.34.vlar_0</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.34.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.171.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.171.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.171.vlar_0</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.171.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.153.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.153.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.153.vlar_0</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.153.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.82.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.82.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.82.vlar_1</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.82.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.38.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.38.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.38.vlar_0</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.38.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.105.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.105.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.105.vlar_1</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.105.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.35.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.35.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.35.vlar_0</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.35.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.219.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.219.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.219.vlar_1</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.219.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.196.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.196.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.196.vlar_0</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.196.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.169.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.169.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.169.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.169.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.192.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.192.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.192.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.192.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.156.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.156.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.156.vlar_1</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.156.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.207.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.207.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.207.vlar_0</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.207.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.172.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.172.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.172.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.172.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.158.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.158.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.158.vlar_0</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.158.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.175.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.175.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.175.vlar_0</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.175.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.199.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.199.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.199.vlar_1</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.199.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15947.14791.15.42.82.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15947.14791.15.42.82.vlar</wu_name>
<name>10au10ab.15947.14791.15.42.82.vlar_0</name>
<file_ref>
<file_name>10au10ab.15947.14791.15.42.82.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.72.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.72.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.72.vlar_0</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.72.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.26540.16427.14.41.226.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.26540.16427.14.41.226.vlar</wu_name>
<name>10au10ab.26540.16427.14.41.226.vlar_0</name>
<file_ref>
<file_name>10au10ab.26540.16427.14.41.226.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.168.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.168.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.168.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.168.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.188.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.188.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.188.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.188.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.132.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.132.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.132.vlar_0</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.132.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.130.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.130.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.130.vlar_1</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.130.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.252.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.252.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.252.vlar_0</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.252.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.150.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.150.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.150.vlar_1</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.150.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15067.14791.13.40.210.vlar_1_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15067.14791.13.40.210.vlar</wu_name>
<name>10au10ab.15067.14791.13.40.210.vlar_1</name>
<file_ref>
<file_name>10au10ab.15067.14791.13.40.210.vlar_1_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.26540.16427.14.41.242.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.26540.16427.14.41.242.vlar</wu_name>
<name>10au10ab.26540.16427.14.41.242.vlar_0</name>
<file_ref>
<file_name>10au10ab.26540.16427.14.41.242.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<file_info>
<name>10au10ab.15035.14791.12.39.79.vlar_0_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>65536</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/sah_cgi/file_upload_handler</url>
</file_info>
<result>
<report_deadline>1462839366</report_deadline>
<wu_name>10au10ab.15035.14791.12.39.79.vlar</wu_name>
<name>10au10ab.15035.14791.12.39.79.vlar_0</name>
<file_ref>
<file_name>10au10ab.15035.14791.12.39.79.vlar_0_0</file_name>
<open_name>result.sah</open_name>
</file_ref>

<platform>windows_intelx86</platform>
<version_num>800</version_num>
<plan_class></plan_class>
</result>
<gui_urls>
<gui_url>
<name>Message boards</name>
<description>Correspond with other users on the SETI@home message boards</description>
<url>http://setiathome.berkeley.edu/forum_index.php</url>
</gui_url>
<gui_url>
<name>Help</name>
<description>Ask questions and report problems</description>
<url>http://setiathome.berkeley.edu/forum_help_desk.php</url>
</gui_url>
<gui_url>
<name>Account</name>
<description>View your account information</description>
<url>http://setiathome.berkeley.edu/home.php</url>
</gui_url>
<gui_url>
<name>Preferences</name>
<description>View and modify your computing preferences</description>
<url>http://setiathome.berkeley.edu/prefs.php?subset=global</url>
</gui_url>
<gui_url>
<name>Tasks</name>
<description>View your recent tasks</description>
<url>http://setiathome.berkeley.edu/results.php?userid=76257</url>
</gui_url>
<gui_url>
<name>Computers</name>
<description>View a list of the computers on which you are running SETI@Home</description>
<url>http://setiathome.berkeley.edu/hosts_user.php?userid=76257</url>
</gui_url>

<gui_url>
<name>Donate</name>
<description>Donate to SETI@home</description>
<url>http://setiathome.berkeley.edu/sah_donate.php</url>
</gui_url>
</gui_urls>
<rss_feeds>
<rss_feed>
<url>http://setiathome.berkeley.edu/notices.php?userid=76257&auth=76257_5d7a8cbf6d642a00d6f4259c3ca81a26</url>
<poll_interval>86400</poll_interval>
</rss_feed>
</rss_feeds>
<file_info>
<name>arecibo_181.png</name>
<url>http://boinc2.ssl.berkeley.edu/sg_images/arecibo_181.png</url>
<md5_cksum>f9b65230a594098d183d2266511bc648</md5_cksum>
<nbytes>52779</nbytes>
</file_info>
<file_info>
<name>sah_40.png</name>
<url>http://boinc2.ssl.berkeley.edu/sg_images/sah_40.png</url>
<md5_cksum>5791ba1be2d33eaa5f90ecf5de89a53d</md5_cksum>
<nbytes>2536</nbytes>
</file_info>
<file_info>
<name>sah_banner_290.png</name>
<url>http://boinc2.ssl.berkeley.edu/sg_images/sah_banner_290.png</url>
<md5_cksum>39839286db7f580bef5377322d15ed35</md5_cksum>
<nbytes>25488</nbytes>
</file_info>
<file_info>
<name>sah_ss_290.png</name>
<url>http://boinc2.ssl.berkeley.edu/sg_images/sah_ss_290.png</url>
<md5_cksum>caf95504208aedd6ac6d82201e2fd8b1</md5_cksum>
<nbytes>35399</nbytes>
</file_info>
<project_files>
<file_ref>
<file_name>sah_40.png</file_name>
<open_name>stat_icon</open_name>
</file_ref>
<file_ref>
<file_name>sah_ss_290.png</file_name>
<open_name>slideshow_setiathome_v7_00</open_name>
</file_ref>
<file_ref>
<file_name>arecibo_181.png</file_name>
<open_name>slideshow_setiathome_v7_01</open_name>
</file_ref>
<file_ref>
<file_name>sah_banner_290.png</file_name>
<open_name>slideshow_setiathome_v7_02</open_name>
</file_ref>
<file_ref>
<file_name>sah_ss_290.png</file_name>
<open_name>slideshow_astropulse_v6_00</open_name>
</file_ref>
<file_ref>
<file_name>arecibo_181.png</file_name>
<open_name>slideshow_astropulse_v6_01</open_name>
</file_ref>
<file_ref>
<file_name>sah_banner_290.png</file_name>
<open_name>slideshow_astropulse_v6_02</open_name>
</file_ref>
</project_files>

</scheduler_reply>

Hi Juha.

If by "file system scan" you mean running chkdsk to check the volume for errors, on your suggestion I have just run it, but chkdsk found no errors on the volume.

This seems to be turning into quite a mystery.

With every theory seeming to hit a dead end, I think it might be good to consider the following.

The troubles for both SETI and Einstein began when Einstein stated it had resent 3 lost Einstein tasks, but they did not show up on my host.

SETI's problems began a few minutes later when SETI stated that it had sent 3 "lost" SETI tasks.

After that failure in the receipt of those "lost tasks", every attempt to get new tasks for either project fails. Each project shows that I been sent their same 3 "lost tasks", and each project also shows that I was sent other other new tasks. Neither the "lost tasks" or the new tasks that either project believes it has sent have actually shown up on my host since that first moment when Einstein said it had sent its 3 "lost tasks".

The fact that this occurred on two separate projects within several minutes of each other leads me to believe the error is either somewhere in BOINC's software, or it is some rather strange occurrence on one of my most reliable hosts, even though my host is having no apparent problems with any other software, hardware, network connections, or Internet communications.

I hope this helps.

Thank you.

Like I said earlier, I can see only one way to get the log messages you got: if opening global_prefs.xml for writing fails. Could you try

1. opening global_prefs.xml in Notepad and editing it, say adding blank lines, and saving it
2. removing it

...

1. They are usually very, very slow to request new units, even when their caches are set to 10/10 days and they have only several units left to process. The interval between requests can, at times, be as much as several hours.

...

Are you still running 10/10 cache setting or did you change it to 10/0.1 as Rob suggested?

If you're still running 10/10 then that's very likely your problem. ;-)

Cheers.

Hi Juha.
You found it! It was the global_prefs.xml file.

I apologize for not addressing this sooner. I was attempting to read, test, and respond to so many ideas from such great experts that I missed your reference to the global_prefs.xml until you restated it.

The problem was that somehow, sometime, that file had its attributes set to "read only".

I am a little curious, however. The old copy of the file had been unchanged since September 8, 2011. Even the 7.6.22 version of BOINC has been running successfully on this host since it replaced 7.2.42 on January 12, 2016.

What would have caused BOINC to attempt to update global_prefs.xml on March 9, 2016, for the first time in four and a half years?

Also, as to the suggestions by both Rob Smith and Wiggo about increasing the frequency of new task requests by changing the cache settings, I have made the changes and will observe the automatic requests for a few days to see if the frequency of the requests increases.

My thanks go to all of you for your help in solving this perplexing problem!

What would have caused BOINC to attempt to update global_prefs.xml on March 9, 2016, for the first time in four and a half years?

It will happen if you change Computing preferences on one of the projects
http://setiathome.berkeley.edu/prefs.php?subset=global
https://einstein.phys.uwm.edu/prefs.php?subset=global
http://milkyway.cs.rpi.edu/milkyway/prefs.php?subset=global

The last changed will be used and propagated (through your computer) to other projects

What do you see for:
Preferences last modified: 7 Jan 2011, 21:28:40 UTC

(on bottom on SETI@home and Einstein@Home, on top at MilkyWay@home)


P.S.
As a side note - I feel this as a bug in BOINC
If it finds one of its files to be Read-Only (or generally any reason for "unable to write") BOINC should say so and not give misleading Messages

The Message in this case should be something like "Can't open global_prefs.xml for write access" and not "can't parse scheduler reply"

---

 


- ALF - "Find out what you don't do well ..... then don't do it!" :)
 

P.S.
As a side note - I feel this as a bug in BOINC
If it finds one of its files to be Read-Only (or generally any reason for "unable to write") BOINC should say so and not give misleading Messages

The Message in this case should be something like "Can't open global_prefs.xml for write access" and not "can't parse scheduler reply"

That's a fair comment.

In bug-hunting mode, I can see two running instances of BOINC from this chair.

One of them is stock v7.6.22: global_prefs.xml is datestamped 2nd. March

The other is a home-build from Head code, dated 22nd December. That one has a global_prefs.xml timestamped about two hours ago, coinciding with a scheduler reply received from LHC Classic: on receipt of that LHC reply, the Event Log registered some preference activity:

21/03/2016 13:41:58 | LHC@home 1.0 | Scheduler request completed: got 8 new tasks
21/03/2016 13:41:58 | LHC@home 1.0 | [sched_op] Server version 705
21/03/2016 13:41:58 | LHC@home 1.0 | Project requested delay of 6 seconds
21/03/2016 13:41:58 | SETI@home | General prefs: from SETI@home (last modified ---)
21/03/2016 13:41:58 | SETI@home | Computer location: work
21/03/2016 13:41:58 | SETI@home | General prefs: no separate prefs for work; using your defaults
21/03/2016 13:41:58 |  | Reading preferences override file
21/03/2016 13:41:58 |  | Preferences:
21/03/2016 13:41:58 |  | max memory usage when active: 7924.30MB
21/03/2016 13:41:58 |  | max memory usage when idle: 7924.30MB
21/03/2016 13:41:58 |  | max disk usage: 100.00GB
21/03/2016 13:41:58 |  | (to change preferences, visit a project web site or select Preferences in the Manager)
21/03/2016 13:41:58 | LHC@home 1.0 | [sched_op] estimated total CPU task duration: 16656 seconds

My SETI account general preferences page says

Preferences last modified: 1 Nov 2015, 15:29:42 UTC

and at LHC Classic:

Preferences last modified: 1 Nov 2015, 15:29:42 UTC

Looks like we have some cross-project research to do: I wonder if different projects running different versions of the BOINC server software transfer the general preferences in incompatible formats?

Interesting. FWIW, my SETI@home account shows: Preferences last modified: 23 Nov 2014, 1:24:06 UTC, which corresponds to the date I joined Asteroids@home. I later joined SETI Beta and Milkyway but neither had any effect on those global preferences.

SETI@home	11 Feb 2000
Asteroids@home  23 Nov 2014
SETI@home Beta 	11 Dec 2014
MilkyWay@home 	9 Apr 2015

The global_prefs.xml here on my daily driver, however, was last modified on 5 Dec 2014. Perhaps that was the first reboot of this box following my initial joining of Asteroids. Also, although my daily driver itself has never run Asteroids (or anything else except SETI Main), the content of the global_prefs.xml file shows Asteroids as the source.

Interesting. FWIW, my SETI@home account shows: Preferences last modified: 23 Nov 2014, 1:24:06 UTC, which corresponds to the date I joined Asteroids@home. I later joined SETI Beta and Milkyway but neither had any effect on those global preferences.

SETI@home	11 Feb 2000
Asteroids@home  23 Nov 2014
SETI@home Beta 	11 Dec 2014
MilkyWay@home 	9 Apr 2015

The global_prefs.xml here on my daily driver, however, was last modified on 5 Dec 2014. Perhaps that was the first reboot of this box following my initial joining of Asteroids. Also, although my daily driver itself has never run Asteroids (or anything else except SETI Main), the content of the global_prefs.xml file shows Asteroids as the source.

I believe the "source" will be the project where you most recently modified your global settings. I only change my BOINC global settings from the SETI@home site. As any global settings I make will be for SETI@home & other projects just have to deal with those settings.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

I agree with you completely, BilBg.

For over 45 years I have been a strong proponent for accurate, descriptive messages.

Messages containing only codes are a throwback to the days when both ram and data storage capacities were extremely limited.

Vague, misleading messages that can only be deciphered through documentation or searching the code were often due to being overly protective of either source code or jobs, or both.

Here is what I got from stdoutdae.txt logs that go back to October 2, 2015.
Interestingly, there is no log entry for Einstein.
If necessary, I can search compressed logs archived back to June 30, 2011.

21-Mar-2016 00:24:27 [SETI@home] General prefs: from SETI@home (last modified 08-Sep-2011 01:07:05)

21-Mar-2016 13:55:40 [climateprediction.net] General prefs: from climateprediction.net (last modified 08-Sep-2015 12:29:08)

As a side note - I feel this as a bug in BOINC
If it finds one of its files to be Read-Only (or generally any reason for "unable to write") BOINC should say so and not give misleading Messages

It's not that it's misleading message. Rather, it's no message at all. The 'can't parse scheduler reply' is a catch-all error message at the end of the processing that's always printed in case of error.

In addition to needing an additional message here, I think the 'can't parse' message should not be behind a debug flag. I don't think up/download error messages are behind debug flags either.

And I don't think failing to write the global prefs file should be fatal error like it is now. Sure, if the prefs file can't be written then the client will be using old prefs but not processing the rest of the scheduler reply isn't going to change that. Either way the client is stuck with old preferences. Opinions?

21/03/2016 13:41:58 | SETI@home | General prefs: from SETI@home (last modified ---)

In other words, mod_time=0 . Interesting.

21/03/2016 13:41:58 | SETI@home | General prefs: from SETI@home (last modified ---)

On that machine, every scheduler reply, from every project, both SETI and non-SETI, is producing a prefs update:

21/03/2016 18:18:05 | SETI@home | Scheduler request completed
21/03/2016 18:18:05 | SETI@home | General prefs: from SETI@home (last modified ---)
21/03/2016 18:18:05 | SETI@home | Computer location: work
21/03/2016 18:18:05 | SETI@home | General prefs: no separate prefs for work; using your defaults

In other words, mod_time=0 . Interesting.

Weeell - in a way.

All of the scheduler replies contain the same line:

  <mod_time>1446391782</mod_time></global_preferences>

(like that, all one line)

which translates to Sun, 01 Nov 2015 15:29:42 GMT - which is accurate, according to the websites I looked at before.

Edit - I mentioned I'm running some self-build clients. Three of the ones currently in use were built on 22 December 2015, to test cures for the Message from task: 0 I'd reported the day before. I only had one build system active then, so they were all built the same way. One 64-bit, and one 32-bit, are exhibiting the prefs problem, but another 64-bit - with identical timestamp - isn't. WTF?

It started on 16 February. This snippet unedited:

16-Feb-2016 13:41:20 [SETI@home] Scheduler request completed
16-Feb-2016 13:41:20 [SETI@home] [sched_op] Server version 707
16-Feb-2016 13:41:20 [SETI@home] Project requested delay of 303 seconds
16-Feb-2016 13:41:20 [SETI@home] [sched_op] handle_scheduler_reply(): got ack for task 17oc15ab.6380.19699.8.35.12.vlar_1
16-Feb-2016 13:41:20 [SETI@home] [sched_op] Deferring communication for 00:05:03
16-Feb-2016 13:41:20 [SETI@home] [sched_op] Reason: requested by project
16-Feb-2016 13:47:19 [SETI@home] Computation for task 15se15ad.23242.20108.14.41.112_1 finished
16-Feb-2016 13:47:19 [SETI@home] Starting task 18fe11af.19606.20517.7.34.60_1
16-Feb-2016 13:47:19 [SETI@home] [cpu_sched] Starting task 18fe11af.19606.20517.7.34.60_1 using setiathome_v8 version 800 in slot 1
16-Feb-2016 13:47:21 [SETI@home] Started upload of 15se15ad.23242.20108.14.41.112_1_0
16-Feb-2016 13:47:25 [SETI@home] Finished upload of 15se15ad.23242.20108.14.41.112_1_0
16-Feb-2016 14:47:47 [SETI@home] [sched_op] Starting scheduler request
16-Feb-2016 14:47:47 [SETI@home] Sending scheduler request: To report completed tasks.
16-Feb-2016 14:47:47 [SETI@home] Reporting 1 completed tasks
16-Feb-2016 14:47:47 [SETI@home] Not requesting tasks: don't need (CPU: job cache full; NVIDIA GPU: )
16-Feb-2016 14:47:47 [SETI@home] [sched_op] CPU work request: 0.00 seconds; 0.00 devices
16-Feb-2016 14:47:47 [SETI@home] [sched_op] NVIDIA GPU work request: 0.00 seconds; 0.00 devices
16-Feb-2016 14:47:49 [SETI@home] Scheduler request completed
16-Feb-2016 14:47:49 [SETI@home] [sched_op] Server version 707
16-Feb-2016 14:47:49 [SETI@home] Project requested delay of 303 seconds
16-Feb-2016 14:47:49 [SETI@home] General prefs: from SETI@home (last modified ---)

The first is normal, the second weird. Nothing in between.

OK, what happened on 16 Feb? It was a Tuesday, but my times are UTC - too early for maintenance.

Same time (to within 15 minutes) on both machines. And once busted, neither machine has stopped doing it, ever since.

  <mod_time>1446391782</mod_time></global_preferences>

Exactly like that, with two closing tags on the same line? I'm not sure if the not-really-XML parser supports that which then could explain mod_time becoming 0.

And I'm not sure if the <mod_time> should be at the end. In sched_request it's the second element in <global_preferences>. Are your hosts sending reasonably looking prefs to server?

  <mod_time>1446391782</mod_time></global_preferences>

Exactly like that, with two closing tags on the same line? I'm not sure if the not-really-XML parser supports that which then could explain mod_time becoming 0.

And I'm not sure if the <mod_time> should be at the end. In sched_request it's the second element in <global_preferences>. Are your hosts sending reasonably looking prefs to server?

Yes - exactly like that, pasted from Notepad++ (which handles the *nix line endings properly)

The sched_requests look OK, but contain

   <mod_time>0.000000</mod_time>

Global_prefs.xml doesn't contain a <mod_time> at all, which may be the beginnings of a clue. I suspect the first probe might be to shut down the client, supply the right <mod_time>, restart, and see what happens for the next few RPCs.

Edit - that seems to have got the right response at startup:

21/03/2016 22:53:41 | SETI@home | General prefs: from SETI@home (last modified 01-Nov-2015 15:29:42)

and it cured the phantom prefs update too.

Now, if I do a real prefs change on the site, will it propagate?