Fixed it. It has to start with;

   <app>
      <name>setiathome_v8</name>
   </app>

picky computers...

Yes, they're picky. Actually, those lines were there - you were missing

<app_name>setiathome_v8</app_name>

from <app_version>

try revision: 3306

Thanks Raistmer, seems to be working now. Two new Apps built with r3306, we'll see if they are any better;
Build features: SETI8 Non-graphics OpenCL USE_OPENCL_NV OCL_CHIRP3 ASYNC_SPIKE FFTW SSSE3 64bit
The one compiled with just the -DUSE_OPENCL was working just fine, I wonder if it will work with the old iMacs with the HD4 GPUs...

Yeah, the PIE version of vfpv3d16 also has the no-checkpoint problem. That's unfortunate, because for v7 vfpv3d16 is the version that is compatible with the most devices. I'll let it run for another day or two before I deprecate that version, just to see if any clues arise.

I'm having problems with the v8.00 (armv7-vfpv3) version on my 2012 Nexus 7, all three Wu's show a little progress before resetting back to Zero repeatedly:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=21582626

WARNING: linker: ../../projects/setiweb.ssl.berkeley.edu_beta/setiathome_8.00_arm-android-linux-gnu__armv7-vfpv3 has text relocations. This is wasting memory and prevents security hardening. Please fix.
WARNING: linker: setiathome_8.00_arm-android-linux-gnu__armv7-vfpv3 has text relocations. This is wasting memory and prevents security hardening. Please fix.
Unable to resolve function unwind_backtrace_signal_arch
Unable to resolve function acquire_my_map_info_list
Unable to resolve function release_my_map_info_list
Unable to resolve function get_backtrace_symbols
Unable to resolve function free_backtrace_symbols
Unable to resolve function format_backtrace_line
Unable to resolve function load_symbol_table
Unable to resolve function free_symbol_table
Unable to resolve function find_symbol
one or more symbols not found. stackdumps unavailable
WARNING: linker: ../../projects/setiweb.ssl.berkeley.edu_beta/setiathome_8.00_arm-android-linux-gnu__armv7-vfpv3 has text relocations. This is wasting memory and prevents security hardening. Please fix.
WARNING: linker: setiathome_8.00_arm-android-linux-gnu__armv7-vfpv3 has text relocations. This is wasting memory and prevents security hardening. Please fix.
Unable to resolve function unwind_backtrace_signal_arch
Unable to resolve function acquire_my_map_info_list
Unable to resolve function release_my_map_info_list
Unable to resolve function get_backtrace_symbols
Unable to resolve function free_backtrace_symbols
Unable to resolve function format_backtrace_line
Unable to resolve function load_symbol_table
Unable to resolve function free_symbol_table
Unable to resolve function find_symbol
one or more symbols not found. stackdumps unavailable

The v8.00 (armv7-vfpv3d16) version seems to be running OK on my Samsung S5 mini,
It shows progress, and increasing Elapsed time, But restarting the phone, shows that no progress has been made:

http://setiweb.ssl.berkeley.edu/beta/result.php?resultid=21581575

WARNING: linker: ../../projects/setiweb.ssl.berkeley.edu_beta/setiathome_8.00_arm-android-linux-gnu__armv7-vfpv3d16 has text relocations. This is wasting memory and is a security risk. Please fix.
WARNING: linker: ../../projects/setiweb.ssl.berkeley.edu_beta/setiathome_8.00_arm-android-linux-gnu__armv7-vfpv3d16 has text relocations. This is wasting memory and is a security risk. Please fix.

Claggy

ATI HD5 OpenCL version has been released to beta.

Eric, is the following up to date with the v8 planclasses?:

http://setiweb.ssl.berkeley.edu/beta/plan_class_spec.xml

TRuEQ & Tuvalu is reporting inability at getting Seti v8 ATI GPU work,
But since he's got 'Use CPU' disabled, and hasn't done any CPU Seti v8 work there's no proof that he's got his preferences right,
It's also possible that he's got enough work from the rest of his projects that Boinc simply won't ask for work from here.

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=2264&postid=55577

Claggy

That's the file directly from the project directory. The SETI@home one is soft linked to the beta one, so they are identical.

I'm beginning to think that a bug has been introduced to BOINC such that you can't do anonymous platform work for a new app unless have already received non-anonymous platform work. It appears to have to do with updating the client_state.xml file in the BOINC directory to reflect the new app. It only seems to happen when work is received for the new app, and anonymous platform doesn't work until client_state.xml has been updated.

This is still a guess, but ask them to try fetching CPU work. If I'm right after successfully getting CPU work, they will be able to get anonymous platform work.

---

That's the file directly from the project directory. The SETI@home one is soft linked to the beta one, so they are identical.

I'm beginning to think that a bug has been introduced to BOINC such that you can't do anonymous platform work for a new app unless have already received non-anonymous platform work. It appears to have to do with updating the client_state.xml file in the BOINC directory to reflect the new app. It only seems to happen when work is received for the new app, and anonymous platform doesn't work until client_state.xml has been updated.

This is still a guess, but ask them to try fetching CPU work. If I'm right after successfully getting CPU work, they will be able to get anonymous platform work.

I'm thinking it is to do with running Anonymous platform/Stock on Boinc 7.4.x and earlier, (The latest Boinc for Android is only 7.4.41)
I'm successfully running the Stock Windows Seti v8 app on Boinc 7.6.22 (along with the graphics app) on the Main project under Anonymous platform:

All SETI@home v8 tasks for computer 7054027

Brent Norman - Canada is reporting problems getting the Windows Seti v8 app working on Boinc 7.4.42 under Anonymous platform:

http://setiathome.berkeley.edu/forum_thread.php?id=78702&postid=1753224

I suggested he upgraded to Boinc 7.6.22, But he has yet to do it.

Claggy

Hmmm. It seems like they are getting stuck either in fftw planning code or our own planning code. Are the machines that have versions that seem to be working low memory machines?

They are, 222.48 MB and 391.71 MB.

---

Mists of dreams drip along the nascent echo, and love no more.

End of line.

Bad news travels faster than the speed of light, good news never leaves the room.

That's the file directly from the project directory. The SETI@home one is soft linked to the beta one, so they are identical.

I'm beginning to think that a bug has been introduced to BOINC such that you can't do anonymous platform work for a new app unless have already received non-anonymous platform work. It appears to have to do with updating the client_state.xml file in the BOINC directory to reflect the new app. It only seems to happen when work is received for the new app, and anonymous platform doesn't work until client_state.xml has been updated.

This is still a guess, but ask them to try fetching CPU work. If I'm right after successfully getting CPU work, they will be able to get anonymous platform work.

That seems unlikely - I've never heard of any such problem, though no other project uses anonymous platform as extensively as we do. Assuming you're suggesting that any such effect applies in the client only (not any artefact of there being no host_app_ver record on the server), I'll test tomorrow by detaching one of mine from the project and installing an app_info before re-attaching.

The problems earlier in this thread about state file errors were all to do with badly-formed app_info files, so I don't think they can be taken as evidence.

Hmmm. It seems like they are getting stuck either in fftw planning code or our own planning code. Are the machines that have versions that seem to be working low memory machines?

They are, 222.48 MB and 391.71 MB.

That pretty much seals it as being either in FFTW's benchmarking or our benchmarking. I guess I'll deprecate all the arm-android versions.

Is there anyone with an x86-android device that can tell me whether the same problem exists there?

---

Good evening I just started v8 on my phone tonight(my phone is an LG G4 AArch 64 processor rev. 2 Android 3.10.49-gfcc4149-00001-g7691e96(andriod5.1) I will be happy to let you know how things go to help the project I do think that I need to reset the checkpoints since I started it got to 2.4% and I had to take my phone off of charge for a little while and progress went back to 0 so I will change the save points and see how things go(I will not have to go anywhere until 5:00 am tomorrow my time)

---

ME AND MY BOY LOOKING FOR E.T.

Good evening I just started v8 on my phone tonight(my phone is an LG G4 AArch 64 processor rev. 2 Android 3.10.49-gfcc4149-00001-g7691e96(andriod5.1) I will be happy to let you know how things go to help the project I do think that I need to reset the checkpoints since I started it got to 2.4% and I had to take my phone off of charge for a little while and progress went back to 0 so I will change the save points and see how things go(I will not have to go anywhere until 5:00 am tomorrow my time)

Eric was asking for someone with an x86 Android device to report whether the problem existed there, ie most Likely with an Intel Atom processor,
Not your ARM AArch64 processor, that isn't an x86 processor.

Claggy

That's the file directly from the project directory. The SETI@home one is soft linked to the beta one, so they are identical.

I'm beginning to think that a bug has been introduced to BOINC such that you can't do anonymous platform work for a new app unless have already received non-anonymous platform work. It appears to have to do with updating the client_state.xml file in the BOINC directory to reflect the new app. It only seems to happen when work is received for the new app, and anonymous platform doesn't work until client_state.xml has been updated.

This is still a guess, but ask them to try fetching CPU work. If I'm right after successfully getting CPU work, they will be able to get anonymous platform work.

I was able to catch work on both devices right from scratch.
The first tasks i got was for GPU.

---

With each crime and every kindness we birth our future.

That's the file directly from the project directory. The SETI@home one is soft linked to the beta one, so they are identical.

I'm beginning to think that a bug has been introduced to BOINC such that you can't do anonymous platform work for a new app unless have already received non-anonymous platform work. It appears to have to do with updating the client_state.xml file in the BOINC directory to reflect the new app. It only seems to happen when work is received for the new app, and anonymous platform doesn't work until client_state.xml has been updated.

This is still a guess, but ask them to try fetching CPU work. If I'm right after successfully getting CPU work, they will be able to get anonymous platform work.

That seems unlikely - I've never heard of any such problem, though no other project uses anonymous platform as extensively as we do. Assuming you're suggesting that any such effect applies in the client only (not any artefact of there being no host_app_ver record on the server), I'll test tomorrow by detaching one of mine from the project and installing an app_info before re-attaching.

The problems earlier in this thread about state file errors were all to do with badly-formed app_info files, so I don't think they can be taken as evidence.

I think we can finally put this to bed in the "false alarm" category. A number of points:

1) I've just detached my Haswell from SETI Main (which removes practically everything - project directory and client_state entries), and uninstalled BOINC. Then, I put back a project directory with a minimal app_info.xml and just enough files to run one test app. Then I put back my SETI@Home account file (saved for the purpose - it's deleted by the detach), and installed BOINC v7.4.42. On restarting BOINC, it went through project initialisation in anonymous platform mode:

03/01/2016 17:33:06 | SETI@home | Found app_info.xml; using anonymous platform
03/01/2016 17:33:06 | SETI@home | URL http://setiathome.berkeley.edu/; Computer ID not assigned yet; resource share 100
03/01/2016 17:33:06 | SETI@home | General prefs: from SETI@home (last modified 01-Nov-2015 00:00:00)
03/01/2016 17:33:06 | SETI@home | Computer location: work
03/01/2016 17:33:23 | SETI@home | [sched_op] Fetching master file
03/01/2016 17:33:23 | SETI@home | Fetching scheduler list
03/01/2016 17:33:25 | SETI@home | [sched_op] Got master file; parsing
03/01/2016 17:33:25 | SETI@home | [sched_op] Found 1 scheduler URLs in master file
03/01/2016 17:33:25 | SETI@home | Master file download succeeded
03/01/2016 17:33:30 | SETI@home | sched RPC pending: Project initialization
03/01/2016 17:33:30 | SETI@home | [sched_op] Starting scheduler request
03/01/2016 17:33:30 | SETI@home | Sending scheduler request: Project initialization.
03/01/2016 17:33:30 | SETI@home | Requesting new tasks for CPU and Intel GPU
03/01/2016 17:33:30 | SETI@home | [sched_op] CPU work request: 1.00 seconds; 0.00 devices
03/01/2016 17:33:30 | SETI@home | [sched_op] Intel GPU work request: 1.00 seconds; 0.00 devices
03/01/2016 17:33:32 | SETI@home | Scheduler request completed: got 1 new tasks

and loaded up normally from there. (All SETI@home v8 tasks for computer 7118033)

2) The error messages from client_state ("State file error: bad application name") exactly match the typing error (missing line) in the posted app_info.xml files:

     ...
     <app_version>
     <platform>x86_64-pc-linux-gnu</platform>
     <version_num>800</version_num>   
     <avg_ncpus>1.000000</avg_ncpus>
     <max_ncpus>1.000000</max_ncpus>
      <file_ref>
     ... 

(both from message 55567)

3) We've had a report from the main project (Marco Franceschini, message 1753626) of the 'continually re-starting, before even starting function choices and FFTW wisdom generation' problem, and he's attributed it to "a issue caused by Comodo Internet Security 2015." - over-zealous anti-virus, which would explain the symptoms perfectly.

Cool. I'll put the OpenCL ones out to beta today. CPU ones in a couple days. Is the HD5 one changed from what I've already got in beta?

---

Ah. I knew I'd seen a post by Eric on dynamic linking of Mac applications - but it was a different Eric!

Eric Driver at NumberFields@Home

Problem:

dyld: Library not loaded: /Users/eric/BOINC_Project/Pari/pari-2.8-1711-ge5c317c/Odarwin-i386/libpari-2.8.dylib
Referenced from: /Volumes/Macintosh HD/Users/Shared/BOINC Data/slots/2/../../projects/numberfields.asu.edu_NumberFields/GetDecics_2.08_x86_64-apple-darwin
Reason: image not found

Solution:

For some reason it grabs the dynamic library first, even though I tell it to use the static version. It used to not do this. The only thing that seemed to work was deleting the dynamic library so it had no choice but to use the static one.

Cool. I'll put the OpenCL ones out to beta today. CPU ones in a couple days. Is the HD5 one changed from what I've already got in beta?

Perhaps not. I just mailed you link to Lunatics post with the same apps so take from source more convenient to you.
Regarding CPU apps - it's AKv8 code tree based ones. Before these CPU builds never were made part of stock but if you feel they are ready for that let it be so. In our tests they are faster than stock build on compatible hardware (their compatibility more limited of course). So I hope they will give some speedup for project indeed being deployed from Berkeley's servers too. Would be nice addition to v8 improvements!

---

News about SETI opt app releases: https://twitter.com/Raistmer

Cool. I'll put the OpenCL ones out to beta today.

+1. OpenCl client seems to be stable...

I guess it is ok ro run .3299 ATI HD5 on main. If not let me know.
I run 1 quad with 2 X ATI 5850 on win7 64-bit
And I just had to get an oldie out of the closet so the other computor is ATI 5970(2GPU) + 1 ATI 5850 with a 2GB win Vista 32-bit machine.

So far both machines feels ok. :) I just need to change position of 2 newly installed chassis fans that blows in the wrong direction. *heh*

Eric,

On Main there's a Mac failing with the following message:

<core_client_version>7.0.28</core_client_version>
<![CDATA[
<message>
process got signal 5
</message>
<stderr_txt>
dyld: Symbol not found: ___stack_chk_guard
  Referenced from: /Library/Application Support/BOINC Data/slots/2/../../projects/setiathome.berkeley.edu/setiathome_8.00_i686-apple-darwin
  Expected in: /usr/lib/libSystem.B.dylib


</stderr_txt>
]]>

The machine is running Darwin 8.11.1 = OS X v10.4.11 . Maybe Charlie baked in a minimum OS requirement.

Eric, small cosmetic bug discovered and fixerd in OpenCL GPU builds (printing TUNE option values and few others). Nothing serious but please postpone release a little while I rebuild...

---

News about SETI opt app releases: https://twitter.com/Raistmer