Upps.... I don't think this is healthy, currently there is no 3.05 S5R6 app for Windows (the app version didn't change so it's x.01 on all platforms), but there could be in the future, so you don't want to have a 305 S5R6 version in your app_info.xml.
Is having one in client_state.xml a problem? If yes I won't be the only person in trouble (the app_info file I'm using was made by someone else here) and on machines that are app_info free the app_version element is lingering in client_state.xml
this is from client_state.xml on a machine that used to (but no longer does) have an a copy of offending app_info.xml files.
...and success in eradicating the app_info file without needing to do a reset.
The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.
Edit: I see that Gary made a more useful version of this comment while I was away typing.
:-).
Often I'm the one that gets 'beaten' but you get lucky sometimes :-).
Actually, I left out one other course of action which would be the one I'd do if Dan was employing me as a consultant :-).
Unless you really know what you are doing, this is probably a bit scary - but it's actually safer than trying to futz with task branding and then getting app_info.xml right. Here are the steps
* Set NNT and wait for all ABP2 tasks to finish (I'm presuming that there are very few, if any, of those).
* When you only have GW left, suspend all unstarted ones and wait for the 'in-flight' GW's to finish - it doesn't matter about any other project tasks. However you may wish to stop other projects trying to 'fill the gap' just before you suspend the GW tasks.
* When all 'in-flight' GW's are finished and reported, completely stop BOINC.
* Delete app_info.xml but nothing else.
* Make a backup copy of your BOINC Data folder (just in case ...)
* Open the main state file (client_state.xml) with a text editor like notepad (not a browser) and scroll down until you find the start of the E@H project.
* After the closing tag, look for any ... clauses and delete any that refer to S5R* making sure to remove only the tags and what is between them.
* Then look for ... tags which refer to S5R5 executables and delete them as before. make sure you leave any of these tags that refer to data files, sun, earth, h1_*, l1_*, etc well alone.
* Keep scanning down the file past large numbers of tags that contain the internal tags , , and . These are some sort of output templates that get filled in when tasks are crunched and then will contain a value other than zero. There will be as many of these 's as there are suspended tasks. These tags should be left alone.
Following these there will be ... tags which have actually been inserted from your app_info.xml. You need to delete these so that BOINC has a 'clean slate' when it restarts. This avoids any need for a project reset.
Following these you will find ... tags which you will also not touch. These clauses are quite large and have an easily recognisable internal structure where all the large data files involved are listed. They also contain the parameters used by the app to crunch a task. Once again there will be as many of these as there are suspended tasks.
Then you will come to the bit you are really looking for - the ... tags which will contain the version number branding amongst other things. These are the result templates sent to you and which E@H will always resend if they become 'lost'. So the key trick is to 'lose' them all and have the server resend them all. This way all the task branding will be fixed up in one fell swoop. If you have 100 suspended tasks, you will find 100 tags, each containing a which is the name you see on the tasks list in BOINC Manager. These are all to be deleted, being careful not to delete anything past the very last tag. This will be quite close to the end of the E@H section of client_state.xml.
* Having removed all your wrongly branded results you can save your state file. Before restarting BOINC, disconnect your network cable temporarily so that if all goes pearshaped you can stop BOINC and revert to your saved copy. If BOINC restarts without major complaint (eg systax errors) you can plug your cable back in and check that your S5R6 and ABP2 apps are still in your project folder. If they are not, insert new copies to save unnecessary downloading.
* Now you can ANT (reverse of NNT) and 'update'. You should expect to see a flood of red (quite alarming the first time I saw it :-) ) but it will simply be all your lost tasks being restored to you. Gotta love that feature :-).
I've tried to be as complete as possible with the above instructions. I've used this 'resend lost results' trick about 20 times in the last couple of years so I know it works. In my case it was mainly to get rid of corrupted tasks where the network was fortunately disabled (I turn off the comms during my ISP's 'peak' charge period) and the whole cache had errored out due to spurious errors related to corruption during unzipping, etc, rather than an actual crunch error. It's a long story but the recovery was always successful when there hadn't been any communication with the servers.
If you want to try this and you need more instructions, please ask.
...and success in eradicating the app_info file without needing to do a reset.
The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.
I see you have moved on quite a ways while I was composing my marathon piece :-).
You may have already 'fixed' your problem if I interpret you correctly by getting an app_info.xml that works correctly. Are you saying that you are now crunching GW tasks under AP but using the correct S5R6 application?
When bailing out of AP, there are three key strategies -
1. Set NNT, empty cache and report, delete app_info, reset the project, get everything (data & apps) fresh.
2. Set NNT, empty cache and report, delete app_info ONLY, remove AP stuff from client_state, DON'T reset, get new apps & tasks but keep existing large data files.
3. Stop BOINC anytime, delete app_info ONLY, edit client_state to remove inserted AP stuff, add to client_state 'official' files and signatures from another machine, restart BOINC and continue on from where you left off.
This third option applies where the AP app and the 'official' app are the same name and version (eg a beta test app has just been made official). You obviously know what you are doing so the above should be clear to you. I've actually done option 3. in the past but it was a while ago (Bernd doesn't seem to run beta test apps any more) and my memory may have forgotten something else that was obvious at the time ;-).
...and success in eradicating the app_info file without needing to do a reset.
The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.
I see you have moved on quite a ways while I was composing my marathon piece :-).
You may have already 'fixed' your problem if I interpret you correctly by getting an app_info.xml that works correctly. Are you saying that you are now crunching GW tasks under AP but using the correct S5R6 application?
I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.
I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.
Aaahhh... that 'last thing' being the copying of the blocks containing the 'official' signatures, I presume?
I didn't, at first glance, realise that
Quote:
The missing element was needing to cope the blocks to the client_state.xml as well.
actually meant 'inserting the missing signatures' :-). I actually used to put signatures into app_info.xml but these days I think BOINC sees it as 'illegal' {for obvious reasons) to do that :-).
I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.
Aaahhh... that 'last thing' being the copying of the blocks containing the 'official' signatures, I presume?
I didn't, at first glance, realise that
Quote:
The missing element was needing to cope the blocks to the client_state.xml as well.
actually meant 'inserting the missing signatures' :-). I actually used to put signatures into app_info.xml but these days I think BOINC sees it as 'illegal' {for obvious reasons) to do that :-).
RE: Upps.... I don't think
)
Is having one in client_state.xml a problem? If yes I won't be the only person in trouble (the app_info file I'm using was made by someone else here) and on machines that are app_info free the app_version element is lingering in client_state.xml
this is from client_state.xml on a machine that used to (but no longer does) have an a copy of offending app_info.xml files.
einstein_S5R6
305
windows_intelx86
1.000000
1.000000
1360623717.060821
6.3.0
einstein_S5R5_3.05_windows_intelx86.exe
einstein_S5R5_3.05_windows_intelx86_0.exe
einstein_S5R5_3.05_windows_intelx86_1.exe
einstein_S5R5_3.05_windows_intelx86_2.exe
einstein_S5R5_3.05_graphics_windows_intelx86.exe
graphics_app
[/pre]
...and success in eradicating
)
...and success in eradicating the app_info file without needing to do a reset.
The missing element was needing to cope the blocks to the client_state.xml as well. Apparently only app_info executables can get away without being signed.
RE: Edit: I see that Gary
)
:-).
Often I'm the one that gets 'beaten' but you get lucky sometimes :-).
Actually, I left out one other course of action which would be the one I'd do if Dan was employing me as a consultant :-).
Unless you really know what you are doing, this is probably a bit scary - but it's actually safer than trying to futz with task branding and then getting app_info.xml right. Here are the steps
* Set NNT and wait for all ABP2 tasks to finish (I'm presuming that there are very few, if any, of those).
* When you only have GW left, suspend all unstarted ones and wait for the 'in-flight' GW's to finish - it doesn't matter about any other project tasks. However you may wish to stop other projects trying to 'fill the gap' just before you suspend the GW tasks.
* When all 'in-flight' GW's are finished and reported, completely stop BOINC.
* Delete app_info.xml but nothing else.
* Make a backup copy of your BOINC Data folder (just in case ...)
* Open the main state file (client_state.xml) with a text editor like notepad (not a browser) and scroll down until you find the start of the E@H project.
* After the closing tag, look for any ... clauses and delete any that refer to S5R* making sure to remove only the tags and what is between them.
* Then look for ... tags which refer to S5R5 executables and delete them as before. make sure you leave any of these tags that refer to data files, sun, earth, h1_*, l1_*, etc well alone.
* Keep scanning down the file past large numbers of tags that contain the internal tags , , and . These are some sort of output templates that get filled in when tasks are crunched and then will contain a value other than zero. There will be as many of these 's as there are suspended tasks. These tags should be left alone.
Following these there will be ... tags which have actually been inserted from your app_info.xml. You need to delete these so that BOINC has a 'clean slate' when it restarts. This avoids any need for a project reset.
Following these you will find ... tags which you will also not touch. These clauses are quite large and have an easily recognisable internal structure where all the large data files involved are listed. They also contain the parameters used by the app to crunch a task. Once again there will be as many of these as there are suspended tasks.
Then you will come to the bit you are really looking for - the ... tags which will contain the version number branding amongst other things. These are the result templates sent to you and which E@H will always resend if they become 'lost'. So the key trick is to 'lose' them all and have the server resend them all. This way all the task branding will be fixed up in one fell swoop. If you have 100 suspended tasks, you will find 100 tags, each containing a which is the name you see on the tasks list in BOINC Manager. These are all to be deleted, being careful not to delete anything past the very last tag. This will be quite close to the end of the E@H section of client_state.xml.
* Having removed all your wrongly branded results you can save your state file. Before restarting BOINC, disconnect your network cable temporarily so that if all goes pearshaped you can stop BOINC and revert to your saved copy. If BOINC restarts without major complaint (eg systax errors) you can plug your cable back in and check that your S5R6 and ABP2 apps are still in your project folder. If they are not, insert new copies to save unnecessary downloading.
* Now you can ANT (reverse of NNT) and 'update'. You should expect to see a flood of red (quite alarming the first time I saw it :-) ) but it will simply be all your lost tasks being restored to you. Gotta love that feature :-).
I've tried to be as complete as possible with the above instructions. I've used this 'resend lost results' trick about 20 times in the last couple of years so I know it works. In my case it was mainly to get rid of corrupted tasks where the network was fortunately disabled (I turn off the comms during my ISP's 'peak' charge period) and the whole cache had errored out due to spurious errors related to corruption during unzipping, etc, rather than an actual crunch error. It's a long story but the recovery was always successful when there hadn't been any communication with the servers.
If you want to try this and you need more instructions, please ask.
Cheers,
Gary.
RE: ...and success in
)
I see you have moved on quite a ways while I was composing my marathon piece :-).
You may have already 'fixed' your problem if I interpret you correctly by getting an app_info.xml that works correctly. Are you saying that you are now crunching GW tasks under AP but using the correct S5R6 application?
When bailing out of AP, there are three key strategies -
1. Set NNT, empty cache and report, delete app_info, reset the project, get everything (data & apps) fresh.
2. Set NNT, empty cache and report, delete app_info ONLY, remove AP stuff from client_state, DON'T reset, get new apps & tasks but keep existing large data files.
3. Stop BOINC anytime, delete app_info ONLY, edit client_state to remove inserted AP stuff, add to client_state 'official' files and signatures from another machine, restart BOINC and continue on from where you left off.
This third option applies where the AP app and the 'official' app are the same name and version (eg a beta test app has just been made official). You obviously know what you are doing so the above should be clear to you. I've actually done option 3. in the past but it was a while ago (Bernd doesn't seem to run beta test apps any more) and my memory may have forgotten something else that was obvious at the time ;-).
Cheers,
Gary.
RE: RE: ...and success in
)
I was well ahead of you. I had them running on the s5r6 executable as of post 102064. This one was where I found the last thing I needed to edit to remove the app_info without any problems.
RE: I was well ahead of
)
Aaahhh... that 'last thing' being the copying of the blocks containing the 'official' signatures, I presume?
I didn't, at first glance, realise that
actually meant 'inserting the missing signatures' :-). I actually used to put signatures into app_info.xml but these days I think BOINC sees it as 'illegal' {for obvious reasons) to do that :-).
Cheers,
Gary.
RE: RE: I was well ahead
)
yup