error condition i am not understanding

I recall a similar discussion about the O2MD1 search and the solution then was to accept CPU work and abort the lost tasks as they got downloaded. But the O2MDF doesn't have any CPU version according to this message.

I think Bernd has to look at this to help you clear the lost tasks before you can get new tasks.
I've sent him a PM.

Here's the thing.  Now that there is a new 'sub-run' with the plan class 02MDF (the run that is for CPUs is O2MD1), it is a run entirely for GPUs with no CPU app for this plan class.  So the message means exactly what it says - there is no CPU app version for O2MDF.  The implication of this is that the scheduler can't redirect a lost GPU test task to a CPU core any more.

The problem arises because of the rules for test apps - only 1 test task per quorum.  In this case nvidia tasks are trusted and AMD tasks are test tasks.  If an AMD task becomes lost, the scheduler isn't smart enough to understand that there is currently no test task in play.  If the nvidia task became lost, the scheduler would resend it.  If the AMD task becomes lost, the scheduler is not allowed to and so tries to send the lost task as a CPU task - hence the message you get.  The solution is for someone to fix the scheduler bug and allow the scheduler to understand that it's OK to send a second test task if the first test task is the one that has become lost.

So why do tasks become lost?  I understand one of the possible answers to that very well because in the last day or so I've seen it happen whilst I was in the process of transitioning a host from FGRPB1G to O2MDF.  The host was building up a stock of tasks for O2MDF.  I had made several successful small work cache increments, each resulting in about 5 - 10 tasks at a time.  Then there was a comms failure showing no scheduler reply to the next work request.

The server often tends to be quite slow so it can take a minute or more for the advice confirming the number of new tasks allocated.  This leaves a 'window of opportunity' for a temporary network glitch to prevent the scheduler reply from arriving.

So once the wait dragged on to the point that the request timed out, I knew there would be trouble.  After a couple of mins, the glitch was fixed and service was restored and in most cases this presents no problem.  The next scheduler contact should cause the 'lost tasks' to be noticed and resent, so you would normally be unaware of the temporary glitch.  However, increasingly, I have been noticing such glitches and I think quite a few are at the server end rather than somewhere else.  In this case however, I think it was my ISP.

So, how to recover from this?  I really don't know.  If you reset the project, the server will still be blocked by the 'one test task' rule.  The only way I can think of is to get an entirely new host ID if you want to immediately keep crunching these tasks on that host.  In my case, I'm allowing the remaining tasks to be finished and then it will go back to FGRPB1G until such time as the blocked resend tasks time out and are reallocated.  I imagine that might take 2 weeks.

Well, of course you don't have any - they've all become 'lost' :-). Check the server contact log properly and you'll see that you have a total of 54 tasks that the server is trying to resend to you but the rules of the game are preventing it from doing so. If you go back through your event log (stdoutdae.txt) for the time when the big work request was made (that should have given you 54 new tasks) I'm sure you'll find evidence of failure to receive a reply to the original request at that time - ie. some sort of network glitch that caused 54 tasks to become lost and thus create this entire difficulty

As an example of what to look for, here is exactly what I saw in the event log that alerted me to the problem.  I've annotated the log snippet with markers for a number of key points to make it easy to follow.

1. (##1) A successful work fetch triggered by a work cache size increase in BOINC Manager.
2. (##2) Lines of output resulting from a further local cache size increase.
3. (##3) While counting down to the next work fetch, a task is completed and uploaded.
4. (##4) 3 secs after upload completes, a new work fetch which also reports the completed task.
5. (##5) While awaiting the scheduler response, another task completes.
6. (##6) If you look carefully, this next task doesn't complete the upload before BOINC states comms failed
7. (##7) Just over a minute later the upload is retried and succeeds (the glitch was evidently quite short).
8. (##8) A new work fetch is initiated which also tries to report both completed tasks.  The response indicates that the scheduler had already received the report for the first task and acted on it.  That also means that there would have been new tasks sent which never made it to the client because of the network glitch at ##6.  So these are genuine lost tasks which under normal circumstances could easily have been resent if the scheduler had undertsood that there were no other test tasks except these already in existence.

12-Nov-2019 10:12:47 [E@H] Sending scheduler request: To fetch work.                                                     ##1
12-Nov-2019 10:12:47 [E@H] Requesting new tasks for AMD/ATI GPU
12-Nov-2019 10:13:15 [E@H] Scheduler request completed: got 7 new tasks
12-Nov-2019 10:13:36 [E@H] General prefs: from Einstein@Home (last modified 26-Nov-2016 15:12:08)                        ##2
12-Nov-2019 10:13:36 [E@H] Computer location: generic
12-Nov-2019 10:13:36 [E@H] General prefs: no separate prefs for generic; using your defaults
12-Nov-2019 10:13:36 [---] Reading preferences override file
12-Nov-2019 10:13:36 [---] Preferences:
12-Nov-2019 10:13:36 [---] max memory usage when active: 7509.97 MB
12-Nov-2019 10:13:36 [---] max memory usage when idle: 7905.23 MB
12-Nov-2019 10:13:36 [---] max disk usage: 20.00 GB
12-Nov-2019 10:13:36 [---] (to change preferences, visit a project web site or select Preferences in the Manager)
12-Nov-2019 10:13:58 [E@H] Computation for task h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0 finished                        ##3
12-Nov-2019 10:13:59 [E@H] Starting task h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_3_0
12-Nov-2019 10:14:01 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_0
12-Nov-2019 10:14:01 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_1
12-Nov-2019 10:14:07 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_1
12-Nov-2019 10:14:07 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_2
12-Nov-2019 10:14:13 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_0
12-Nov-2019 10:14:13 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_3
12-Nov-2019 10:14:15 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_3
12-Nov-2019 10:14:18 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0_2
12-Nov-2019 10:14:21 [E@H] Sending scheduler request: To fetch work.                                                               ##4
12-Nov-2019 10:14:21 [E@H] Reporting 1 completed tasks
12-Nov-2019 10:14:21 [E@H] Requesting new tasks for AMD/ATI GPU
12-Nov-2019 10:14:38 [E@H] Computation for task h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0 finished                       ##5
12-Nov-2019 10:14:39 [E@H] Starting task h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_1_0
12-Nov-2019 10:14:41 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_0
12-Nov-2019 10:14:41 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_1
12-Nov-2019 10:14:52 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_0
12-Nov-2019 10:14:52 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_1
12-Nov-2019 10:14:52 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_2
12-Nov-2019 10:14:52 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_3
12-Nov-2019 10:19:29 [---] Project communication failed: attempting access to reference site                                     ##6
12-Nov-2019 10:19:29 [E@H] Scheduler request failed: Timeout was reached
12-Nov-2019 10:19:40 [---] BOINC can't access Internet - check network connection or proxy configuration.
12-Nov-2019 10:19:59 [E@H] Temporarily failed upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_2: transient HTTP error
12-Nov-2019 10:19:59 [E@H] Backing off 00:01:15 on upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_2
12-Nov-2019 10:20:00 [E@H] Temporarily failed upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_3: transient HTTP error
12-Nov-2019 10:20:00 [E@H] Backing off 00:01:15 on upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_3
12-Nov-2019 10:21:15 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_2                                ##7
12-Nov-2019 10:21:16 [E@H] Started upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_3
12-Nov-2019 10:21:18 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_3
12-Nov-2019 10:21:19 [E@H] Finished upload of h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_6_0_2
12-Nov-2019 10:21:29 [E@H] Sending scheduler request: To fetch work.                                                               ##8
12-Nov-2019 10:21:29 [E@H] Reporting 2 completed tasks
12-Nov-2019 10:21:29 [E@H] Requesting new tasks for AMD/ATI GPU
12-Nov-2019 10:21:33 [E@H] Scheduler request completed: got 0 new tasks
12-Nov-2019 10:21:33 [E@H] Completed result h1_0653.45_O2C02Cl2In0__O2MDFG2_G34731_653.60Hz_7_0 refused: result already reported as success
12-Nov-2019 10:21:33 [E@H] No work sent
12-Nov-2019 10:21:33 [E@H] No work is available for Gravitational Wave search O2 Multi-Directional
12-Nov-2019 10:21:33 [E@H] see scheduler log messages on https://einsteinathome.org/host/541492/log

I've seen this exact same problem several times before.  I've tried to report it before.  I had less of a clue about what was going one then than I do now.  In that same thread, Zalster had 288 lost tasks that eventually came back as CPU tasks and then were aborted to get rid of them so that he could get fresh GPU tasks.  Other people have seen similar problems.  I would be very surprised if it's not the same issue of a test task becoming lost (for whatever reason) and then not being allowed to be resent. 

I think you give a very plausible explanation for what seems to be going on and I also think the response should be understandable even for one that haven't spent much time reading logs or thinking about how Boinc works.

I agree that the resend lost task feature is nice to have and if it were to be removed then the lost tasks would become ghosts that need to time out before the next copy gets sent out to try and form the quorum. It would slow down validation and cause the database to bloat if the network problems get frequent.

Yes it exists and it's a feature on the server. When Boinc contacts the server it sends a list of all tasks on your computer, the server then compares this to what it thinks you should have. If the lists don't match up the server then tries to resend the missing tasks to your computer. Those missing tasks are called "lost tasks" as the became lost somehow.

If Bernd can't or won't make a manual intervention then your will probably have to wait for the deadlines of the tasks to expire. That would normally be 14 days here but might differ sometimes, I don't run the O2MDF search so can't look it up.
An other option would be to force the server to give your host a new hostID, it will involve editing client_state.xml, ask if you want to go down this route.