Fixed
Audio track switching under tunnelled playback
Changing the audio track mid-playback could leave video stuttering and juddering (not buffering) with a sluggish player overlay, persisting until playback was stopped and resumed. Reported on a Prism+ (MediaTek) TV with tunnelling enabled.
Cause: the in-place track switch flushes the video decoder and recreates the AudioTrack inside a live tunnel. Under tunnelled playback video frames are released by the audio hardware clock, and on some vendor HALs the tunnel returns with bad frame pacing that persists for the rest of the title.
Fix: with tunnelling on, audio track changes now rebuild the player at the current position — the same recovery sequence used for audio init failures — instead of switching in place. Your selection is carried across the rebuild. You'll see a brief reload where you previously saw a seamless (but broken) switch.
With tunnelling off — the default — nothing changes. The in-place switch path is untouched.
Thanks to the Prism+ community tester for the report and for isolating the stop/resume workaround, which pointed straight at the cause.
Changed
Clearer device assessment results
Every row now reads as one of four honest states, instead of the ambiguous "No change" that was quietly covering three different situations:
- A recommended value (e.g. On, 175 MB) — the assessment is telling you what to set.
- ✓ Already set — the assessment endorses a specific value and your device already has it. Previously these rows looked identical to ones where nothing had been evaluated; now a green tick confirms you're already right.
- Your call — a genuine trade-off the assessment can describe but shouldn't decide for you (Resolution Matching on a multi-resolution display; frame-rate matching's Start vs Start & stop when it's already on). The reasoning is still shown; the choice stays yours.
- Leave as is — the deciding fact isn't available on this device (display can't be inspected, audio route unconfirmed, or the setting is inert on this hardware). Not a preference — just honestly outside what can be verified from here.
The Internal Engine row now confirms your engine with a tick when you're on ExoPlayer or Auto, rather than reporting a vague no-change.
Two recommendations that now argue their case
Both rows were previously stated without evidence, which broke the assessment's own rule that every recommendation shows its grounds:
- Custom Playback Buffers — now explains what Off actually costs: media3's stock load control computes its buffer target in bytes (~13 MB), which holds roughly one second of a 4K remux no matter what its duration settings say. The fork's values are sized to your device instead.
- ExoPlayer Native Memory — now leads with the real reason: it keeps remux-sized buffers off the Java heap, so garbage collection can't stutter frames. The memory-tier limits follow as supporting detail.
Honest note
Neither the assessment nor the speed test can measure what would happen with these two settings off — the sweep is a network instrument, and heap-versus-native effects live in decode and garbage-collection behaviour it never observes. So these rows now make a well-supported argument rather than claiming a measurement they didn't take. If a device ever turns up where off is genuinely better, that would be a bug worth fixing rather than a setting worth recommending.