Every task is marked as Invalid, if at the moment of 100% of progress the PC is offline on some obstacles, for example it lost the connection with Internet (this may happen quite often, if PC is connected by GSM connection).
I really do not know, what to say to the project technicians.

It's not a beautiful workaround, maybe preposterous to do, but since they run > 24 hours each [on my laptop], something that can be done without too much inconvenience:

A) Load up fresh on FAHB for e.g. 3 day buffer. (I have no trouble when I load up a fresh day's worth]
B) When off-line, suspend each task that has passed 90% and nearing 100. (Eventually, you'll have a bunch of > 90% complete)
C) When internet is back, let the transfer tab clear and trickles report (See the event log stops 'reporting trickle xyz like the sample below, with extra log flags)
3/14/2016 9:43:28 AM [sched_op] Starting scheduler request
3/14/2016 9:43:28 AM [trickle] read trickle file projects/www.worldcommunitygrid.org/trickle_up_FAH2_000081_avx38741_000096_0019_005_0_1457945004.xml
3/14/2016 9:43:28 AM Sending scheduler request: To send trickle-up message.
3/14/2016 9:43:28 AM Not requesting tasks: don't need (job cache full)
3/14/2016 9:43:28 AM [sched_op] CPU work request: 0.00 seconds; 0.00 devices
3/14/2016 9:43:30 AM Finished upload of FAH2_000081_avx38741_000096_0019_005_0_r2044393219_13
3/14/2016 9:43:31 AM Finished upload of FAH2_000081_avx38741_000096_0019_005_0_r2044393219_3
3/14/2016 9:43:31 AM Scheduler request completed
3/14/2016 9:43:31 AM [sched_op] Server version 701
3/14/2016 9:43:31 AM Project requested delay of 121 seconds
3/14/2016 9:43:31 AM [sched_op] Deferring communication for 00:02:01

D) Resume all suspended tasks and let them finish. (LAIM not needed to be on as FAHB checkpoints frequently)

Theory is, you get a wave of valids in one stats session.

I've done it, unplanned, and all went valid... suspending them when getting past 90%. [Not sure if the trickle handler insists on getting and processing them in sequence, but it seems Spock logic]. One problem may simply be that when trickle 10 comes in and the validator gets launched for the task, the trickle handler may not yet have churned through the previous last yet [it does over 2.5 million a day]... a timing issue, but compressed versus uncompressed transmission was mentioned as a problem. It seems the thing they would address, was not addressed [but lacking positive feedback "yes we did cover that base", it's a huge guess... maybe the techs did].

Summary: Test if it works for you going off-line [if willing to put up], crunch to 90, suspend task, then go on line and let them report, then resume.

Certainly Monday-Thursday you could start fresh FAHB before going home... don't know how fast your office machine is to not hit 100% in what I presume is something like a 16 to 8 away period. The scheduling in BOINC can be set also with a custom daily schedule as well.

If scripting/scheduling is something engageable, boinccmd can be used to read in different configs at different times. Else, yes having an office machine volunteered is nice, but I would not let me be distracted by BOINC. Choose whatever is convenient in other projects. Limited supply, so tasks in the feeder will get crunched anyhow.

"It has now been resent to two other hosts."?

FAH2 is true zero redundant, so not sure how to understand it being resent to 2 other hosts because of yours going invalid. Maybe if you post a copy of the distribution page, we can reconstruct why those 2 extra copies were issued.

Hi.

After getting another 3 tasks marked as Invalid for no reason that I can see, with over 40hrs gone down the drain, I'm going to pull the plug so to speak as I don't want to waste more time on this project.

And the tasks have all been resent twice right away. Is there something wrong with the validator.