Didn't see your post, and went into the source myself... was going to post the exact same question!! I actually slapped my head when I realized the algorithm used the (HIGHLY) variable bitrate as a constant in the calculation!
I hacked the MPEGtransmitter class to allow access to the currentMPEGTime field, but this didn't work either... though I know just about nothing about MPEG streams and have no real idea what this variable holds.
Is there a time embedded in the packet? Is there a good overview of the .ts packet format? And lastly... Friar are you the guy who created the customized VirtualDVHS app?
Regarding the currentMPEGTime variable in the MPE2Transmitter, it doesn't have any relationship to the concept of file relative time-code. It's used by the transmitter's stream-bit-rate follower code to determine when to send ts packets over FireWire (and when not to), as well as for generating the soure-packet-header that's prepended to every ts packet in the FireWire stream.
Regarding a good overview of the ts packet format, it's called IEC 13818-1.
Regarding time-code embedded in the stream, even if there is a time-code in the packets (which there can be at the mpeg video es level), I wouldn't use it, because it has no bearing on the time-code relative to the file position, which is the useful parameter for a program like this.
I think a good solution is to create a secondary file during the recording of a stream, to save frame start locations, such as filename.nav, or filename.pos, to go along with the stream file, filename.m2t.
As ts packets are saved to the .m2t file, feed them to a ts reader/demuxer, that can detect frame starts. Record some information such as frame-start ts packet position in the stream (in bytes (save 64bits per frame), or in ts packets ( save 32bits per frame). Possibly, save picture type (I,P,B), and some other info for each frame that could help in trick modes playback as well.
For playback, try to open both the stream file, and the navigation file (if it exists). If the navigation file doesn't exist, revert to today's sloppy time-code method, But, if the navigation file does exist it then becomes a way to determine exact time-code based on current playback position, as well as it allows for random navigation within the file.
This feature should be enabled/disabled through a button on the preference pane, so that people running on slower systems, (you know who you are), wouldn't incur the extra CPU overhead required to pull this scheme off.
And lastly.. No, I'm not the guy who created the customized