https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5580
--- Comment #12 from Jim Young <jyoung@xxxxxxx> 2011-12-28 13:51:59 PST ---
Created an attachment (id=7617)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7617)
Cooked version of original trace file with frame 1 epoch set to 1001, and delta
captured all set to 1 second to better illustrate original problem
I've attached an "adjusted" version of the original trace file. In this
adjusted trace file each frame has a modified time stamp. Frame 1 now has the
epoch time of 1001.0 and all subsequent frames have a delta captured of 1.0.
This allows one to look at the time stamps and more easily compare the behavior
of having a display filter that suppresses some frames and then setting a time
reference.
Regarding this particular bug it is looks like it is present in both 1.4.10 and
1.6.4. Open up the "adusted" trace file. Apply the display filter "http".
The built-in "delta time displayed" values are directly related to the number
of non-displayed frames. Set Time Reference on any packet and all "delta time
displayed" values will read 1.0 regardless of the number of frames actually
displayed between each frame.
Bug 4985 while similar has a different root cause. If one adds columns for
both the built-in "delta time displayed" and custom
"frame.time_delta_displayed" the issue associated with bug 4985 will be more
readily apparent.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.
