bitpim-devel — For bitpim developers

Re: [Bitpim-devel] Timeouts on SCP-5500

[Roger B. <ro...@ro...>]

> I'll do something.  If I can keep the hack limited to com_sanyo5500, I
> may check it in.

Ideally I would like a generic solution that can work for all phones.
So far I don't have a solution that works for ANY phone!

> How do I get the bulk limit?  When I was trying the Sanyo 4900 using
> libusb, things would seem to happen in 64 byte chunks.  It also always
> eventually timed out on me.

It is wMaxPacketSize in an endpoint descriptor.  This is from an AudioVox
8900.

      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               none
        wMaxPacketSize         64
        bInterval               0


>   File "./commport.py", line 267, in readuntil
>     self.ser.flushInput()
> AttributeError: _usbdevicewrapper instance has no attribute 'flushInput'

Mmmm, that code is somewhat dodgy anyway since it flushes the input
buffer, which would throw away any data in it.  However we just
timed out on the read meaning there is no data to flush.  The win32
pySerial code does a fair job of resetting/kicking the input.

I added a flushInput method to the usbdevicewrapper.  It has a call to 
native.usb.USBFile.resetep.  You can see commented out code in that 
that actually clears halts and does and endpoint reset at the USB 
level.  That had no effect on the VX4400 USB issues as there wasn't 
actually a halt, nor did resetep actually have any effect.  You can 
try uncommenting all that to see if it makes a difference.

Roger

Re: [Bitpim-devel] Timeouts on SCP-5500

[Stephen W. <sa...@ge...>]

On Mon, 2004-02-23 at 04:06, Roger Binns wrote:
> > Redoing the command is not a problem for the Sanyo 5500 phonebook or
> > calendar.  There is no state in the reading or writing of these.
> 
> What I recommend you do is the quickest dirtiest hack to see if it
> fixes the problem.  Don't commit it though :-)  If it does fix it
> then we can try to figure out a proper way of doing this.
I'll do something.  If I can keep the hack limited to com_sanyo5500, I
may check it in.
> 
> A good test is to do an entire filesystem backup.  For the 4400 I
> had to add a delay of 0.3 of a second before getting each file.
> If you don't the processor seems to get overwhelmed or something.
> 
The file system backup works fine, even without the 0.3 second delay. 
But the packets in file system mode are a bit over 256 bytes, while the
phonebook protocol packets are over 1000 bytes long.  (And most of that
space is not used).

> > If I capture the data with SnoopyPro, the packet I send to the phone is
> > a single 1034 BULK_OR_INTERRUPT_TRANSFER thingy, but the response comes
> > back in 4 or 5 groups.  The first set of bytes almost always 99 bytes
> > which might be followed by 396, 198 and 341 bytes.  These counts will
> > vary.
> 
> What is the bulk limit?  For the LG phones and the AudioVox CDM 8900
> it is 64 bytes per URB.  Have you tried accessing the phone using libusb
> rather than the acm module?

How do I get the bulk limit?  When I was trying the Sanyo 4900 using
libusb, things would seem to happen in 64 byte chunks.  It also always
eventually timed out on me.

When I try the libusb with the 5500, it will sometime work, but often
get a usbdevicewrapper instance has no attribute 'flushInput' error.

Traceback (most recent call last):
  File "./gui.py", line 150, in run
    res=call()
  File "./gui.py", line 91, in __call__
    return apply(self.method, self.args+args, d)
  File "./gui.py", line 1067, in getdata
    i[1](results)
  File "./com_sanyo5500.py", line 69, in getphonebook
    self.sendpbcommand(req, self.protocolclass.studyresponse,
writemode=True)
  File "./com_sanyo.py", line 186, in sendpbcommand
    data=self.comm.readuntil(self.pbterminator, logsuccess=False,
numfailures=numretry)
  File "./commport.py", line 267, in readuntil
    self.ser.flushInput()
AttributeError: _usbdevicewrapper instance has no attribute 'flushInput'


			Stephen

Re: [Bitpim-devel] More on TM520 phonebook

[Roger B. <ro...@ro...>]

> Hopefully I will get the code done to submit a patch next week - it's much
> easier seeing the code to understand what I meant.

Cool.  Can you send them small discrete pieces as that is easier to understand?

Roger

Re: [Bitpim-devel] Timeouts on SCP-5500

[Roger B. <ro...@ro...>]

> Redoing the command is not a problem for the Sanyo 5500 phonebook or
> calendar.  There is no state in the reading or writing of these.

What I recommend you do is the quickest dirtiest hack to see if it
fixes the problem.  Don't commit it though :-)  If it does fix it
then we can try to figure out a proper way of doing this.

The reason I recommend this approach is because I tried to solve it
"properly" for the VX4400 and the low level code looked real ugly
and was an almost incomprehensible mess.  And of course I discovered
that it didn't fix it anyway (since you could hit exactly the same
problem on the retry or the next command sent).

> The filesystem seems to work reliably.

A good test is to do an entire filesystem backup.  For the 4400 I
had to add a delay of 0.3 of a second before getting each file.
If you don't the processor seems to get overwhelmed or something.

> If I capture the data with SnoopyPro, the packet I send to the phone is
> a single 1034 BULK_OR_INTERRUPT_TRANSFER thingy, but the response comes
> back in 4 or 5 groups.  The first set of bytes almost always 99 bytes
> which might be followed by 396, 198 and 341 bytes.  These counts will
> vary.

What is the bulk limit?  For the LG phones and the AudioVox CDM 8900
it is 64 bytes per URB.  Have you tried accessing the phone using libusb
rather than the acm module?

Roger

Re: [Bitpim-devel] Timeouts on SCP-5500

[Stephen W. <sa...@ge...>]

On Sun, 2004-02-22 at 16:25, Roger Binns wrote:
> ...
> The problem is what to do.  In the case of the VX4400, the communications
> timeout happens while reading the response, and to me seems to be an
> issue with buffer management on the phone.  This means that it has
> already done the action sent in the command, and it would be
> wrong to retry some of the commands (for example the one that goes to
> the next phonebook entry, deleting a file, listing the next directory etc).
Redoing the command is not a problem for the Sanyo 5500 phonebook or
calendar.  There is no state in the reading or writing of these.

The filesystem seems to work reliably.

Of course it might be a problem for media transfers since the ringers
and pictures are not in the file system.

> I am out of ideas on what do about this problem.  You may want to try
> the device on Windows and see if the same problems occur.  If they don't
> then someting will be going on in the device driver to work around it.
> 
My phonebook test code worked fine on Windows, using a Futuredial
driver.  (I think the same driver as used for the 4900 and other sanyo
phones.)

If I capture the data with SnoopyPro, the packet I send to the phone is
a single 1034 BULK_OR_INTERRUPT_TRANSFER thingy, but the response comes
back in 4 or 5 groups.  The first set of bytes almost always 99 bytes
which might be followed by 396, 198 and 341 bytes.  These counts will
vary.

				Stephen
> Roger
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel

Re: [Bitpim-devel] Timeouts on SCP-5500

[Roger B. <ro...@ro...>]

Stephen Wood wrote:
> Is there a clean way to trap communications timeouts so that I can try
> reinitializing communications or such?

The problem is what to do.  In the case of the VX4400, the communications
timeout happens while reading the response, and to me seems to be an
issue with buffer management on the phone.  This means that it has
already done the action sent in the command, and it would be
wrong to retry some of the commands (for example the one that goes to
the next phonebook entry, deleting a file, listing the next directory etc).

The LGE driver on Windows works around the problem by sending a read URB
(USB request block) before sending any write which means the phone already
has a read buffer allocated or something.

I tried doing something similar with libusb using multi-threading and it
didn't work.  I don't think libusb is designed to be multi-threaded (well
maybe version 1.0 will do the trick).

So that kind of thing can only be in a real OS level device driver.

I am out of ideas on what do about this problem.  You may want to try
the device on Windows and see if the same problems occur.  If they don't
then someting will be going on in the device driver to work around it.

Roger

[Bitpim-devel] Timeouts on SCP-5500

[Stephen W. <sa...@us...>]

I am experimenting with the Sanyo SCP-5500, starting with understanding
the phonebook protocol first.  There are strong similarities with the
protocol for the other Sanyo phones.  The headers are larger and the
packets are bigger, but the hex codes in the headers for different
packets are usually the same and the payload formats are similar.  I'll
probably be able to reuse a lot of code.

When reading the phonebook, I will get a timeout at a random place.  The
retry hack used for writing to the other Sanyo phones does not help.  I
worry that this is a similar problem to those experienced with the
VX4400 when using the straight through cable.

Is there a clean way to trap communications timeouts so that I can try
reinitializing communications or such?

				Stephen


9:41:40.729 /dev/input/ttyACM0: Timed out - flushing and trying again
9:41:43.731 /dev/input/ttyACM0: Timed out - flushing and trying again
9:41:46.733 /dev/input/ttyACM0: Timed out waiting for 7e, requested
bytes 1  - 0 bytes read
9:41:46.733 Error: Device needs attention - SCP-5500 on
/dev/input/ttyACM0
SCP-5500 on /dev/input/ttyACM0: The phone is not responding while
manipulating the phonebook.

[Bitpim-devel] More on TM520 phonebook

[Chris P. <dev...@te...>]

Seems like the TM520 phonebook is dead simple compared to the VX4400,
because other than the actual customer ringtone filename, everything is
contained in the phonebook packet. In a TM520, the entry number returned
IS the speed dial, and it is associated to the default number of the
entry (which is also returned as an index (0-4) in the packet).
How the numbers are returned in an entry is also fixed - it's always
Home, Office, Cell, Pager, and Data/Fax, so nothing like the VX4400
where you can have a different priority for each entry.

As for why pim/midiringer.dat wasn't read as part of the fundamentals, it's
because that file strictly tells which custom ringtone file is associated
with which phonebook entry and nothing more - that's why I read and parse it
right before getting the phonebook.

I haven't tried syncing the phone without issuing a start sync - and in fact
after a start sync, the existing code send a pbinitrequest, and then a
pbinforequest (and use a pbnextentryresponse) before looping for data. You're
right in that once a start sync is used, the phone will always reboot after
and hence I have moved all other operations (ringtone and calendar) to come
before getting the phonebook.

Hopefully I will get the code done to submit a patch next week - it's much
easier seeing the code to understand what I meant.

Re: [Bitpim-devel] Re: TM520 Phonebook read routine

[Roger B. <ro...@ro...>]

>             buf=prototypes.buffer(self.getfilecontents("pim/midiringer.dat"))

That should be done in the getfundamentals code.

> PS - with the TM520, phonebook sync must be the last operation if you
> selected multiple things with Get Phone Data. Is that the case with
> the VX4400? The reason being that TM520 will always reboot after getting
> the phonebook so you have to do everything else before that (ringtones
> and calendar)

When writing the phonebook is done last.  That is because you may be
updating ringtones/wallpapers and the ids need to be known first.

I could change the reading to be in "reverse" order as well.  The
4400/6000 do not need the start/end sync commands.  However if you
do supply the start sync, the screen goes into a synchronisation 
mode, and you have to reboot afterwards either through an explicit
end sync command, or by there being one minute of no activity.

Roger

Re: [Bitpim-devel] brew only? or more?

[Roger B. <ro...@ro...>]

Justin Mitchell wrote:
> Does Bitpim only support Brew devices, or do it's capabilites extend
> beyond that? 

It supports whatever phones people have written modules for.  There
is no inherent hard coding of any type of phone.  It just so happens
that all the people who have added phone support have been in the
US which primarily has phones based on Qualcomm CDMA, and hence use
the "brew" protocol for accessing the embedded filesystem.

> I noticed that the scripts for each of the currently
> supported phones references com_brew, although I didn't realize the
> Sanyos supported Brew.... 

"Brew" is probably a bad choice for a name.  Brew specifically refers
to the programming environment in the phone, and all Qualcomm chipsets
support the same filesystem protocol in order to upload the programs.
Even when the phone doesn't support Brew, the filesystem protocol is
typically present.  I can't really think of a better name.

> Anyways, just curious... thinking about adding
> support for some Samsung phones.

Go for it.  There is some documentation in web/phonespec.html.  It
certainly needs more parts filling out, and I welcome patches to
the doc :-)

Roger

Re: [Bitpim-devel] Sanyo 8100

[John D. <joh...@ma...>]

I wanted to personally thank you for the that everybody is doing. 
Bitpim works great for my 8100 (except the ringtones and pictures) and I 
really appreciate it.

Thanks - again, let me know if there is anything I can do.

John


Stephen Wood wrote:
> I just got ahold of an 8100, so we don't really need help with the 8100
> at the moment.  Perhaps there are other areas of BitPim that could use
> help??
> 
> 			Steve
> 
> On Fri, 2004-02-20 at 15:16, John DiMartino wrote:
> 
>>Hi,
>>
>>I asked before what I could do to help development of the Sanyo 8100 - 
>>but I really can't program at all.  I got a response but I had no clue 
>>where to start.  Could somebody give me specific tasks that I could do 
>>to help out?
>>
>>Thanks,
>>John DiMartino
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel

Re: [Bitpim-devel] LG phonebook sync question - keeping original entry number

[Roger B. <ro...@ro...>]

Chris Poon wrote:
> After more digging around in the code, I figure the best way to use
> the speeddial key to store the entry number

No, that is a bad idea.  The speed dial field is used for storing the speed
dial. Remember that BitPim can work with multiple phones concurrently.

> I totally forgot
> that in the TM520 you have to choose a default phone number for each entry,

The phonebook format in BitPim is designed to work with that.  See the top
of phonebook.py.  In particular numbers are ordered, and hence the first
one is the default.  The 4400/6000 store 5 numbers in priority order,
with another 5 bytes storing each number type.

> default phone number field. Now I just need to understand fully what the
> savephonebook function does (I partially understood it and made it modular
> to support phone differences) before I go test it out

Run the analyser on examples\vx4400phonebookupdate.txt to see how the
code works.

Roger

Re: [Bitpim-devel] LG phonebook sync question - keeping original entry number

[Roger B. <ro...@ro...>]

> I'm not sure I understand this, so let me re-state.
> When you go a getphonebook, as part of the response, you get the entry number
> (entrynumber), which I don't see the code stores in anywhere. 

Correct.

> When you need to
> rewrite a modified entry, I take it that the phone will ignore whatever entry
> number you put in the request and use the serial number as the key? 

No.  Look at the savephonebook code.  That code re-reads the phonebook,
and matches up the serials of the data about to be written with what is
already on the phone.

The VX4400/4500/6000 require that you write out stuff in entry order,
but there can be holes due to entries being deleted, and then new entries
are appended.

It would be pointless storing the entry number in BitPim since the 
phonebook on the phone could change between BitPim reading it and
BitPim writing to it.

> For a
> brand new entry, the serial should be automatically created, but the entry
> number was filled in by an incremental counter - can anyone explain how BREW
> handles it when you send a pbappendentryrequest? 

This has nothing to do with Brew.  The LG phones store their phonebook in
files particular to them and have their own sync protocol.

The phone has a file containing the next counter number.  When you add an
entry, that number gets allocated.

> I know eventually I will
> destroy my spare phone testing this, just wanted to know what to expect

Just make sure you do a complete filesystem backup first and you should be
ok.  About the worst damage is if the phone gets into an infinite reboot
loop, in which case Verizon will replace the phone.

> Also, is the speed dial being kept at all? I don't see the code for VX4400
> doing that currently and I assume you lose your speed dial or is that not
> the case?

The speeddial is not read as it isn't included in the phonebook sync protocol
as far as I can tell.  It is on a file in the phone, but I haven't quite
figured out how it is stored.  The speed dials (and voice dials) are tied to 
particular serials, so providing the serials of entries are preserved the
speed/voice dials are preserved.

> PS: next up, the LG4600 (VX4600 down in the states), once I justify paying
> over $70USD for a data cable which it cost only $30USD (all the taxes, duties,
> and shipping handling created a 100%+ overhead). I believe the LG4600 has
> very similar phonebook structure, and I know the ringtone/wallpaper handling
> already (at least I think I know).

What a few weeks till bitfling is ready (I'll give more details when it is
closer to completion).  It will make development considerably quicker and
easier for phones not in front of you.

Roger

Re: [Bitpim-devel] Sanyo 8100

[Stephen W. <sa...@ge...>]

I just got ahold of an 8100, so we don't really need help with the 8100
at the moment.  Perhaps there are other areas of BitPim that could use
help??

			Steve

On Fri, 2004-02-20 at 15:16, John DiMartino wrote:
> Hi,
> 
> I asked before what I could do to help development of the Sanyo 8100 - 
> but I really can't program at all.  I got a response but I had no clue 
> where to start.  Could somebody give me specific tasks that I could do 
> to help out?
> 
> Thanks,
> John DiMartino

[Bitpim-devel] brew only? or more?

[Justin M. <li...@ju...>]

Does Bitpim only support Brew devices, or do it's capabilites extend 
beyond that? I noticed that the scripts for each of the currently 
supported phones references com_brew, although I didn't realize the 
Sanyos supported Brew.... Anyways, just curious... thinking about adding 
support for some Samsung phones.

Justin

[Bitpim-devel] Sanyo 8100

[John D. <joh...@ma...>]

Hi,

I asked before what I could do to help development of the Sanyo 8100 - 
but I really can't program at all.  I got a response but I had no clue 
where to start.  Could somebody give me specific tasks that I could do 
to help out?

Thanks,
John DiMartino

Re: [Bitpim-devel] LG phonebook sync question - keeping original entry number

[A F <eat...@ho...>]

Hi Chris,

I'm already looking at the 4600, and already have a cable.  Perhaps it would
be better if we were to work together rather than have you purchase another
cable and work independently?

I'll email you everything I've mapped out already over the weekend.

Anthony

----- Original Message ----- 
From: "Chris Poon" <dev...@te...>
To: <bit...@li...>
Sent: Friday, February 20, 2004 9:59 AM
Subject: Re: [Bitpim-devel] LG phonebook sync question - keeping original
entry number


> You wrote:
> >
> > You can store the entry number as part of the serials.  The way the
other LG
> > phones work is that each entry has two serial numbers which are equal
and never
> > change for that entry.  Every time you create a new entry, a new serial
is
> allocated
> > (the new serial being an ever increasing number).
> >
> > When writing out to the phone, the existing entries and their serials
are
> > read, and the entries being written out are matched to those.  The
> > software inside the phone maintains the speed dial pointers correctly.
> >
> > Roger
>
> I'm not sure I understand this, so let me re-state.
> When you go a getphonebook, as part of the response, you get the entry
number
> (entrynumber), which I don't see the code stores in anywhere. When you
need to
> rewrite a modified entry, I take it that the phone will ignore whatever
entry
> number you put in the request and use the serial number as the key? For a
> brand new entry, the serial should be automatically created, but the entry
> number was filled in by an incremental counter - can anyone explain how
BREW
> handles it when you send a pbappendentryrequest? I know eventually I will
> destroy my spare phone testing this, just wanted to know what to expect
>
> Also, is the speed dial being kept at all? I don't see the code for VX4400
> doing that currently and I assume you lose your speed dial or is that not
> the case?
>
> PS: next up, the LG4600 (VX4600 down in the states), once I justify paying
> over $70USD for a data cable which it cost only $30USD (all the taxes,
duties,
> and shipping handling created a 100%+ overhead). I believe the LG4600 has
> very similar phonebook structure, and I know the ringtone/wallpaper
handling
> already (at least I think I know).
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Bitpim-devel mailing list
> Bit...@li...
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel
>

[Bitpim-devel] Speed dial

[Stephen W. <sa...@us...>]

Chris:

	I am not sure if it is a useful example for your phone, but the code
for the Sanyo phones saves and restores speed dial settings.

				Steve

Re: [Bitpim-devel] LG phonebook sync question - keeping original entry number

[Chris P. <dev...@te...>]

After more digging around in the code, I figure the best way to use
the speeddial key to store the entry number (and as part of discovery,
I have all fields identified for a phonebook entry). I totally forgot
that in the TM520 you have to choose a default phone number for each entry,
which is how the speed dial is assigned - and thus, the phonebook has a field
saying which is the default phone number. All I need to do is assign the
speed dial field with entrynumber for that particular number during
getphonebook, and reset the entrynumber to be the speed dial as well as the
default phone number field. Now I just need to understand fully what the
savephonebook function does (I partially understood it and made it modular
to support phone differences) before I go test it out

Re: [Bitpim-devel] LG phonebook sync question - keeping original entry number

[Chris P. <dev...@te...>]

You wrote:
> 
> You can store the entry number as part of the serials.  The way the other LG
> phones work is that each entry has two serial numbers which are equal and never
> change for that entry.  Every time you create a new entry, a new serial is
allocated
> (the new serial being an ever increasing number).
> 
> When writing out to the phone, the existing entries and their serials are
> read, and the entries being written out are matched to those.  The
> software inside the phone maintains the speed dial pointers correctly.
> 
> Roger

I'm not sure I understand this, so let me re-state.
When you go a getphonebook, as part of the response, you get the entry number
(entrynumber), which I don't see the code stores in anywhere. When you need to
rewrite a modified entry, I take it that the phone will ignore whatever entry
number you put in the request and use the serial number as the key? For a
brand new entry, the serial should be automatically created, but the entry
number was filled in by an incremental counter - can anyone explain how BREW
handles it when you send a pbappendentryrequest? I know eventually I will
destroy my spare phone testing this, just wanted to know what to expect

Also, is the speed dial being kept at all? I don't see the code for VX4400
doing that currently and I assume you lose your speed dial or is that not
the case?

PS: next up, the LG4600 (VX4600 down in the states), once I justify paying
over $70USD for a data cable which it cost only $30USD (all the taxes, duties,
and shipping handling created a 100%+ overhead). I believe the LG4600 has
very similar phonebook structure, and I know the ringtone/wallpaper handling
already (at least I think I know).

[Bitpim-devel] Re: TM520 Phonebook read routine

[Chris P. <dev...@te...>]

I did hoist the getphonebook method out of the VX4400, and given how
the initialization is different, I have changed it a bit so that the
TM520-specific code is moved out of the getphonebook function. It seems
that the TM520 will always reboot the phone after PhoneBook sync so
you don't really need to explicitly switch to BREW mode (and doing so
actually break things with the TM520). I have included the snippet of
the code relating to getphonebook here for now as I'm not quite done
with the rest of the changes.

    def pbinit(self):
        req=self.protocolclass.pbstartsyncrequest()
        self.sendpbcommand(req, self.protocolclass.pbstartsyncresponse)
        
        req=self.protocolclass.pbinitrequest()
        res=self.sendpbcommand(req, self.protocolclass.pbinitresponse)

	count = res.numentries

        req=self.protocolclass.pbinforequest()
        res=self.sendpbcommand(req, self.protocolclass.pbnextentryresponse) ##
NOT inforesponse
	
	return count

    def pregetpb(self,result):
        index={}
        try:
            buf=prototypes.buffer(self.getfilecontents("pim/midiringer.dat"))
        except com_brew.BrewNoSuchFileException:
            # file may not exist
            return index
        g=self.protocolclass.ringindex()
        g.readfrombuffer(buf)
        for i in g.items:
            if i.name != "default":
                index[i.index+1]=i.name[len('ringer/'):]
        return index

    def getphonebook(self,result):
        """Reads the phonebook data.  The L{getfundamentals} information will
        already be in result."""
        pbook={}
        # Bug in the phone.  if you repeatedly read the phone book it starts
        # returning a random number as the number of entries.  We get around
        # this by switching into brew mode which clears that.
        #self.mode=self.MODENONE
        #self.setmode(self.MODEBREW)

	result['intermediate'] = self.pregetpb(result)
        self.log("Reading number of phonebook entries")

        numentries=self.pbinit()
        self.log("There are %d entries" % (numentries,))
        for i in range(0, numentries):
            ### Read current entry
            req=self.protocolclass.pbreadentryrequest()
            res=self.sendpbcommand(req, self.protocolclass.pbreadentryresponse)
            self.log("Read entry "+`i`+" - "+res.entry.name)
            entry=self.extractphonebookentry(res.entry, result)
            pbook[i]=entry 
            self.progress(i, numentries, res.entry.name)
            #### Advance to next entry
            req=self.protocolclass.pbnextentryrequest()
            self.sendpbcommand(req, self.protocolclass.pbnextentryresponse)

        self.progress(numentries, numentries, "Phone book read completed")
        result['phonebook']=pbook
        cats=[]
        for i in result['groups']:
            if result['groups'][i]['name']!='No Group':
                cats.append(result['groups'][i]['name'])
        result['categories']=cats
	del result['intermediate']
        print "returning keys",result.keys()
        return pbook

PS - with the TM520, phonebook sync must be the last operation if you
selected multiple things with Get Phone Data. Is that the case with
the VX4400? The reason being that TM520 will always reboot after getting
the phonebook so you have to do everything else before that (ringtones
and calendar)

[Bitpim-devel] vx4500 ringtones.... mp3 and midi

[greg c. <gre...@ya...>]

Is pitpim converting mp3 files to midi or does the
vx4500 support mp3 ringtones.  I take a normal mp3
file and change the extention to midi... use bitpim
and transfer the file to my vx4500 and it works just
fine as a ringtone.  My guess is that the phone is
supporting mp3 because I downloaded a police siren to
it and it works just fine....Ive been told that there
is no way that you can get a siren into midi format.  
I think that the phone just requires a mid extention
to the file. I have attached the siren.mid file...
this copy of the file was downloaded back off of my
phone so I know it works.

thanks
greg

__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: [Bitpim-devel] LG phonebook sync question - keeping original entry number

[Roger B. <ro...@ro...>]

Chris Poon wrote:
> Am I correct in saying that currently BitPIM doesn't keep the original entry
> number and will just re-create it when the phonebook is pushed to the phone?
> From reading the code it doesn't seem like BitPIM keep track it - although
> it's probably insignificant in the VX4400 given how the phonebook changed,
> I think we need to keep track of the entry number for the TM520 because that
> also determines the speed dial entry.

You can store the entry number as part of the serials.  The way the other LG
phones work is that each entry has two serial numbers which are equal and never 
change for that entry.  Every time you create a new entry, a new serial is allocated
(the new serial being an ever increasing number).

When writing out to the phone, the existing entries and their serials are
read, and the entries being written out are matched to those.  The
software inside the phone maintains the speed dial pointers correctly.

Roger

[Bitpim-devel] LG phonebook sync question - keeping original entry number

[Chris P. <dev...@te...>]

Am I correct in saying that currently BitPIM doesn't keep the original entry
number and will just re-create it when the phonebook is pushed to the phone?
From reading the code it doesn't seem like BitPIM keep track it - although
it's probably insignificant in the VX4400 given how the phonebook changed,
I think we need to keep track of the entry number for the TM520 because that
also determines the speed dial entry.

Yeah, the TM520 is pretty primitive and I'm now retrofitting the code to
support an old phone :(

[Bitpim-devel] Findings on ringtone support for TM520

[Chris P. <dev...@te...>]

So it looks like it's just a hack in the firmware to get downloadable ringtone
on the TM520
- no index file keeping track of ringtones
- only the first 5 ringtones in the filesystem can be used (suspect it to be
sorted alphabetically to count)
- index file for referencing the actual ringtone path for all phonebook entries
(pim/midiringer.dat)
- index file for the default ringtone path (pim/ringtitle.dat)

This is a totally different model than the VX4400, granted the TM520 is an
older phone and originally didn't have downloadable ringtone support.
Hopefully the VX1/VX10 isn't too far from it, but we would definitely need
some VX1/VX10 users browse around the filesystem to see if there is any
difference, and test out the code that I'm going to write. Unfortunately
none of the phones I had in my hands had the right firmware, although my
co-worker here does. Trying to make the ringtone support close to the VX4400
is going to be a difficult task, but I will try to merge as much of it as
I can so we will have more common code. Granted there is no index, and only
a limit of 5 ringtones allowed, I don't think it's worthwhile to support the
ringtone merge - it will strictly be overwritten.

I need to find more time for writing this...