Re: VX5400/VX8550 picture-id/ringer-id index issue

The attached patch should fix both earlier issues and the ringtone/ 
picture id issues. Thanks again for helping find these bugs.




-Nathan

On Dec 10, 2007, at 4:55 AM, [email protected] wrote:

> This link describes a problem with contacts' picture-ids  
> mysteriously changing on the VX8550:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=473698C5.8040105%40gmail.com&forum_name=bitpim-user
>
> I have been able to duplicate this problem, along with ringer-ids  
> which mysteriously change, and I understand why it happens.  I'm not  
> familiar enough with the underlying code to offer a programming  
> solution, but I can explain what is happening and offer a suggestion  
> on how to possibly fix it.
>
> In short, in the VX5400's (and probably the VX8550's) pim/ 
> pbentry.dat file, the phone does not store relational indexes which  
> pair media files (as listed in dload/image.dat and dload/ 
> myringtone.dat) with contacts.
>
> Bitpim appears be storing such indexes in the pbfileentry.ringtone  
> and pbfileentry.wallpaper fields, but that will not work -- the  
> phone itself does not recognize such indexes nor does it attempt to  
> preserve or reconcile any indexes.  When changes are made which  
> affect dload/myringtone.dat or dload/image.dat (such as adding or  
> deleting media files), the indexing scheme used by Bitpim fails, and  
> ringer-ids and picture-ids end up being changed for contacts when  
> the phonebook is downloaded (and subsequently uploaded).
>
> If a user manually sets a ringer-id (or picture-id) for a contact on  
> the phone, the phone sets the pbfileentry.ringtone (or  
> pbfileentry.wallpaper) field to $0064 -- a flag, not an index.  When  
> the phonebook is downloaded, Bitpim interprets this "index" as the  
> first ringer (or image) in dload/myringtone.dat (or dload/ 
> image.dat), and mistakenly assigns an incorrect ringer-id (or  
> picture-id).
>
> For the the VX5400, the pbfileentry.ringtone field should only  
> contain one of the following:
> 1. $FFFF for the default ringtone.
> 2. $0000 - $0012 for any of the 19 built-in ringtones (including no  
> ring).
> 3. $0064 as a flag to lookup the contact's corresponding ringer-id  
> path in pim/pbRingIDSetAsPath.dat.  Whenever the contact information  
> is viewed on the phone, if the path is determined to be invalid, the  
> phone sets the flag back to $FFFF and the associated record in pim/ 
> pbRingIDSetAsPath.dat is set to all zeros.
>
> The pbfileentry.wallpaper field should only contain one of the  
> following:
> 1. $0000 for a default setting of no wallpaper (but if a valid image  
> path exists in pim/pbPictureIDSetAsPath.dat for the contact, it will  
> be used anyway, making the $0000 insignificant).
> 2. $0064 as a flag to lookup the contact's corresponding picture-id  
> path in pim/pbPictureIDSetAsPath.dat.  Whenever the contact's  
> information is viewed on the phone, if the path is determined to be  
> invalid, the phone sets the flag back to $0000 and the associated  
> record in pim/pbPictureIDSetAsPath.dat is set to all zeros.
>
> I believe Bitpim currently uses these fields as indexes (based at  
> $0064, and incremented by 1) for the records in dload/myringtone.dat  
> and dload/image.dat.  But the phone does not recognize any such  
> indexing scheme, and if ringtones or images are added or deleted  
> (which shifts the relative index position in dload/myringtone.dat or  
> dload/image.dat), there is no corresponding code in the phone to  
> "adjust" (or reconcile) the indexes for each contact.  Subsequently,  
> if the erroneous "index" that Bitpim uses in these fields is  
> retrieved with the phonebook by Bitpim, Bitpim will determine the  
> the contact entry's ringer--id or picture-id to be something other  
> than what it actually is.
>
> For a possible solution, when retrieving the phonebook, I believe  
> the actual ringer-id (or picture-id) path can be found by accessing  
> the record obtained from the file image of pim/pbRingIDSetAsPath.dat  
> (or pim/pbPictureIDSetAsPath.dat) having an offset at  
> pbfileentry.entry_number0 * 255.  If the path does not exist in the  
> records obtained from the file image of dload/myringtone.dat (or  
> dload/image.dat), then pbfileentry.ringtone should be set to $FFFF  
> (or pbfileentry.wallpaper should be set back to $0000), and the  
> corresponding record in the file image of pim/pbRingIDSetAsPath.dat  
> (or pim/pbPictureIDSetAsPath.dat) set to all zeros, and the ringtone  
> (or wallpaper) tab for the contact should appear blank.
>
> If a user adds a non-built-in ringer (or a wallpaper),  
> pbfileentry.ringtone (or pbfileentry.wallpaper) should be set to  
> $0064 as a flag (that is what the phone does -- there are no  
> indexes), and the corresponding record in the file image of pim/ 
> pbRingIDSetAsPath.dat (or pim/pbPictureIDSetAsPath.dat) should be  
> updated with the selected path.  The phone will take care of any  
> unreconcilable issues, such as the user deleting a media file from  
> the phone before uploading the phonebook (if that happens, when the  
> contact info is viewed on the phone, the phone will see that the  
> media file path is invalid, it will set the flag field accordingly,  
> and it will zero out the path in the appropriate file).
>
> If a user deletes the ringer (or wallpaper) tab for a contact,  
> pbfileentry.ringtone should be set to $FFFF (or  
> pbfileentry.wallpaper should be set to $0000), and the corresponding  
> record in the file image of pim/pbRingIDSetAsPath.dat (or pim/ 
> pbPictureIDSetAsPath.dat) set to all zeros.
>
> I'll be glad to help resolve this issue (if possible).  If I haven't  
> adequately explained anything, just let me know.
>
> Ron
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by:
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> BitPim-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bitpim-devel

-------------------------------------------------------------------------
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

_______________________________________________
BitPim-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bitpim-devel