[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Nokia 5130c-2 writecalendar overwrites notes

From: gnokii
Subject: RE: Nokia 5130c-2 writecalendar overwrites notes
Date: Wed, 26 Jan 2011 00:18:11 +0530

> -----Original Message-----
> Date: Tue, 25 Jan 2011 15:33:58 +0100
> From: Pawel Kot <address@hidden>
> Subject: Re: Nokia 5130c-2 writecalendar overwrites notes
> To: "Discussion forum for gnokii users." <address@hidden>
> Message-ID:
>       <address@hidden>
> Content-Type: text/plain; charset=ISO-8859-1
> Hi,
> On Tue, Jan 25, 2011 at 15:21,  <address@hidden> wrote:
> > The actual problem is that the phone repeatedly reports the 
> same "free
> > position" with the result that calendar notes are 
> overwritten.  I would like
> > to explore the theory that this is caused by the phone not 
> having completed
> > writing the last note when it responds to the following 
> enquiry from gnokii
> > for the next "free position".  If you would like to tell me 
> how to modify
> > gnokii source to sleep after writing each note I will be 
> happy to try it.
> Does it mean that writing the two calendar notes in a row stores them
> in the same location? Is it always repeatable?
> take care,
> -- 
> Pawel Kot

Thanks Pawel  :-)

It's repeatable.  I've been testing with ~350 notes.  The first two notes
have always been stored in the same location.  The remaining notes have also
been stored in the same location or the next (and, on one run, the next):

>> the notes were written to only two or three locations, thus 
>> overwriting all but two or three of the notes.  This information
>> came from gnokii output and was confirmed by getcalendarnote.  
>> I cannot see any pattern to when it switched from one location 
>> to the next; for three runs using the same input file:

>> 1. Used two locations; switched at 34% of the way through.
>> 2. Used two locations; switched at 61%.
>> 3. Used three locations; switched at 9% and 82%.

This variability could be explained by it being a hardware-dependent timing



reply via email to

[Prev in Thread] Current Thread [Next in Thread]