Daily Quota

Big mistake right there ... :-).

Here's a tip for you. If you ever again find a host with a large slab (or all) of its work cache trashed by something silly like a failed checksum or a missing file, do NOT 'manually' send them in by clicking 'update'. They will be counting down the remaining part of some timeout that was assigned at the time the 'error' was discovered. This is your 'window of opportunity' so just say a little 'thank you' to BOINC for not having returned them all at this point. Then quickly shut down BOINC - after noting the names of just the trashed tasks if there are 'good' ones left as well. Also note the names of any completed tasks so you can be sure to leave them untouched.

Essentially what you are going to do is remove (or 'correct' if you're a masochist) the blocks for all trashed tasks from the state file (client_state.xml). You would also do as Claggy suggested and download a fresh copy of the file that caused the problem in the first place. When your client is restarted and talks to the server, the server will notice all the missing results, declare them to be 'lost', and will very obligingly send you brand new copies to replace them, thus 'fixing' your state file for you. If you really are a masochist, you will do the 'fixing' yourself, perhaps to save yourself the ignominy of having the server know that you've been fiddling with your state file, naughty boy :-). The 'fixing' is relatively simple but rather tedious if you have to visit 112 individual blocks to remove the error details that have been inserted there and to fix other things like status flags, etc. It's quite doable, just tedious. Much quicker to completely remove the entire blocks and have the server resend them to you.

That's the simple overview - the devil is in the details :-). After you fix or remove all the blocks for trashed tasks, you need to search through the rest of the state file for other 'damage'. This is quite easy to find as it always seems to be setting a status flag with a negative number denoting an error condition. I always just search for the string '>-'. There are not many flag values that start with a minus so you will easily find things like '-119' or -161, which are two of the values I remember seeing in past episodes of state file fixing. The status needs to be changed back to '1' for files (like your example) that have been sent out to you. For finished data to be uploaded, the status is '0' - if I remember this all correctly :-). I probably do a couple of these 'fixes' per year and I always work it out from the context, rather than writing it down in intricate detail :-). After all, who bothers reading the manual if you can just wing it :-).

The other thing I do is preserve all downloaded data files associated with onboard tasks. For example, for BRP5, these will be the files starting with 'PB...' and ending in '.bin4' or '.zap' For 100+ tasks, this represents a lot of data. You need to take a backup copy of it all just after shutting down BOINC. When BOINC restarts, it is likely to delete the data for s you have removed from the state file. So, anything deleted by BOINC because of this, can easily be restored just before you initiate the contact with the server that will discover the lost results. Then when the server sends batches of lost results, you will not need the downloads. You will see messages saying "... file exists, skipping download."

I've used this procedure successfully many times over the years. For a case like yours, it would have taken about 15 mins or so and would have avoided the daily quota issues.

Another point, what happened to the host you linked to? It no longer has any tasks at all and the hostID isn't listed as one of yours any more? Did you create a new hostID to get around the backoff and then merge in the old one? Ah yes, it seems you did!!