Live telemetry `averageBitrateMbps` divides by wall-clock time, so it decays toward zero while paused and never recovers

[classicjazz]

What happened?

LiveTelemetrySampler.tick() (Sources/AetherEngine/Diagnostics/LiveTelemetrySampler.swift, ~line 207) computes the session-average bitrate as:

let elapsed = max(0.5, Date().timeIntervalSince(sessionStartTime))
let lifetimeBytes = max(0, demuxerBytes - sessionStartBytes)
averageBitrateMbps = Double(lifetimeBytes) * 8.0 / elapsed / 1_000_000.0

The denominator is pure wall-clock time since the session started. It never subtracts time the session spent paused.

While playback is paused, demuxerBytes stops advancing (once the forward buffer is full) but elapsed keeps growing. So the reported average falls steadily the longer the session sits paused, trending toward zero. When playback resumes it climbs back only slowly and never returns to the true average, because the paused seconds stay in the divisor permanently.

instantBitrateMbps is unaffected — it's windowed over recent ticks. Only the lifetime average is wrong.

The value is wrong at the source, in LiveTelemetry.averageBitrateMbps, so every consumer inherits the error — including the "divide file size by averageBitrateMbps" download-time estimate suggested in the doc-comment on LiveTelemetry itself. It's visible in Sodalite's Stats for Nerds "Bitrate" row (avg N Mbps), but that's just where it shows up, not where it originates.

Steps to reproduce

1. Start any session that produces LiveTelemetry (native or software path), e.g. a direct-play VOD file.
2. Let it play ~30 s. Note the average bitrate — it sits near the media's real bitrate.
3. Pause for 2–3 minutes.
4. Observe the average has dropped well below the real bitrate, roughly in proportion to playtime ÷ total elapsed.
5. Resume. The average recovers only gradually and asymptotes below the true value — the paused interval is permanently in the denominator.

Expected: the average is taken over time the session was actually playing/transferring, so a pause leaves it flat rather than dragging it down.

AetherEngine version or commit SHA

6.73.0

Host app

Sodalite

Platform

tvOS

OS version

tvos 27

Device / chip

Apple TV 4K

Playback path

Not sure / not a playback bug

Source media (for playback bugs)

No response

Error codes / log lines

Anything else

Why this belongs in AetherEngine and can't just be fixed in Sodalite: averageBitrateMbps is computed in the sampler and shipped as a field of the public LiveTelemetry struct. Sodalite only reads it. A host-side workaround (freeze the last playing value while state == .paused before displaying it) hides the symptom in one row of one screen, but the field stays wrong for every other consumer — the download-time estimate the struct's own documentation points at, any future HUD, any logging. The divisor is the bug and only the engine owns it.

Suggested fix: accumulate an "active" duration — wall-clock minus time spent in .paused / .seeking — and divide by that instead of Date().timeIntervalSince(sessionStartTime). Alternatively, integrate bytes-over-time across the sampler's own tick windows and only advance the accumulator on ticks where the transport is playing.

[superuser404notfound]

Confirmed and fixed on main in bf84aaa (merged as 9931c1a). The diagnosis in the report is exactly right, including that the fix belongs in the sampler rather than in the host: the divisor is the bug, and LiveTelemetry.averageBitrateMbps is where it is computed.

What changed. LiveTelemetrySampler now accumulates an activeSeconds counter one tick at a time and divides by that instead of Date().timeIntervalSince(sessionStartTime). A tick charges its second only when playbackPhase says the session is consuming media. A pause leaves the value standing still, and the seconds it spent paused never enter the divisor, so there is nothing to climb back out of on resume.

One deliberate difference from the suggested fix. The suggestion was to subtract time spent in .paused and .seeking. A seek is kept in the divisor. It is where the session fetches hardest: the forward buffer is discarded and a fresh range is pulled, so dropping those seconds while keeping their bytes would push the average above the media's real rate on every scrub. The same reasoning keeps .rebuffering and .stalled charged, since a stalled reader is a real part of what the session averaged. The line is drawn at "is the session consuming media", not at "is the picture moving", which leaves exactly .paused plus the three phases with no live session behind them (.idle, .ended, .error) outside it.

.ended matters on its own: the sampler keeps ticking until the host tears the session down, so a snapshot left on screen after the last frame used to decay in exactly the same way a pause did.

One behaviour change worth naming. The field is now nil rather than 0.00 until both halves are measurable. The old form published a confident zero on its very first tick, because that tick seeds sessionStartBytes from the same counter it then subtracts, making the lifetime delta zero by construction. That mirrors networkThroughputMbps one field over: a value that cannot be measured yet is a gap, never a zero. Sodalite's Stats for Nerds already renders a nil half of that row as an em dash, so nothing is needed on the host side.

Covered by Issue514AverageBitrateTests, which folds the reported session shape tick by tick (30 s of a 2.8 Mbps file, a three minute pause, then playback again) and pins that the value does not move across the pause, plus a wiring test that a running sampler accrues no active time while the transport is paused.

This is not in a release yet. It will go out in the next AetherEngine version, and Sodalite picks it up with its engine pin, so the Stats for Nerds row will show it after the next TestFlight build. Leaving this open until then.

[superuser404notfound]

Released in 6.75.0 (f436d89).

[classicjazz]

I retested in Sodalite 1.0.0 (41) and have the following feedback:

What I believe the two fields should mean

• Bitrate (this instant): the bitrate of the video being played right now.
• Average: the mean bitrate of the video that has been played since this playback
  session started.

Both are about video played. Neither is about video transferred. A session can transfer
video it is not playing — VOD prefetches ahead of the playhead, live keeps streaming into
the DVR while paused — and in both cases the transfer counter moves while nothing plays.

Today both halves are metered from demuxerBytesFetched, which is the transfer counter
(LiveTelemetrySampler.swift:263). That shows up differently on the two routes (Live v VOD)
because the transfer diverges from playback differently on each.

What each route does

Route	Bitrate	Average
Live TV, playing	correct	correct
Live TV, paused	wrong — keeps reading the incoming stream	wrong — climbs, and keeps climbing the longer the pause runs
VOD, playing	correct	wrong — inflated by the prebuffered video
VOD, paused	correct	wrong — same inflation

Live while playing is correct by accident of the clock: an origin cannot be pulled faster
than it is produced, so transferred == played and the quotient lands on the real rate. That
is the same formula being right for a reason that does not generalize.

Live, paused: it measures video being streamed, not video played

chargesActiveTime freezes the divisor while paused (LiveTelemetrySampler.swift:248). The
fix assumed the numerator freezes with it — Issue514AverageBitrateTests.swift:82 encodes it as
tick(.paused, bytes: 0).

On live that premise is false by design. AE#443's live runaway park exists precisely so a
consumer that stops polling keeps draining the origin
(VideoSegmentProvider.swift:1108-1122: "a live pump that stops reading stops draining the
origin", capped at the DVR window plus slack). So while paused the bytes keep arriving at the
broadcast rate and the divisor stands still: the average can only climb.

Confirmed on device (tvOS, Apple TV 4K gen 3, HDHomeRun ATSC): paused live TV's average
increases steadily, and the longer the pause runs the higher it goes. Nothing was played
during that time, so the average of video played cannot have changed at all.

Note that on live the pre-#514 wall-clock divisor was the right one — there the wall clock
is the media clock. chargesActiveTime is route-blind, so one function has to be right for
both routes.

VOD: the average counts video that has not been played yet

The read-ahead runs to forwardSeconds = segments * 4 plus a disk budget
(SoftwarePlaybackHost.swift:881). Those bytes are in the numerator the moment they are
fetched, minutes before they are played, and the lead never leaves it — so the average
reports the prebuffer for the whole session.

Observed on tvOS: a ~20 Mbps stream reading ~35 Mbps average, with the instant figure
sitting at ~20 and no earlier burst above the average to explain it. The instant half behaves
on this route, paused included. Live TV on the same build reads correctly, which is this same
arithmetic with the prefetch removed.

[superuser404notfound]

Thank you for the retest and for the analysis. It was right on every point, including the part that implicates the first fix: round one froze the divisor during a pause on the assumption that the numerator froze with it, and the test encoded that assumption (tick(.paused, bytes: 0)). On live it is false by design, for exactly the AE#443 reason you cited.

Fixed in 7.22.1 (d06f3eb, PR #666), with your definitions. Both fields are now about video played, not video transferred:

• The loopback and software pumps record every packet of the played video and audio streams by presentation time on the source axis.
• Each 1 Hz sampler tick charges only the packets the playhead crossed since the previous tick, over the media seconds it crossed. Bitrate is that over roughly the last 10 s of playback, Average over the whole session.
• A pause does not move the playhead, so both values stand still, on live too. A seek charges nothing for the span it jumps, and a range fetched again after a seek counts once. Prefetched video counts when it is played, not when it arrives.
• The transfer rate stays in its own field (networkThroughputMbps), and the remote-HLS bypass keeps reporting the variant's declared rates.

Measured with aetherctl over an HTTP origin, the old build against the new one:

Case	before (Average)	after	file
VOD, native, H.264, pause + seek	723, then 103, then 52 Mbps	18.4 to 19.0	18.2
VOD, software, VP9, same	385, then 54, then 26	8.8 to 9.5	8.9
Live TS, native, DVR, paused 50 s	climbs 23 to 64 during the pause	holds 8.12, then 8.0	8.17
Live TS, software, same	climbs 29 to 71	holds 8.07, then 8.0	8.17

The live rows reproduce your HDHomeRun observation: during the pause the instant figure kept reading the incoming stream and the average climbed without bound.

Two things worth knowing when reading the numbers:

• While paused, Bitrate holds the last value that was played rather than going blank.
• Both count the played video plus the selected audio track. Unselected audio tracks, subtitles and container overhead are not in them, so they sit slightly under a file bitrate that includes everything.

Sodalite picks it up with the engine pin that is already bumped, so the next TestFlight build carries it. I'll leave this open until you have had a chance to retest.