[BitPim-devel] p_lgvx8550.p -- additional format information for pbentry.dat and pbnumber.dat

[r***@cox.net]

In p_lgvx8550.p, pbfileentry and pnfileentry are showing "entry type" and "entry group" definitions for 12 bytes beginning at offset 5. The actual usage for these 12 bytes are (for the VX5400, anyway):

2 bytes (word, low byte first) year_last_modified
2 bytes (word, low byte first) month_last_modified
2 bytes (word, low byte first) day_last_modified
2 bytes (word, low byte first) hour_last_modified # 00 - 24 hour
2 bytes (word, low byte first) minute_last_modified
2 bytes (word, low byte first) second_last_modified

Except for year_last_modified, all of the other values will always have 0 for the high byte. Date and time values are based on the phone's displayed date and time. Whenever a contact's entry is modified, the entry is changed in pbentry.dat to reflect the modified date/time, and all of the associated record(s) for the contact in pbnumber.dat are changed to reflect the same modified date/time.

Ron

[Nathan Hjelm]

Thanks for that information. Attached is a patch that addresses both
the unk1 and modification date issues. For simplicity the patch sets
the modification date to the current date.



-Nathan

Post by r***@cox.net
In p_lgvx8550.p, pbfileentry and pnfileentry are showing "entry
type" and "entry group" definitions for 12 bytes beginning at offset
2 bytes (word, low byte first) year_last_modified
2 bytes (word, low byte first) month_last_modified
2 bytes (word, low byte first) day_last_modified
2 bytes (word, low byte first) hour_last_modified # 00 - 24 hour
2 bytes (word, low byte first) minute_last_modified
2 bytes (word, low byte first) second_last_modified
Except for year_last_modified, all of the other values will always
have 0 for the high byte. Date and time values are based on the
phone's displayed date and time. Whenever a contact's entry is
modified, the entry is changed in pbentry.dat to reflect the
modified date/time, and all of the associated record(s) for the
contact in pbnumber.dat are changed to reflect the same modified
date/time.
Ron
-------------------------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/bitpim-devel

[r***@cox.net]

Thanks Nathan. In the current p_lgvx8550.p and p_lgvx8550.py src/phones/ files, I'm reading a variable NUM_EMAILS=2 (on lines 25 and 17 respectively). But the variable being used in the code in both source files is NUMEMAILS, which does not appear to be defined in either source file (although I'd guess it could be defined globally or in an import file, if that's allowed in Python). Is this an error? Obviously, NUMEMAILS is working, but I am clueless as to where it has been defined (I'm also clueless about Python for the most part, but that's another matter).

Thanks for any help.

Ron

Post by Nathan Hjelm
Thanks for that information. Attached is a patch that addresses both
the unk1 and modification date issues. For simplicity the patch sets
the modification date to the current date.
-Nathan