macOS: AVPlayerItem.currentTime() from the main actor did not return for 13.3 s during a consumer wedge, and the engine reads it there in two places

[superuser404notfound]

Split out of #408. Observed by @rrgomes on macOS 26.6.2 during the retest, one sample, and worth recording because the engine reads the same property from the same place.

What was seen

While AVPlayer was parked in the consumer wedge of #421, an AVPlayerItem.currentTime() call made from the host's main actor did not return for 13.3 s, and the app was fully blocked for that time. It came back 30 ms after the re-engage watchdog fired. The same wedge on an Apple TV the same afternoon returned instantly. The reporting host no longer reads the player from the main actor during a stall.

Why this is ours as well

Two engine reads sit on the main actor and would join the same wait:

• AetherEngine+Loading.swift:1206, the stage-1 nudge: self.reengageStalledConsumer(position: player.currentTime().seconds, ...). This one is the sharper case, because it runs precisely when the consumer is wedged, which is the state in which the call was measured not returning.
• NativeAVPlayerHost.bufferedEnd, which reads item.currentTime() before walking loadedTimeRanges.

AetherEngine+Diagnostics.swift:59 already treats these as sync XPC reads and hops them off the main actor for the memory probe ("#134: currentTime()/loadedTimeRanges are sync XPC reads"), so the hazard is known in one place and unguarded in the others.

Related: #254 has the same shape on the software path (SoftwarePlaybackHost.seek runs the deadline-free Demuxer.seek on the main actor, field App Hangs).

What would settle it

One sample on one platform is not a measurement. The engine has renderedPositionMirror for exactly this reason (the producer reads AVPlayer's position off-main through it), so the fix is likely to be small; the part that needs evidence first is whether the block is reproducible on macOS under a wedge, and whether tvOS is genuinely exempt or merely was not caught. aetherctl can hold a wedge open on the loopback path, which is where to try it.

[superuser404notfound]

One sample was enough to justify an audit, and the audit found more than the two reads named above.

The rule was already written down here

AVFoundationOffMain has carried it since #134: these getters are synchronous XPC round trips to mediaserverd, and on the main actor a busy media server turns any of them into a fully blocked main thread and, past the watchdog threshold, a process kill. What had adopted it was the 30 s memory probe. The paths that run precisely BECAUSE the server is not answering had not.

path	reads per pass	now
seek-deadline loop	1 island + 3 bufferedEnd	one batched off-main snapshot
stall nudge / item reload	currentTime() at the call site and again inside	rendered-position mirror
VOD shift-publish line	avPlayerBufferAheadSeconds()	awaited off-main
premature-end recovery (#287)	playhead + seekable + loaded, separately	one batched reading

The seek-deadline loop is the one worth pointing at. It runs while a seek is not landing, which is the state you measured the block in, and it was taking four round trips per pass. bufferedEnd was two of those three.

The mirror was also the right value, which is the part that surprised me

recoveryAnchorPosition(currentRendered:) exists to keep a recovery anchor from sitting below the frame already on screen (#115). currentTime() is the clock, and the clock diverges from the rendered frame during exactly the landing those paths run in (#123). So the stall watchdog was not only reading through a call that can block, it was reading the wrong quantity to begin with. The wedge path immediately beside it was already passing the mirror, which is what made the inconsistency easy to see once someone looked.

What is not changed

The reads inside load() and the seek completion stay synchronous: both run at a moment where AVPlayer has just answered. And nothing here can be verified against a real block from this side, since it needs a media server that is not answering. What can be said is that the count of main-actor round trips in the recovery and deadline paths is now zero.

One thing that fell out of it

Taking the reads off the main actor took the logic with them. bufferedEnd was a @MainActor property wrapped around a blocking round trip, so its rule had no test at all; the pure function now has eight. One of them records a property the old shape hid: ranges are judged against the playhead rather than against the running end, so [100,152] and [152,170] do not chain and the figure understates the buffer. Left as it stands rather than fixed, because seekIsWedged reads an understated buffer as starvation and that deserves its own measurement before anyone moves it.

Merged to main (ee8780fe), not released. Thank you for mentioning it rather than only fixing it on your side; a single sample on one platform was worth more here than it might have looked.

[superuser404notfound]

Released in 6.43.0, with both consumers on the new pin. Leaving this open for the retest.