This release brings the fork up to date with official NuvioTV 0.8.2. Two threads run through the fork's own work: lossless audio that starts cleanly and stays smooth on the hardware that struggles with it, and an app that's more honest and more resilient about what your audio chain, your add-ons and your debrid services actually deliver.

At a glance

• Everything from the official 0.8.2-beta release is included — among it MKV subtitles that use zlib compression, Continue Watching card styles, Bluetooth audio handling, external-player handoffs that survive leaving the screen, faster metadata, and a reworked Layout settings screen. Credit to the upstream authors: @tapframe, @skoruppa, @ram130, @supergera13, @halibiram, @haveAnIssue, @nosvasedis and @mmsw91.
• An unusual number of 0.8.2's audio fixes were already in this fork. Four of upstream's headline changes — un-gating the DTS-HD sniff from Dolby Vision handling, restricting audio recovery to actual audio failures, the light PCM rebuild step, and passthrough recovering at normal speed — are fixes this fork shipped independently over the last few weeks. The fork's versions are kept; nothing changes on your device in those paths.
• Lossless TrueHD no longer opens with a stutter. The player waits for enough actual audio data before starting, recovers automatically when the device's audio pipeline loses its place, and holds the picture steady while it does.
• Provider error cards are stopped, not played — and never touch your watch history.
• You choose how a denied audio format is handled: lossless multichannel PCM (the default) or AC-3 for chains that can't take multichannel PCM.
• The app learns codecs your TV claims but can't actually play, and stops retrying them.
• Audio diagnostics grew up: what your HDMI link actually negotiated, what was refused at the door, and how many PCM channels it can genuinely carry.
• Slow add-ons get a 15-second deadline, and catalogues in the older manifest style finally page and search.
• High-bitrate remuxes stop stalling under Custom Playback Buffers.

New

Provider error cards are stopped, not played

Debrid services and scrapers sometimes answer a stream request with a valid, playable file whose entire content is an error message — a few-hundred-kilobyte "no matching file" clip dressed up as a full release. These played as if the title had started, and in one case crashed the app. They're now recognised and stopped with a plain message:

This stream looks like a provider error card, not the video. Try a different source.

Two checks drive it — a size floor (proven on device: a 407 KB card served for a nearly two-hour film, stopped cleanly) and a length backstop for the rarer card big enough to slip past it. Both apply only once the app knows roughly how long the title should be, and missing information always means "don't judge", never "reject" — a real stream can't be thrown away. A stopped card leaves no trace: no resume progress, no watched mark, no auto-advance to the next episode.

Choose how a denied audio format is handled

The per-format passthrough switches from nt1 decode anything you switch off to lossless multichannel PCM. That's the wrong answer for a chain that can't accept multichannel PCM at all — a two-channel-LPCM soundbar collapses a 7.1 track to stereo, silently. New under Playback → Audio → Denied Codec Handling:

• Decode to PCM — the default, and unchanged behaviour.
• Transcode to AC-3 — opt-in: denied formats are re-encoded to AC-3 and passed through as a bitstream, so those chains get full 5.1 instead of stereo.

The transcode option never applies to AC-3 itself, and stands down (falling back to PCM decode) if your chain turns out to reject AC-3 too. On a chain that takes multichannel PCM, leave the default alone — lossy 5.1 would be a downgrade, which is exactly why this is opt-in. Verified on device: the same DTS-HD MA track plays as multichannel PCM in one mode and as an AC-3 bitstream in the other. This exists because of a community report describing precisely this kind of chain — thank you.

The app learns what your chain truly can't play

Some TVs advertise a codec — because the receiver behind them lists it — that their own hardware then refuses to open at play time, so every play went attempt, fail, recover, repeat. The app now learns: once a codec has been refused in two separate sessions, it's decoded from the first moment instead. Deliberately cautious — two sessions so a one-off glitch never penalises a codec, tied to the specific output route (swapping ARC ↔ eARC starts fresh), and only where a software decoder can take over. On hardware that plays its codecs, nothing changes.

Being straight about where this stands: on a capable chain the mechanism never engages — which also means it hasn't yet been exercised end to end on an affected chain in the field. The decision logic is fully covered by tests; reports from a chain that trips it are very welcome. There's no "forget" control yet — if your chain genuinely gains a capability on the same connection, clearing the app's data starts fresh.

Improved

Lossless TrueHD: clean starts, automatic recovery, steady picture

Titles with very quiet openings — a slow fade-in, a hushed cold open, a studio logo — could open with a burst of stuttering and a several-second jump when TrueHD was passed through. Quiet lossless audio carries far less data per second, so "seconds buffered" was the wrong measure: the audio pipeline downstream was handed a trickle, ran dry, and raced to find its place again, dragging the picture with it. The player now waits for enough actual audio data, not just enough seconds — a fraction of a second longer on a quiet opening, nothing at all on a normal one, with a hard time limit so no stream is ever held up. Scoped to TrueHD; constant-bitrate formats can't hit this.

The same fault can also strike on a cold app start, when the frame-rate switch briefly drops the HDMI link. The player now recognises its signature — the audio clock racing ahead of real time — and handles it by itself: a quick automatic in-place jump (the same thing a manual skip does) that rewinds to exactly where the disruption began; a fresh correction budget for a rare later disruption after a clean stretch of playback; and the picture held steady through the disruption instead of stuttering — imperceptible in the common case, up to a couple of seconds in the spaced-out case, strictly bounded, and deliberately blind to network rebuffer jumps, which are a different thing.

Being straight about the limits: this recovers from the fault rather than preventing it — a brief unsettled moment can still occur on a cold start, and a smaller, shorter roughness on warm starts, below what the recovery watches for. Starting another title without fully closing the app avoids the cold-start case entirely. The same file misbehaves identically in the official app and in an unrelated player, so this is a device-level limitation being worked around, and preventing it entirely is ongoing. Network rebuffering on a marginal connection is a separate, unaddressed issue — that's the next area of work.

Audio diagnostics that tell you the truth

The Audio Chain Claims row on the stats overlay now reports on labelled lines instead of one badly-wrapping line, and from more honest sources: Negotiated — the encodings the HDMI/ARC/eARC output actually negotiated, a cross-check on the platform's optimistic claims; Rejected — codecs the platform accepted on paper but refused at open, the line that finally names what failed; Max PCM — the negotiated PCM channel count, the one capability no failure can ever teach, since a two-channel chain collapses multichannel PCM to stereo silently; and a Surround field that reads n/a (<API 31) on Android 10/11 rather than a misleading unknown.

The Device Settings Assessment puts this to work: it now recommends a Denied Codec Handling value from the negotiated PCM channel count — a two-channel chain towards Transcode to AC-3 (only where AC-3 passthrough is enabled), a multichannel chain towards Decode to PCM, and an unreadable answer means leave as is. The per-format switches themselves stay in your hands.

Smaller improvements

• Every add-on now has its own 15-second deadline, so one unresponsive source can no longer hold the stream list for the shared network budget of a minute and a half. Deliberately generous — a cold scrape on a large title genuinely takes ten seconds or more — and a source that times out is now named in the error detail instead of quietly vanishing.
• When opened from Continue Watching, the runtime on the stream screen now comes from the file you previously played, so it appears sooner (it may differ from the add-on's figure by a minute or two).

Fixed

Stalling on high-bitrate remuxes with Custom Buffers

The back buffer is charged against the same memory budget as the buffer ahead of you, but the two were sized independently — at remux bitrates a 15-second back buffer could reserve 150–190 MB of a 150 MB budget, so playback would stall, briefly recover, and stall again. The default back buffer is now 5 seconds. Installs on the old default migrate automatically; a value you chose yourself is left alone — unless you'd chosen 15 s, the previous default, which the migration can't tell apart from a leftover default. Only reachable with Custom Playback Buffers on; a default install builds a 1.5-second back buffer and was never exposed.

A half-denied format family no longer strands playback

With DTS allowed but DTS-HD denied, a DTS-HD Master Audio track could fail outright with a playback error: these tracks announce themselves as plain DTS first and reveal the full format only mid-stream, wrong-footing the decoder choice — and the player rebuilt itself into the identical trap until its retries ran out. It now recognises the situation and recovers with one automatic rebuild that prefers the app's own decoder for that stream. One trade-off, on that stream only: other audio tracks are decoded to PCM rather than passed through — a degraded track beats an error screen. Verified on device in both handling modes; default settings unaffected.

The stats panel no longer floods the system log

On devices whose temperature sensors don't respond to apps (the Xiaomi TV Box S is one), the panel's once-a-second SoC temperature request triggered a retry storm — tens of thousands of error lines a minute while the panel stayed open. The panel now recognises a device that cannot answer, stops asking, and hides the row. Devices whose sensors do work are unaffected: an occasional missed reading never causes the row to give up. Ordinary viewing was never affected.

Catalogues in the older manifest style now page and search

Stremio add-ons can declare a catalogue's supported extras in two ways, and Nuvio read only one — so any catalogue using the older short form stopped after its first batch of items and never appeared in search. Both forms are now read, and a catalogue that lists its own skip positions without declaring a page size has one inferred from them. If a row has been stopping at ten or twenty items, this is the fix. Adapted from upstream PR NuvioMedia/NuvioTV#2871 by @supergera13 — the descriptor-parsing half only.

Smaller fixes

• The loading screen's source and filename lines no longer overlap the title artwork — the text is anchored below the artwork rather than positioned from the screen centre, so clearance holds for any artwork and any release name.
• Two buffer fields in playback issue reports described what was configured rather than what the player actually ran, understating the back buffer; both were corrected. Neither ever affected playback.
• An internal control that tried to adjust the back buffer mid-stream was removed — the player fixes its back buffer at start and never re-reads it, so the control could never work.

Install

Sideload via ADB or a file manager. This is a personal test build with the application ID com.nuvio.tv.test, so it installs alongside official NuvioTV rather than replacing it.

Licence and attribution

GPL v3.0. All upstream copyright headers, licence text and developer attributions are preserved; no licence text was removed.

• Upstream is NuvioMedia/NuvioTV, whose player, audio sink, renderer, tracking and settings plumbing this work extends. This fork is not affiliated with or endorsed by the NuvioTV project — please do not report issues from this build to upstream.
• The catalogue-manifest fix adapts the descriptor-parsing half of upstream PR NuvioMedia/NuvioTV#2871 by @supergera13.
• The bundled FFmpeg audio decoder library was modified for the per-format transcode decisions; its complete corresponding source is included in the repository at app/libs/ffmpeg-aar-src, credited to the AOSP media3 authors and @halibiram, per GPL v3.0.
• Thanks to the community members whose reports shaped this release's audio work — particularly the one describing a TV that advertises formats its hardware then refuses.