pauljdandClaude Opus 5.5
f9c879b2d9
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2.4 KiB
Orbit TV 0.95.2: reopen the sound when the box's audio clock goes wrong
A small fix of its own, approved by Paul on 3 November 2026. No scheduler, artwork or plan changes.
What happened: on the Drive-In (300) on 3 November, Godzilla (HEVC 4K with Dolby TrueHD 8-channel sent straight to the amplifier) started on time at 20:00. By about 21:37 the sound had drifted behind the picture. The box's log showed ExoPlayer warning twice a second: "Spurious audio timestamp (frame position mismatch)", with the hardware's playback position reading about 89,478 seconds (2^32 frames at 48 kHz, a wrapped counter). The sound hardware's position reports had become nonsense, so the player could no longer keep the picture in step. Retuning (a fresh audio track) fixed it, which Paul did at 21:48.
The change: once a scheduled programme has played steadily for 30 seconds (AUDIO_CLOCK_SETTLE_MS), Orbit sets ExoPlayer's DefaultAudioSink.failOnSpuriousAudioTimestamp, so a bad position report stops the player instead of being tolerated. That error (isAudioClockFault) is handled on its own: the player reopens at the programme's live position after 200 ms, with no failure message, and not counted as a retry. Logged as audioClockReset=N positionMs=… in logcat (OrbitSchedule) and the playback notes. At most 3 resets a programme (MAX_AUDIO_CLOCK_RESETS), then the old tolerant behaviour returns. Watching is off during the first 30 seconds of a programme (a single stray report is normal there), off under the ident, and switched off when the player closes.
Unchanged: schedules, plans, the guide, idents, preloading, and every other error path (the one retry, then "won't play").
Files: EmbyPlaybackDialog.kt (watchAudioClock, isAudioClockFault, the reset path and the settle timer); AudioClockTest (3 tests). 363 unit tests pass; lint has no errors. Not installed.
To check on the TV: a long film with TrueHD or DTS passthrough. If the fault returns, there should be a one-second blip and the sound back in sync, with audioClockReset in logcat, rather than a drift. If resets show up often early in films, raise the settle time.
Installed 3 November 2026 at about 22:02 with Paul's OK. All 31 committed plans byte-identical before and after. Not yet verified on the box: needs a long passthrough film; check logcat and playback-notes for audioClockReset and whether sync held.