r***@cox.net
2007-12-10 11:55:29 UTC
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
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