It can look like a bug: AV - Playback Time on a content shows more minutes consumed than the content's own runtime. The metric is working correctly; this article explains why the calculation can produce a value above the content's duration, and which patterns to look for.
Legitimate causes
AV - Playback Time is the sum of av_playback_duration across all events in a session where playback was active. Several legitimate patterns produce more accumulated time than the content's nominal length:
Replays inside the same session
If a user reaches the end of a video and immediately replays it, the second playback adds to the session's accumulated playback time without resetting it. A 5-minute video watched twice in one session produces 10 minutes of playback time on a single av_session_id.
Seek-backs and rewatches
Every time the user scrubs back and watches a section again, the re-watched seconds are counted again. A user who watches the same chapter three times during an exploration session produces playback time well above the content duration.
Multiple plays before a stop
If the user pauses and resumes repeatedly without the session closing, each play-pause-play cycle continues to accumulate playback time in the same session.
Real-time vs D+1 duration reallocation
In real-time, durations are placed on the next event rather than the one they belong to — because at the moment of an event, Piano doesn't yet know how long that event will last. The daily optimisation routine (runs ~00:00 your site’s timezone) moves each duration to its correct event and merges consecutive heartbeats into single entries.
The practical implication: DataFlow, Data Sharing, and real-time Data Query queries read from the stream table (pre-D+1 reallocation) and will systematically differ from the D+1 interface views, sometimes by hours per session when long pauses or excluded events are involved. For comparable totals across the two sides, query D+1 data, or account for the reallocation mechanism in your downstream processing.
Live streams
For live content, the "content duration" isn't a fixed value, it grows as the live program continues. A viewer who joins early and stays through the full broadcast accumulates playback time that exceeds any snapshot of the live content's duration captured at the start.
Duplicate av.heartbeat events
If your player or SDK integration fires duplicate heartbeats (for example, two heartbeat timers running at once after a misconfigured event listener), each heartbeat adds duration. Inspect the event stream, if you see heartbeats firing twice per interval, you have a tagging bug.
Investigation steps
-
Filter to a single session with an unusually high playback time and inspect its events. If the events show legitimate replays / seek-backs, the metric is correct.
-
Check the timestamp gap between events. Healthy heartbeats are evenly spaced (typically at your configured frequency). Doubled or irregular intervals point to a tagging issue.
-
Compare real-time against next-day historical. If the over-count is only visible in real-time and disappears the next day, it's the heartbeat-merging processing, not a bug.
-
For live content, use
av_content_time_consumed(sum ofav_cursor_difference) rather than playback time when you want to measure unique time consumed, since cursor difference doesn't double-count replays.
Genuine playback-time errors
If, after the above, the playback time is still inflated and the event stream looks healthy, the most likely cause is a player integration sending heartbeats while the player is paused (the heartbeat continues to accumulate av_playback_duration even though the user isn't actually watching). Compare playback time to av_position movement: if position is static while playback time grows, the player is mis-reporting its state.