[tiper]

Builds on #992. Its stereo cap in Auto is unchanged.

On my LG C1 (webOS 6.5.3), 5.1 Opus stalls silently once packets go over 1500 bytes, and Vorbis is refused. This adds:

• A small per-firmware list of what’s known to break, which Force Direct Play respects too.
• Learning: if the TV refuses a format or stalls on it, the app remembers that for this firmware and retries once with the server converting. A firmware update clears it.

FLAC stays on #950’s PCM route. Only measured on a C1 so far.

[GLinnik21]

Thanks @tiper, the packet-size measurement on the C1 is exactly the evidence this needed, and the per-firmware table with its evidence strings is a nice shape. Merged.

What I changed before merging:

• the retry now rides the existing recovery path: a refused or stalled native audio track goes through open_failure_action into a background recovery flight where the server converts the audio, so the viewer never sees the error screen first and the frame thread never waits on PMS. native_audio_retry / take_native_audio_retry / the app/run.rs retry are gone.
• the conversion is recorded as a Recovery attempt, so if the converted route also fails, the error report says it was the app's own second open.
• learned refusals have one owner, your Install preference, changed through one Session::with_native_audio_refusal method. The caps are derived from it by a single fold that can only remove capabilities, instead of the leaked per-rebuild snapshots and the extra statics.
• your two pump failure sites now end the Engine through Player: a terminal playback error lets go of the pipeline and the video plane #937's fail_engine_for_good, so the pipeline is released under the read-out.
• merged main in (Audio: Opus direct play, stereo in Auto (part of #918) #992, FLAC PCM: declare sampleRate in kHz #1036, player: webOS 3 seeks in place through LG's public Seek #1038, Player: a terminal playback error lets go of the pipeline and the video plane #937, Playback: a foreground Load refused while the plaintext grants return is claimed again #1018); the only conflict was the Preferences descriptor table, where your row and Audio: Opus direct play, stereo in Auto (part of #918) #992's both stay.

Kept as you wrote them: the measurements, the exclusion table, the stall watchdog and packet-size evidence, the stored preference type with its stale-build handling, and your tests. Nothing here was run on a TV, so a C1 check of the converted 5.1 Opus route would be welcome.

[tiper]

@GLinnik21
Tested on my C1 (webOS 6.5.3) with your build of main, against a mock server and a 5.1 Opus clip that stalls the C1’s decoder:

Auto: converted by the server, plays with no error screen.
Force Direct Play: refused up front by the C1 limit.
With the limit lifted (nativeaudiowide), the stall is caught after ~4 s and the background recovery plays it converted, no error screen.

Thanks for the rework, it’s cleaner than mine 🙂