didn't save my sleep history

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Record sleep
2. Press save
3. Try to see history

What is the expected output? What do you see instead?
Says no history

What version of the product are you using? On what operating system?
Bets

Please provide any additional information below.
Droid x

Original issue reported on code.google.com by bigw...@gmail.com on 12 Dec 2010 at 2:40

• Merged into: #31

[GoogleCodeExporter]

Original comment by jondwil...@gmail.com on 12 Dec 2010 at 6:23

• Changed state: Duplicate

[GoogleCodeExporter]

Original comment by jondwil...@gmail.com on 12 Dec 2010 at 6:23

[GoogleCodeExporter]

Hi, do you know if there was an error message displayed when you finished 
saving?

Original comment by jondwil...@gmail.com on 12 Dec 2010 at 6:24

[GoogleCodeExporter]

I don't remember any message, but I'll try recording during work and just put 
it in my pocket or something and let you know.

Original comment by bigw...@gmail.com on 13 Dec 2010 at 6:24

[GoogleCodeExporter]

Ok, just make sure it records for about an hour or more.

Original comment by jondwil...@gmail.com on 13 Dec 2010 at 7:09

[GoogleCodeExporter]

Ok, it worked that time.  I recorded about 3-4 hours of movement by just 
putting it in my pocket.  Worked very well.  I entered a note and rated it with 
stars.  Not sure why it didn't work the first time when I actually slept.  I'll 
try again without entering a note or something else.  If it works during the 
day, perhaps it has something to do with the time rolling over at midnight?  
Just a thought.

Original comment by bigw...@gmail.com on 13 Dec 2010 at 11:34

[GoogleCodeExporter]

Ok did an overnight one and when saving it said" could not save. Likely too 
(something)" disappeared too fast. Save failed. Could it have something to do 
with the clock rolling over at midnight or something?

Original comment by bigw...@gmail.com on 14 Dec 2010 at 1:45

[GoogleCodeExporter]

Probably not a problem due to the clock rolling over. The update next update 
I'm going to put out will allow these allegedly short sleeps again, so that 
should help alleviate the problem while I figure out what is happening.

Original comment by jondwil...@gmail.com on 14 Dec 2010 at 6:10

[GoogleCodeExporter]

Yea, my sleep wasn't short (about 8 hours).  Do you do something like "endtime 
- starttime = duration" anywhere and use hours and seconds?  If so, convert 
over to using unixtime (seconds since the epoch) or something else.  The 
hours/minutes thing will bite you every time.

If you want to send me a beta version, I'll be happy to run it through its 
paces.  I'm going to do a daytime recording session that records over the 
12-noon timestamp today.

Original comment by bigw...@gmail.com on 14 Dec 2010 at 7:34

[GoogleCodeExporter]

shdb.addSleep(context, new SleepRecord(name,lessDetailedX, lessDetailedY, min, 
alarm, rating, endTime - startTime, numberOfSpikes, timeOfFirstSleep, note));

That's exactly what I do, except they ARE in milliseconds since epoch. What I 
think is happening is either the app is crashing or getting killed somehow. It 
could then lose its collection of data. Otherwise, something about the DroidX 
could be causing inconsistent number of data points to be collected. On the 
Droid 1, when I use a certain rate of collection, the sensor only sends me data 
when there is actually movement.

Original comment by jondwil...@gmail.com on 15 Dec 2010 at 3:09

[GoogleCodeExporter]

I don't think the app is crashing because right b4 I hit the stop button thee 
is a full set of data displayed.  Then the rating screen is displayed.  Enter a 
star rating and save...  Error.  No indication that the app has crashed. 

 I did have one successful save with 0.5.0.  It was interesting in that the saved graph was very different than the graph before saving.  The displayed graph was very rectangular in that there was high activity at the start and finish, and low activity in between.  The final saved graph showed a ramp going down to near zero at the mid point and the back up to the high point on the right,as if all the points in between were ignored.  Perhaps there is a timing error and the data is being decimated before it is being evaluated for saving?

Original comment by pegbat...@gmail.com on 15 Dec 2010 at 4:55

[GoogleCodeExporter]

in the previous example, the app was recording data for  12 hours and 24 
minutes.

Original comment by pegbat...@gmail.com on 15 Dec 2010 at 4:59

[GoogleCodeExporter]

Recorded another one for 10 hours overnight. Noticed that I had an alarm (not 
in the app but the standard alarm from the os waking me up) could that be 
resetting the clock or something?  Do I need to use the internal alarms to the 
app instead?

Original comment by bigw...@gmail.com on 15 Dec 2010 at 1:44

[GoogleCodeExporter]

Ok, well I'm going to change my design on this one ASAP, because I'm really 
unsure why this is happening. Instead of keeping movement recorded in volatile 
RAM, I'm going to save it to disk, and then read that out when saving. This 
should be a more stable way of doing things. Before that, I'm going to finish 
up 0.5.1 (there's still a bug in it)
 and try to release it today.

Original comment by jondwil...@gmail.com on 15 Dec 2010 at 6:10