Firstly, I would like to apologize if this is the wrong section. There doesn't appear to be a section for Android, so I figured the Unix/Linux section would be the most closely relevant.

I have a current SETI@Home task on the Android version which is sitting around 529319802675154000000000000.000%. This is after about 24 hours of CPU time which has usually been enough to complete previous tasks.





If any other information would be beneficial to correcting this issue, please let me know.

This thread can be closed/deleted. Upon suspending other projects, then resuming them, it caused the percentage to return to a reasonable number.

---

Moved from Q&A - I know some of you have been doing things with Android and may be interested Wizard Fait's progress

---

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

I saw that a few times, but wasn't sure if it was my old phone or the app doing it. I restarted my phone or the app and after the next checkpoint it corrected itself.

However the author of the app(s) might still be monitoring this thread: Seti android app.

If not you could submit a bug report on their website.

---

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

Thank you very much! I have sent an email to the developer using the site given.

---

I encountered this same problem when I was testing SetiApp on HTC Wildfire S. Unfortunatelly I couldn't find bug. I captured 'weird' workunit and computed on my tablet (VFP and NEON code) and I didn't catch weird progress :( (and I got correct results). Tomorrow I will try to compute on HTC Wildfire S. Sorry :(.
May be this is bug in the Android (???). I dont know :(

I encountered this same problem when I was testing SetiApp on HTC Wildfire S. Unfortunatelly I couldn't find bug. I captured 'weird' workunit and computed on my tablet (VFP and NEON code) and I didn't catch weird progress :( (and I got correct results). Tomorrow I will try to compute on HTC Wildfire S. Sorry :(.
May be this is bug in the Android (???). I dont know :(

The converse problem (elapsed time increasing, but progress %age remaining static) is well observed at SETI, but equally unsolved.

But the number in the image is too large to have been reached by gradual increments - that would have taken the age of several universes.

Most recent cases of outlandishly large numbers - from the NVidia GPU 'wacky memory' bug, to the extended-length WU names at this project - have turned out to be the result of storing 32-bit data in 64-bit memory locations, and failing to initialise or zero the most significant 32 bits of the variable.