Skip to content

Audit: competitive IPTV benchmark and pre-alpha product/architecture priority reset #205

Open
Open
Audit: competitive IPTV benchmark and pre-alpha product/architecture priority reset#205

Description

@MrFr3di
MrFr3di
opened on Aug 24, 2026

Objective

Create a durable, source-backed product + architecture benchmark for MuxTV against mature TV/IPTV applications and use that benchmark to realign pre-alpha priorities without weakening the engineering properties MuxTV already gets right.

This is an umbrella audit / decision issue, not authorization for one large implementation PR.

It exists because the repository has reached an unusual state:

MuxTV is currently much more mature as an engineering platform than as a finished IPTV product.

That asymmetry is useful only while the engineering control plane accelerates product delivery. The current repository is close to the point where CI/evidence/contracts/documentation can begin to outpace the user-visible IPTV loop (provider → guide → live → catch-up → recovery).

This issue therefore owns:

  • the competitive baseline;
  • the distinction between engineering maturity and market/product maturity;
  • the product thesis derived from the benchmark;
  • priority ordering across already-owned implementation issues;
  • explicit decision rules for what should and should not move before 0.1.0-alpha.

It does not take implementation ownership away from the existing architecture, UI, release, measurement, provider, playback or Android compatibility issues.

Audit baseline and freshness

Repository checkpoint

Audit baseline:

  • repository: MuxTV/Muxtv;
  • branch: main;
  • exact audit SHA: 5aa9c108cc63187d8066494fb30c73b82f4e0f97;
  • audit date: 2026-08-24;
  • app identity: app.muxtv.tv, 0.1.0-alpha.1;
  • minSdk: 26;
  • current Android stack includes Kotlin, Compose for TV, Navigation 3, Media3, Room 3, WorkManager, Hilt and OkHttp.

Important: .work/CURRENT-STATE.md is intentionally a reviewed snapshot, not dynamic HEAD. The audit therefore treats live Git/GitHub state as current execution truth and uses the snapshot only as historical reviewed evidence.

The current settings.gradle.kts contains 28 included Gradle modules, while the older reviewed snapshot still describes 27. This is not itself a defect; it demonstrates why snapshot state and live state must remain visibly distinct.

Immutable repository references used by this audit:

Owner relationships / meta-links

This issue is a coordination and prioritization layer over existing owners.

Area Existing authority Relationship to this audit
Provider/catch-up/device architecture #184 Primary implementation umbrella; this audit provides market/product priority justification
Compatibility corpus #186 Required before claiming broad IPTV dialect support
Player implementation leakage #201 Dependency-inversion cleanup before provider expansion
Sources implementation leakage #202 Dependency-inversion cleanup before provider expansion
Android 17 LAN access #204 Release-critical compatibility/security path
TV UI characterization #188 / #93 User-visible TV quality closure before declaring UX maturity
Measurement correctness PR #178 / #27 Performance evidence must be trustworthy before claims
Physical/release qualification #31 Required for device/codec/HDR/audio claims
Source HTTP validators #100 Useful efficiency improvement, lower priority than provider/catch-up completeness
Provider readiness #112 Remains readiness/activation semantics authority
Lifecycle persistence #118 Remains reboot/unlock/package-replace lifecycle authority
Buffer policy #109 Must remain measurement-driven, not copied from competitor constants
TV Doctor/fallback #30 Existing diagnostics/recovery owner
Seek ownership #132 / accepted follow-up work Do not reopen single service-owned seek authority as part of this audit

Do not collapse these into a mega-PR.

Methodology

This report intentionally separates engineering quality from product/market maturity.

Quality model

Use ISO/IEC 25010:2023 as the general quality reference model. The standard defines a product quality model intended for specifying, measuring and evaluating software/ICT product quality, including use in requirements, testing objectives and acceptance criteria.

This does not mean that the numerical scores below are ISO certification scores. They are decision heuristics grounded in repository evidence and competitor capabilities.

Android TV quality model

Use the current Android TV quality framework:

Competitive benchmark rule

Do not compare only by feature count.

Benchmark dimensions:

  1. TV-native UX / D-pad / EPG ergonomics;
  2. Live TV + EPG core;
  3. provider/protocol breadth;
  4. catch-up / timeshift / DVR / multiview;
  5. playback/device compatibility;
  6. catalog/search/multi-source management;
  7. operational/product maturity.

Internal code quality of closed-source competitors is not inferred. Their benchmark score describes user-visible/product capability only.

Exact aggregate values are therefore directional decision aids, not scientific rankings; the important result is the maturity cluster and gap distribution.

Executive verdict

Primary conclusion

MuxTV is a strong pre-alpha engineering system, but it is not yet a peer product to TiviMate/Sparkle/OTT Navigator.

The strongest current areas are:

  • bounded hostile-input handling;
  • immutable/staged catalog and EPG publication;
  • previous-good retention;
  • explicit refresh/run ownership;
  • process-owned Media3 playback lifecycle;
  • bounded generation-safe recovery;
  • credential/redaction/network security boundaries;
  • exact-SHA evidence and deterministic Android harness discipline.

The weakest market-facing areas are:

  • provider breadth;
  • end-to-end catch-up/archive semantics;
  • local timeshift/DVR/multiview;
  • mass-user onboarding;
  • physical device/codec/HDR/audio qualification;
  • final TV UI polish and release maturity.

The strategic danger is not primarily conventional technical debt. It is premature sophistication: continuing to expand CI/contracts/architecture machinery faster than the core user-visible IPTV loop becomes complete.

MuxTV maturity scorecard

The scores below deliberately separate architecture from shipped product capability.

Dimension Current assessment Interpretation
Engineering foundation for pre-alpha 7.8/10 Strong for current stage
Data integrity / ingest safety 9.0/10 One of the strongest parts of the repository
Playback architecture 8.5/10 Correct single-owner direction; adapter leakage remains
Security/privacy architecture 8.5/10 Significantly stronger than a typical IPTV MVP
TV UX engineering discipline 7.5/10 Strong methodology, characterization and focus evidence
Demonstrated TV UX polish 5.5/10 Current UI still has known characterization/regression work
IPTV protocol/provider maturity 3.5/10 Main functional gap
Device/playback compatibility evidence 4.5/10 Architecture exists; hardware truth is insufficient
Performance evidence maturity 5.0/10 Strong harness, but measurement correctness is still being repaired
Release maturity 4.5/10 Appropriate for pre-alpha, insufficient for broad support claims
Maintainability of current code graph 6.8/10 Good modularity with confirmed boundary drift
Delivery efficiency 5.5/10 Control-plane complexity is becoming material

A separate product-capability heuristic places current MuxTV around mid-40s/100 against mature IPTV clients. This must not be interpreted as code quality; it means a current user still loses major workflows by replacing a mature IPTV application with MuxTV.

Competitive product benchmark

Reference products:

  1. TiviMate — TV UX / complete mainstream IPTV workflow benchmark;
  2. Sparkle TV — PVR/timeshift/provider breadth benchmark;
  3. OTT Navigator — multi-provider aggregation / duplicate folding / fallback benchmark;
  4. Televizo — baseline mass-user IPTV completeness benchmark;
  5. Kodi + PVR IPTV Simple — protocol/catch-up/timeshift semantics benchmark;
  6. Jellyfin Android TV — engineering reference for device capability and hardware-specific playback truth, not a direct IPTV product competitor.

Directional product maturity cluster:

Product Directional maturity Primary reference value
Sparkle TV ~90+ PVR/timeshift/provider breadth
TiviMate high-80s TV-first UX + mature IPTV workflow
OTT Navigator mid/high-80s multi-provider aggregation/power-user IPTV
Kodi + IPTV Simple low/mid-80s protocol/catch-up/timeshift compatibility
Televizo mid/high-60s simple but complete mainstream IPTV baseline
MuxTV current mid-40s engineering reliability foundation, incomplete product breadth

Do not optimize for a two-point difference between competitors. Optimize for closing MuxTV's large capability gaps while preserving its stronger architecture.

Competitor conclusions

1. TiviMate — UX and mainstream IPTV baseline

Current official Google Play description lists:

  • large-screen Android TV / remote-first UI;
  • M3U;
  • Xtream Codes;
  • Stalker Portal;
  • EPG;
  • multiple playlists;
  • favorites;
  • catch-up;
  • recording;
  • search;
  • parental controls;
  • multiview.

Sources:

Adopt

  • fast channel-centric navigation;
  • high-information-density but readable EPG;
  • minimal distance between current playback and channel/program selection;
  • TV/remote-first hierarchy.

Do not copy blindly

Do not define success as “same screen skin as TiviMate”. The durable target is equivalent interaction quality plus MuxTV-specific reliability/diagnostics advantages.

MuxTV gap

MuxTV has stronger observable architecture than we can infer for a closed competitor, but the user still lacks complete provider/catch-up/recording/multiview flows. Engineering advantages are therefore mostly latent rather than market-visible.

2. Sparkle TV — strongest functional warning for the current roadmap

Current official Google Play feature set includes:

  • Android TV / Google TV / Fire TV;
  • M3U/M3U8, Xtream Codes, XMLTV;
  • Stalker Portal;
  • Jellyfin, Plex, Tvheadend, Enigma2, HDHomeRun and other PVR sources;
  • EPG;
  • multiple audio tracks;
  • DVB/teletext subtitles;
  • AFR;
  • local timeshift;
  • DVR and series recording;
  • multiview;
  • catch-up/VOD/movies/series;
  • multiple simultaneous sources;
  • parental controls;
  • remote customization;
  • Android TV Home integration.

Source:

Strategic conclusion

The existing roadmap position of Xtream/provider catch-up inside a late “provider expansion” phase is too conservative for a competitive IPTV product in 2026.

This audit does not recommend moving DVR, multiview and full local timeshift before playback stability. Those remain expensive, high-risk capabilities.

It does recommend promoting:

  • minimum ProviderCapability seam;
  • one real Xtream vertical slice;
  • first-class provider catch-up/archive playback intent;

into the pre-alpha/early-alpha product path.

3. OTT Navigator — strongest product analogue to future Smart Channels

Official FAQ describes:

  • multiple providers;
  • grouping channels across providers;
  • duplicate folding for same/close channel names;
  • automatic switch to the next folded source on playback failure;
  • manual source switching.

Source:

This maps directly to MuxTV's intended future shape:

canonical channel
    ↓
provider provenance
    ↓
multiple stream variants
    ↓
health / compatibility
    ↓
primary + bounded fallback

Adopt

  • multi-provider aggregation concept;
  • duplicate/variant folding as a user-visible simplification;
  • playback fallback between equivalent variants.

MuxTV opportunity

MuxTV can improve on the product concept by making decisions explicit, reversible and explainable through provenance and TV Doctor rather than exposing an increasingly large manual settings surface.

Constraint

Do not implement automatic fuzzy merge before labeled-corpus precision proves it safe. False-positive merge remains more damaging than missed merge.

4. Televizo — the minimum mainstream completeness warning

Current Google Play description lists:

  • multiple playlists;
  • EPG;
  • catch-up;
  • Chromecast;
  • sorting/search;
  • parental controls;
  • favorites;
  • video/audio/subtitle track selection.

Source:

Televizo matters because it represents a simpler product, not because it is the architectural ideal.

The warning is:

A user will not compensate for missing catch-up/provider workflows because MuxTV has better immutable revision semantics.

Before positioning MuxTV as a mainstream IPTV alternative, its basic user journey must at least match this completeness level while retaining TV-first quality.

5. Kodi + PVR IPTV Simple — protocol and catch-up semantics reference

The current PVR IPTV Simple documentation supports:

  • multiple M3U/XMLTV pairs;
  • provider catch-up/archive;
  • multiple inputstreams;
  • HLS/DASH/Smooth Streaming through inputstream.adaptive;
  • live/catch-up timeshift modes through inputstream.ffmpegdirect;
  • EPG-driven archive playback;
  • catch-up modes including default/append/shift/Flussonic/Xtream-style resolution;
  • catch-up windows and corrections;
  • playback-as-live vs bounded-program semantics;
  • programme-to-programme and archive-window navigation.

Source:

Core architectural lesson

Catch-up is not URL string substitution.

The domain must preserve the difference between:

  • Live(channel);
  • CatchupProgram(channel, programme, start, end);
  • CatchupPosition(channel, wallClockPosition).

Provider resolution then creates a transport-level descriptor. player:media3 must not learn M3U/Xtream/Kodi catch-up dialects.

This supports the direction already proposed under #184.

6. Jellyfin Android TV — device capability truth reference

Jellyfin documentation explicitly notes that Android TV HDR support depends on the specific device. Current Android TV issues and changes also demonstrate why codec/audio/HDR capabilities cannot be inferred safely from API level or generic codec names alone.

Sources:

Adopt

Build a typed DevicePlaybackProfile from runtime/platform evidence:

  • actual decoder capabilities;
  • supported resolutions/profiles where queryable;
  • display HDR capabilities;
  • audio route/capability evidence;
  • narrowly scoped evidence-backed quirks.

Reject

  • manufacturer-name heuristic as primary truth;
  • “API >= X therefore Dolby Vision/TrueHD works” assumptions;
  • emulator evidence as codec/HDR/passthrough certification.

#31 remains the physical support-claim authority.

Confirmed MuxTV strengths to preserve

A. Hostile-input and bounded ingest

StreamingM3uParser already enforces explicit limits including line size, entry count, attributes and metadata accumulation. It streams entries rather than building an unbounded full playlist in memory and remains cancellation-aware.

It already recognizes common IPTV metadata including:

  • tvg-id / tvg-name / tvg-logo;
  • group/channel-number metadata;
  • catchup* fields;
  • User-Agent/Referer metadata;
  • #EXTVLCOPT;
  • #KODIPROP;
  • playlist-level EPG references.

Do not replace this with a giant “parse everything to DTO list” provider layer.

B. Immutable/staged publication

Catalog and EPG work already use staged/revision semantics and preserve previous-good data. This is strategically valuable for unreliable IPTV endpoints.

Future providers must plug into these publication owners; they must not create parallel mutable provider-owned catalogs.

C. Playback lifecycle ownership

Current MuxTvPlaybackService owns the single ExoPlayer/MediaSession runtime, setup generations, recovery and final seek mutation.

This audit does not reopen duplicate-player or duplicate-seek ownership work.

D. Security/privacy

Preserve:

  • Keystore-backed credential ownership;
  • exact-origin cleartext approval;
  • scoped request headers;
  • no raw token/Cookie/Authorization/credential URL in logs or UI semantics;
  • redacted observations/diagnostics;
  • bounded external playback descriptor validation.

Provider compatibility must not be purchased by leaking provider secrets.

E. Evidence discipline

Current self-hosted workflows already enforce exact-source checkout/provenance, clean runner state, Android harness validation, evidence upload and post-run reset.

The canonical persistent AVD contract remains exactly:

  • MuxTV_TV_OLD_API26;
  • MuxTV_TV_CURRENT_API36.

Do not create resolution-, benchmark-, player-, database- or low-RAM-specific persistent AVDs.

Confirmed gaps / contradictions

1. Normative architecture is currently cleaner than the implementation

.work/ARCHITECTURE.md says feature modules should not directly consume player implementation, DAO/network or adapter implementation details.

Current graph violates that intent:

feature:player directly depends on player:media3 and Media3 UI.

feature:sources directly depends on refresh/sync/credentials/database implementation modules.

Owners:

These should be fixed before broad provider expansion, but as narrow dependency inversion — not as a repository-wide Clean Architecture rewrite.

2. Catch-up metadata support is not catch-up product support

Current M3U ingest already recognizes and persists catchup, catchup-source, catchup-days, catchup-correction farther than parsing.

The live playback projection still fundamentally resolves toward stream locator/request metadata rather than preserving a first-class archive timeline intent.

Therefore:

Parsing catch-up tags must never be advertised as complete catch-up support.

Owner: #184 plus compatibility input contract #186.

3. Provider breadth is too narrow for a competitive IPTV alpha

M3U/XMLTV remains a valid and important source type, but MuxTV currently lacks the breadth users expect from mature IPTV clients.

Recommended first second-provider implementation: Xtream Codes, because it tests authentication, credentials, inconsistent JSON typing, separate live/EPG/catch-up capabilities, rate/error semantics and optional VOD/series without requiring those optional products to ship.

Do not implement Xtream + Stalker + Jellyfin simultaneously.

4. Android 17 LAN access is a release-critical gap

Android 17 requires ACCESS_LOCAL_NETWORK at runtime for apps targeting API 37+ unless a system-mediated path is used.

Official source:

#204 documents that Add Source currently lacks the full permission-aware journey and that local-network classification also needs alignment.

This is a release blocker for targetSdk 37 LAN-source claims, not post-alpha polish.

5. TV UI engineering is stronger than demonstrated UI polish

#188 exists because shared rail/content geometry, focus restoration and visual-scale regressions still require characterization against accepted immutable baselines.

Therefore distinguish:

  • UX engineering discipline — strong;
  • current proven market polish — incomplete.

Do not claim TiviMate-level UI polish merely because the focus test strategy is sophisticated.

6. Performance infrastructure is stronger than current performance truth

PR #178 demonstrates that the measurement harness itself had an invalid global boundary expectation for a selective search result while product semantics were correct.

That is healthy to discover, but it means benchmark/tooling count must not be mistaken for validated product performance.

Until #178/#27 evidence is clean:

7. Branch governance is weaker than CI discipline

At the audit checkpoint the live GitHub branch response exposed main as not protected through the classic branch-protection endpoint.

Because GitHub repository rulesets may provide protections separately, this audit does not assert that the repository is definitely ungoverned without checking rulesets.

However, before public release the effective policy must be verified to guarantee at minimum:

  • PR-based integration where intended;
  • required validation for relevant changes;
  • no accidental force-push/direct bypass of accepted evidence.

A strong exact-SHA pipeline is not sufficient if repository governance can bypass the evidence contract.

8. Documentation/live-state drift is now a real operational concern

Reviewed snapshots are useful and should remain.

But tools/agents must distinguish three concepts explicitly:

LIVE HEAD
  = execution truth

LAST REVIEWED SNAPSHOT
  = reviewed historical truth at an exact SHA

NORMATIVE ARCHITECTURE
  = intended invariant/decision truth

A stale snapshot must not be read as current implementation state.

Product thesis

Do not position MuxTV as “free TiviMate” or “Sparkle clone”.

The more defensible target is:

MuxTV is a fast, local-first, TV-native IPTV client that turns multiple imperfect providers into one stable personal TV catalog, understands Live/EPG/Catch-up as real timeline semantics, automatically chooses viable stream variants, and explains failures/fallbacks through TV Doctor without requiring a cloud account.

This product thesis uses MuxTV's existing strengths instead of competing only by feature count.

A future differentiated journey should look like:

Provider A + Provider B
        ↓
canonical/provenance-aware channel
        ↓
multiple variants
        ↓
device compatibility + recent health
        ↓
primary stream fails
        ↓
bounded fallback to safe reserve
        ↓
viewer keeps watching
        ↓
TV Doctor explains the fallback without exposing secrets

This is a stronger long-term differentiator than “we also support Xtream”.

Roadmap priority reset

The current roadmap is architecturally disciplined, but the market benchmark argues for one major change:

Provider capability + Xtream + provider catch-up should move earlier. DVR/local timeshift/multiview should remain later.

P0 — before a convincing public 0.1.0-alpha

P0 is the minimum path required to make the current engineering platform translate into a coherent IPTV product.

Stabilization / evidence correctness

Product completeness promotion

Promote from late roadmap:

These do not require DVR, VOD/Series product UI or local timeshift to ship.

P1 — alpha → beta

  • QR/phone-assisted source/provider onboarding;
  • backup/restore closure;
  • typed DevicePlaybackProfile;
  • canonical multi-provider provenance/identity;
  • evidence-based variant ranking/fallback;
  • Source refresh: conditional HTTP validators and 304 Not Modified #100 HTTP conditional validators / 304 efficiency path;
  • broader TV Doctor explanations;
  • additional provider compatibility fixtures.

QR/phone onboarding deserves elevated priority because entering long URLs/provider credentials with a TV remote is intrinsically poor 10-foot UX.

P2 — after single-stream stability is proven

  • local timeshift;
  • DVR and recording scheduler;
  • recording storage/conflict/recovery;
  • multiview;
  • VOD/Series product surface if separately approved.

These features materially increase storage, concurrency, memory, player and lifecycle complexity and should not delay the core Live/Catch-up product loop.

P3 — later / evidence-gated

  • Stalker after Xtream;
  • sophisticated Smart Channel auto-merge;
  • extension ecosystem;
  • alternate libmpv engine;
  • advanced plugin marketplace;
  • other providers with no concrete second-user/product justification.

Alpha vertical definition

A convincing 0.1.0-alpha should prove one closed journey rather than many disconnected subsystems:

Install
  ↓
Add M3U or Xtream source
  ↓
Secure credentials / network policy
  ↓
Refresh without corrupting previous-good catalog
  ↓
Channels + Search + EPG
  ↓
Stable D-pad navigation
  ↓
Live playback
  ↓
Audio/subtitle selection
  ↓
Catch-up from Guide where provider supports it
  ↓
Bounded recovery/fallback
  ↓
Doctor explains relevant failure/fallback
  ↓
Restart / process recreation / refresh preserves valid state

Everything not required to prove this journey must be challenged for pre-alpha necessity.

Control-plane budget / anti-overengineering rule

MuxTV's CI/evidence discipline is a strength, but new infrastructure should now face a higher bar.

Before alpha, a new workflow, module, generalized framework or evidence subsystem should be accepted only if at least one is true:

  1. it closes a proven false-positive/false-negative in current validation;
  2. it protects a concrete alpha/release support claim;
  3. it is required by the next real second implementation (for example Xtream proving a provider seam);
  4. it removes meaningful duplicated ownership or prevents a known class of corruption/security failure.

Otherwise defer it.

Temporary architectural constraint

Do not add a new Gradle infrastructure module merely to make a diagram cleaner.

Prefer extending existing stable seams (catalog:api, player:api, composition root) until a genuine second implementation proves that another module has independent value.

Persistent AVD policy clarification

Preserve the repository's exact two persistent AVD identities:

  • MuxTV_TV_OLD_API26;
  • MuxTV_TV_CURRENT_API36.

Do not proliferate resolution/low-RAM/benchmark AVDs.

However, the architectural invariant should be interpreted as:

no more than two persistent repository-owned AVD identities

—not as:

MuxTV may never execute any validation against another API level.

Android 17/API37-specific runtime behavior cannot be certified by API36.

When API37 qualification is required, use an explicitly approved non-persistent/ephemeral strategy or physical Android 17 device evidence without silently creating a third long-lived repository AVD. When API37 becomes the appropriate “current” canonical environment, replace API36 rather than accumulating another permanent device.

Owner: #204 / #31.

Risk register

Risk Evidence Impact Priority
Product capability gap vs mature IPTV apps competitor benchmark user adoption / replacement value Critical
Xtream/catch-up too late in roadmap TiviMate/Sparkle/Kodi baseline market completeness Critical strategic
Android17 LAN source journey incomplete #204 + official Android 17 behavior core local-source failure Release blocker for targetSdk37 claim
Current TV UI regression uncertainty #188 usability / TV quality High
Physical codec/HDR/audio evidence incomplete #31 invalid support claims / playback failures High
Feature→adapter implementation leakage #201/#202 provider expansion cost High before provider expansion
Measurement harness still being repaired PR #178 misleading performance decisions High for claims
CI/control-plane work outpacing product loop repository history delivery speed High strategic
Effective branch/ruleset governance not yet evidenced in this audit live branch state bypass of evidence discipline High release governance
Snapshot/live-state confusion current docs vs live HEAD agent/developer mistakes Medium
Cutting-edge dependency churn version catalog stabilization risk Medium
Provider abstraction becomes generic before second implementation #184 scope risk overengineering High if unmanaged

Dependency strategy before alpha

Current stack is intentionally modern and includes very recent Android/Kotlin/Room/Media3 components.

That is acceptable during active foundation work, but near alpha the policy should change from:

latest compatible

into:

known-good qualified release train

Do not continue broad dependency upgrades solely because a newer version exists while P0 compatibility, catch-up and physical qualification remain incomplete.

Exceptions require a concrete bug/security/platform requirement or measurable product benefit.

What must NOT be done to “catch up” with competitors

Do not respond to Sparkle/TiviMate parity by implementing every checkbox simultaneously.

Before the core vertical is proven, avoid bundling:

The intended sequence is vertical and evidence-backed:

M3U excellent
  ↓
Xtream excellent
  ↓
catch-up excellent
  ↓
multi-provider identity/provenance/fallback excellent
  ↓
storage-heavy PVR features

Decision rules

Rule 1 — product evidence before generalized architecture

A new abstraction must point to a real second implementation or current duplication/risk.

Rule 2 — compatibility claims are executable

Recognizing syntax in a parser is not support. Use #186 dispositions:

  • SUPPORTED;
  • IGNORED_SAFE;
  • REJECTED;
  • NOT_IMPLEMENTED.

Rule 3 — hardware claims are device-scoped

Emulator evidence proves API/platform behavior, not MediaCodec/HDR/Dolby Vision/passthrough/Fire OS compatibility.

Rule 4 — one mutation owner

Preserve one owner for player mutation, source publication, readiness activation and retry classes. Provider expansion must not introduce parallel scheduler/player/refresh authorities.

Rule 5 — no secret compatibility debt

Never gain provider compatibility by persisting/logging raw credential-bearing URLs, provider responses, Authorization/Cookie values or unredacted exception payloads.

Rule 6 — TV quality is user-visible behavior

A sophisticated focus harness is not evidence of polished UX until representative 720p/1080p D-pad/focus/readability behavior is actually green.

Rule 7 — control plane must earn its cost

Every new pre-alpha CI/evidence mechanism must defend a concrete correctness/support/release claim or fix a measured validation defect.

Acceptance criteria for this audit issue

This issue is complete only when the benchmark has materially changed execution priorities, not merely when the report exists.

External source index

Quality / TV platform

Competitive / prior-art products

Final decision

MuxTV should not reduce its engineering rigor.

It should now change where that rigor is spent.

The repository already has enough foundation to justify moving from “control the system” toward “prove the complete IPTV product loop”. The next competitive step is not another generalized framework. It is to make the existing architecture visibly valuable to the viewer through:

  1. a stable TV UI;
  2. M3U and Xtream provider workflows;
  3. real EPG-driven catch-up timeline semantics;
  4. bounded recovery/fallback;
  5. device-aware playback truth;
  6. simple TV onboarding;
  7. TV Doctor explanations;
  8. physical-device support evidence.

If MuxTV preserves its current data/security/playback discipline while delivering that sequence, it can differentiate from mature IPTV clients on reliability, explainability and multi-source resilience rather than becoming another feature-for-feature clone.

If infrastructure/contracts/CI continue to grow faster than provider/catch-up/device product capability, the project risks reaching alpha as an exceptionally well-controlled IPTV architecture that still solves fewer daily viewing workflows than much simpler existing applications.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions