Resume discards the playback rate: `play()` is rate 1.0, and the host re-issues it from paths a client can't see

[rrgomes]

Measured on 6.45.0, Mac Catalyst, native path, on a 1080p24 H.264 MKV. Setting a
rate through setRate holds until playback is paused; the resume comes back at
1.0.

Rate survives a great deal — including two far seeks that re-aimed and restarted
the producer (producerShift=-14.056, rate 1.5 throughout). It is specifically
pause/resume that loses it:

01:47:11.937  rate=1.5                                (holding, after both seeks)
01:47:11.967  [NativeAVPlayerHost] #1 rate=0.0        pause
01:47:58.069  [NativeAVPlayerHost] #1 rate=1.0        resume — not 1.5
01:47:58.325  rate=1.0 … and stays 1.0

That much is expected from AVPlayer.play(), which is rate = 1.0 by
definition, and the host latches a boolean playIntent rather than a rate.

What we did not expect is that a host-side workaround cannot hold it.
Re-applying our intended rate immediately after the resume, plus a backstop
wherever the engine settles on .playing:

02:05:09.925  resume → rate=1.0
02:05:09.925  we set rate=1.5
02:05:09.970  rate=1.0        ← reset again, 45 ms later, from a play() we did not issue
02:05:09.970  we set rate=1.5
02:05:12.934  [FreezeDiag] trigger=stall state=playing frozenFor=3.0s rate=1.5
02:05:14.370  rate=1.0        ← final, and the phase never changed so nothing re-asserted

Three things follow. The rate is reset more than once per resume, from paths a
client cannot observe, so one write cannot hold it. A client backstop keyed on
the playback phase cannot catch the last reset, because the phase stays
.playing across the whole sequence. And the resume where we wrote rate three
times in 45 ms froze the clock for three seconds at the resume instant — an
identical earlier flap did not, so we are not claiming causation, but writing
rate inside AVPlayer's resume window is a poor place for a client to be.

We have reverted our workaround rather than ship it.

The ask is the pattern the engine already has for the neighbouring case:
desiredVolume with applyDesiredVolume(to:) exists so volume is re-applied to
whatever transport is current, and there is no desiredRate. Applying the
intended rate at the engine's own play sites would put it where the re-issues
already are.

Context, in case it changes the priority: this is for a group-watch feature where
one rate is shared across peers. A peer silently returning to 1.0 on any pause —
and a room pauses often, deliberately and for buffering — diverges from everyone
else and then gets pulled back by drift correction.

[superuser404notfound]

Confirmed, including the part that matters most here: the client-side workaround could not have worked. The re-issues come from the readyToPlay re-assert after an item swap, from interruption and background resume, and from the #287 premature-end recovery, and on top of those AVKit's transport and the remote command centre call play() straight on the AVPlayer, where neither a client nor the engine sees it. That is why one write was gone 45 ms later and the last one had no phase edge to hang a backstop on.

On main in f583deb, and the answer is the platform's own: AVPlayer.defaultRate, "the rate at which to start playback when play is called". Both AVPlayer-backed hosts record the speed there, so every play site resumes at it and nobody writes rate inside a resume window at all.

• Zero is now treated as a pause rather than a speed at all four hosts. It was being remembered as one, and it then became the rate the next resume, the software path's clock arming and a rebuffer recovery all came back at, so a session could return frozen while reporting itself playing. Reachable through the documented setRate(0), so it is worth naming even though it is not what this report hit.
• desiredRate now sits next to desiredVolume, exactly as suggested, and is seeded into every host a load builds, re-clamped to that host's ceiling (2.0 video, 3.0 audio-only). It is what carries the speed across the rebuilds a session makes on its own: reload at position, audio-track switch, AirPlay LAN swap, background return. On the software path those build a fresh host, so without it a rebuild still dropped to 1.0 even with the resume fixed.
• The speed belongs to the item. Loading a different source, or stop(), returns to 1.0. A rebuild of the same source keeps it. That way a host whose own speed control resets per item cannot end up displaying 1.0 over a session still running at 1.5, and a reused AVPlayer cannot carry the previous item's speed into the next one.

The measurement is a drill in the CLI harness, aetherctl play --host-calls ratehold: set 1.5, pause at tick 3, resume at tick 5 with no client write, then read the rate back off the transport itself rather than off anything the engine remembers. Native and software both hold 1.5 across the pause and across an audio-track switch. Both halves were checked by removing them again: without the defaultRate write the drill reports 1.00 after the resume, which is this report; without the engine seed it holds the resume and loses the rebuild.

For the group-watch case that means a peer keeps the shared rate across its own pauses and across any reload it does for buffering or a route change, and a rate that changes still does so only when someone asks for it.

Thanks for measuring the workaround as well as the defect. Without that second log the fix would very likely have landed as one more re-apply, in the same window you found is a bad place to be.

[superuser404notfound]

Released in 6.49.0. Worth knowing for the retest: the client-side re-apply can come out now, and should, since the rate is held on AVPlayer.defaultRate and a client write in the resume window is the thing that had you three writes deep in 45 ms. A pause, a buffering pause and an in-session reload should all come back at the shared rate; a rate that changes should only do so when a peer asks for it.