Official BOINC application - https://play.google.com/store/apps/details?id=edu.berkeley.boinc

This application loses random crunched SETI@Home work units. I've run it on quad-core DEXP Ursus A270i and on quad-core Samsung SM-T530. Application thinks crunched work unit already sent and removes it from queue but SETI@Home server doesn't receive it. Thus, work unit becomes obsolete after timeout. For example, work unit 2069309013 has lost not so long ago and should become obsolete after April 14.

---

CX

A Work Unit is removed from display 24 hours after it has been validated. Thus if you have returned it, and the other wingman had already returned, and the two results validate, it will vanish from display just over 24 hours after your result was returned.
The "deadline" is the date after which the task is deemed to have died on the computer to which it was sent. If it hasn't been returned by that time it will be sent out to someone else, with a new deadline.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

If Commander Xell is absolutely certain that task 11oc11af.21318.19290.10.37.55_1 has been completed on his Android device and reported to the server, then neither of those situations applies: the task should either have been purged, or displayed on the website with one of the possible outcomes (success or error). The replica database is currently online and up to date, so there's nowhere else for it to hide.

I have no experience with the Android client, but the normal PC BOINC client doesn't remove a completed task from the list until it receives an active acknowledgement from the server: if a communication error occurs, the task remains visible in the user's Manager list until a subsequent re-report does receive the expected acknowledgement. This behaviour can be monitored with <sched_op_debug> logging.

21/03/2016 11:22:14 | SETI@home | [sched_op] handle_scheduler_reply(): got ack for task 23se10aa.23250.15216.5.32.98_1

There's one further possibility: if the Manager is set to display 'Active tasks only' (not sure if this is possible or normal with the Android client), a completed task will disappear from the Manager display on completion, before being reported to the server.

It's worth checking in detail with whatever Android logs are available: removal of the task from the client records before receipt of an acknowledgement of a successful report would be a bug.

Yes, I certain. I don't know how to reproduce the situation. However, Android application sometimes acts as described by Richard. I will try to find something interesting in logs and to report later.

---

CX

I have no experience with the Android client, but the normal PC BOINC client doesn't remove a completed task from the list until it receives an active acknowledgement from the server: if a communication error occurs, the task remains visible in the user's Manager list until a subsequent re-report does receive the expected acknowledgement.

The Android client is one ported from the same source as the Linux/OS X/Windows version of 7.4.41, no changes have been made in its scheduler. The only changes to that BOINC are in the GUI, as far as I know.

Comes to mind, how do Ghost Tasks occur again?

As for reporting a possible bug in that client, there is still no developer for Android found, so any bug reports will most probably go unanswered. Well, especially when reported on the Seti forums, but they won't fare much better on the BOINC forums either.

---

Yes, I certain. I don't know how to reproduce the situation. However, Android application sometimes acts as described by Richard. I will try to find something interesting in logs and to report later.

I see the server says that host currently has 6 tasks In progress. Is that true? I have found the Android BOINC client only downloads 1 task per active CPU and 0 extra cache.

---

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

Comes to mind, how do Ghost Tasks occur again?

A significant and relevant point.

When the server issues new task to the clients, it neither waits for nor expects an acknowledgement. Tasks are assumed to have reached the client come what may. If the outgoing message falls into a black hole, so be it. That's a ghost.

Returning tasks are ack'd as I illustrated - and if not ack'd, are sent again and again until they (and the reply) both get through. In that respect, the client-server interactions are asymmetric: I suppose results are treated as being more valuable, tasks can be sent to someone else.

Comes to mind, how do Ghost Tasks occur again?

A significant and relevant point.

So unless Commander Xell finds mention in the log about task 11oc11af.21318.19290.10.37.55_1 being uploaded/reported, it could just as well have been a hiccup on the line when the task got in, and the servers sees it as being there, but the client does not.

And with Seti's "Resend lost tasks" turned off again (??) it won't be resent at this time.

---