Closed Bug 1685503 Opened 3 years ago Closed 3 years ago

Use AwakeTimeStamp to count time for media telemetry

Categories

(Core :: Audio/Video, task)

task

Tracking

()

RESOLVED FIXED
90 Branch
Tracking Status
firefox90 --- fixed

People

(Reporter: padenot, Assigned: padenot)

References

Details

Attachments

(2 files, 1 obsolete file)

No description provided.

This prevents having dramatic over-reporting on Windows.

Depends on D101036

Attachment #9196038 - Attachment description: Bug 1685503 - Switch HTMLMediaElement telemetry to use AwakeTimeStamp. → Bug 1685503 - Switch HTMLMediaElement telemetry to use AwakeTimeStamp. r?mattwoodrow
Severity: -- → N/A
Type: defect → task
Blocks: 1685399

That is not actual a blocker, but we have to be aware of which bug would be landed first, then another bug would need to do some rebasing. So change it to see-also.

No longer blocks: 1685399
See Also: → 1685399
Attachment #9196038 - Attachment is obsolete: true
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/36427e64399a
Use AwakeTimeStamp to count time for media telemetry. r=alwu
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/bc141a334421
Use AwakeTimeStamp to count time for media telemetry. r=alwu
Backout by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e339980fb66f
Backed out changeset bc141a334421 for windows browser chrome failures on browser_tab_visibility_and_play_time.js CLOSED TREE

Alastor, I still have a failure (even with the path that adds sleeps) that I don't understand: https://treeherder.mozilla.org/jobs?repo=try&revision=16474cd2909a408eb4796ba814d59e6947c6441c, do you?

Flags: needinfo?(padenot) → needinfo?(alwu)

I will check that later today, keep my NI.

I tried your patch locally and ran it many times (50+), the result all seemed pretty good. If we still get the intermittent failure on try, that means the low resolution clock didn't continue counting within a second, is that something we need to worry about?

Or we could try to use waitForCondition(/* callback : return true when the clock starts forward*/) to replace the sleep() in assertValueConstantlyIncreases to see if the result would become more reliable.

Flags: needinfo?(alwu)

(In reply to Alastor Wu [:alwu] from comment #12)

Or we could try to use waitForCondition(/* callback : return true when the clock starts forward*/) to replace the sleep() in assertValueConstantlyIncreases to see if the result would become more reliable.

That was it, thanks for the hint, I switched this to use "timeupdate" (when playing, kept setTimeout for the "paused" case), and it's solidly green. It's just a matter of playback taking some time to start, which, in retrospect, is obvious:

https://treeherder.mozilla.org/jobs?repo=try&revision=24d983cc8699defb0827e94dbc60eed75157bb64&selectedTaskRun=EwK3VEQYTiSkkU0QEoWbWw.0

Attachment #9219794 - Attachment description: Bug 1685503 - Wait one second when testing the telemetry probes for visible and invisible media elements, to not depend on high-resolution clock. r?alwu → Bug 1685503 - Wait for "timeupdate", or one second (when paused) when testing the telemetry probes for visible and invisible media elements, to not depend on high-resolution clock. r?alwu
Pushed by padenot@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/037395dc7d1d
Use AwakeTimeStamp to count time for media telemetry. r=alwu
https://hg.mozilla.org/integration/autoland/rev/cb5292b9c50d
Wait for "timeupdate", or one second (when paused) when testing the telemetry probes for visible and invisible media elements, to not depend on high-resolution clock. r=alwu
Regressions: 1709597
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 90 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: