CompletedUnits.csv - Atoms is being written with Credit value. Some units are showing up twice in the data.

[GoogleCodeExporter]

What steps will reproduce the problem?

- Atoms is being written with Credit value.  The "pass-through" property in
the UnitInfo Class for "Number of Atoms" is pointing to the Credit property.

- Some units are showing up twice in the data.  Look for bigadv unit
(R/C/G) == (17/7/20).  It was written twice.  I'm guessing this is
happening when a unit is written (after first detected completion) but then
the client is reloaded again before the current unit can be uploaded and a
new unit downloaded.

Last Version Tested

- v0.4.6.99

Original issue reported on code.google.com by harlam357 on 9 Dec 2009 at 4:15

[GoogleCodeExporter]

Problem with Credit being written in lieu of Atoms was Fixed in Revision 104 
(public
0.4.7).  Still need to address the duplicate units shown in the data.

Original comment by harlam357 on 4 Jan 2010 at 5:06

• Changed state: Started

[GoogleCodeExporter]

The way I've decided to handle this is to only update the CompletedUnits.csv 
file
once a WU has become history (i.e. a new one has downloaded and begun 
processing). 
This should thwart the problem with duplicates showing up in the data.

Secondly, see the EFT and AllFramesAreCompleted properties in UnitInfoLogic.  
Since
fixing Issue 156 it appears that once most bigadv units finish their last frame 
they
would be assigned a Zero EFT since their ETA values would have been zero and 
they had
not yet written the FinishedTime to the queue.dat file.  In light of this I've 
added
the AllFramesAreCompleted property.  Now, if ETA is Zero and 
AllFramesAreCompleted ==
false, the EFT will be Zero.  Otherwise, if will be given a value of the
(UnitRetrievalTime plus ETA) minus the DownloadTime.

This theory still needs validated...

Original comment by harlam357 on 10 Mar 2010 at 5:21

[GoogleCodeExporter]

Marked Fixed for Revision 154.

Original comment by harlam357 on 10 Mar 2010 at 6:08

• Changed state: Fixed