English · Français
Hub-46 VO / VF TV · Mobile · Desktop Provider v3
Structured provider knowledge, cache-safe publication and native validation across the official Nuvio clients.
Install · Setup · How it works · Native Labs · Upstreams · Security
Tip
For most users, start with the general manifest. The other projections use the same maintained provider layer with a narrower presentation.
https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/manifest.json
Other manifest projections — French-focused and/or without anime-oriented providers
French-focused manifest
https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/vf/manifest.json
General manifest without anime-oriented providers
https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/no-anime/manifest.json
French-focused manifest without anime-oriented providers
https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/vf-no-anime/manifest.json
Manifest guide: docs/how-to-add-manifest.md
Plugin update / refresh / reinstall / cache recovery: docs/niakvio-update-reinstall-cache.md
https://raw.githubusercontent.com/niakw/NiakVIO/main/assets/stream-badges-fusion-v8.json
StreamBadge guide: docs/how-to-add-stream-badges.md · Understand the technical badges: docs/stream-badges-technical-guide.md
Note
NiakVIO does not host video. It maintains provider metadata, structured protocol knowledge, compatibility rules, manifests and client-side provider bundles.
Important
Named works in code, CI or documentation are deterministic test fixtures, not a catalogue. See TESTING_NOTICE.md and DISCLAIMER.md.
NiakVIO is built for the part that becomes difficult over time: keeping a large provider layer understandable when domains, protocols, clients and player behavior change.
| What stays explicit | |
|---|---|
| 🔌 Catalogue | 46 Hub Provider Objects remain visible; unresolved or disabled state is not silently erased to improve a success rate. |
| 🌍 Projections | General, French-focused and no-anime manifests come from one maintained provider layer. |
| 🧠 Knowledge | Routes, request semantics, identity rules, official-domain evidence and provenance live outside opaque published bundles. |
| 🧩 Repair model | Common failures can be handled at Provider/Core-family level; uncertain changes go through reviewable Learning proposals. |
| 🧪 Native evidence | TV Android, Mobile Android, Mobile iOS, macOS and Windows are five independent compatibility boundaries. |
| 📦 Publication | Provider versions, manifests, content-addressed bundles and integrity metadata stay synchronized. |
| 🛡️ Validation | Zero streams, wrong-media playback, malformed media and upstream client failures remain distinct states instead of fake success. |
NiakVIO vs a raw provider manifest
A standalone provider or manifest can be perfectly useful. NiakVIO becomes valuable when the goal is a large, changing provider catalogue that must remain maintainable across multiple Nuvio clients.
| Capability | Raw provider / standalone manifest | NiakVIO |
|---|---|---|
| Installation | One or several provider manifests | One maintained layer with several projections |
| Catalogue maintenance | Mostly manual | Hub-46 retained and audited |
| Durable source | Often the published JS itself | ProviderBase v3 + structured DATA + owned Provider/Core Bloc |
| Route knowledge | Usually embedded in provider code | Structured route/request/provenance data |
| Domain rotation | Manual/static URL changes | Official-hub discovery + bounded official_site refresh |
| Media types | Launch type and semantic capability may be mixed | Canonical capability separated from Nuvio transport compatibility |
| Failure diagnosis | Often zero streams / generic error | Search, detail, episode, runtime, player, media and device evidence |
| Repair | Manual provider rewrite | Family/Core repair + reviewable Learning proposals |
| Client coverage | Often inferred from one runtime | Five independent native Labs |
| Publication | File replacement | Cache-safe versions + manifest generation + integrity hashes |
Keep the stack small: one tool per role.
| Providers | Metadata & catalogue | Subtitles | Favorites & tracking |
|---|---|---|---|
 NiakVIO |
 Ultra MAX |
 SubSense |
 SIMKL |
| One provider layer. | Discovery and metadata-oriented rows. | Dedicated subtitle addon. | History, favorites and tracking. |
| Repository · Manifest | Ultra MAX · GitHub | Configure · GitHub | SIMKL |
Tip
Simple target stack: 1 provider layer + 1 metadata/catalogue addon + 1 subtitle addon + 1 tracking service. Avoid stacking several provider packs that compete for the same role unless you are deliberately testing them.
New to Nuvio? Install Nuvio + NiakVIO step by step
The public surface stays simple; most of the complexity lives behind explicit contracts.
- Provider knowledge is normalized into ProviderBase v3, structured DATA and owned Provider/Core Bloc.
- Runtime behavior is gated and validated without turning a zero result into fabricated success.
- Accepted bytes are published atomically with synchronized manifests, versions and integrity metadata.
Deep dive: ARCHITECTURE.md · BRAIN_REPAIR_ARCHITECTURE.md · INSTALL.md · VALIDATION.md
Provider v3, DATA and runtime contracts
Published provider bundles are reconstructed from:
ProviderBase v3
+ structured provider DATA/static knowledge
+ PROVIDER.* Bloc
+ CORE.* Bloc
+ NiakVIO-safe minimizer
providers/*.js files are content-addressed runtime artifacts, never reconstruction seeds. Historical/upstream JavaScript is knowledge and provenance only.
The durable route source is:
provider.model.routeData
Recognition preserves, when known, method, body encoding and fields, Referer, Origin, response kind, placeholders, role, provenance and confidence. Missing route evidence means unknown, not automatically dead or quarantined.
Runtime rules include:
- capability/type gate before provider network work;
- TMDB enrichment only when the provider plan needs it;
- identity scoped by work/type/season/episode;
- incompatible provider returns
[]instead of arbitrary searching; - Core output processing only after useful streams exist;
- zero streams never manufacture success;
- wrong-media playback is a failure;
- one broken stream never disables the whole provider by itself.
Media types — semantic capability vs Nuvio transport
canonicalSupportedTypes describes what the provider catalogue actually serves (movie, tv, anime). supportedTypes describes how Nuvio may launch it.
An anime-only provider can legitimately expose:
{
"canonicalSupportedTypes": ["anime"],
"supportedTypes": ["anime", "tv"]
}tv is the episodic launch-compatibility alias for anime. NiakVIO does not synthesize series; movie appears only when the provider declares canonical movie capability. Transport aliases never widen semantic capability.
CORE, Learning, Domain Refresh and publication
- Quick — deterministic structure/runtime/unit/security/minimizer checks. No provider repair or reconstruction.
- Deep — broader read-only network/hub observation, provider-health evidence, projections, reports and integrity inventories. Still no Provider JS repair/reconstruction.
- Learning — isolated code-evolution/repair path; proposed changes remain reviewable before publication authority.
- Domain Refresh — deliberately narrow maintenance of validated
official_siteCONFIG data only.
Publication is atomic and fail-closed. Published provider-byte changes require synchronized provider/manifest/cache/release metadata, but the bump happens only after the validation pile is accepted.
release-finalize.yml finalizes an accepted generation at the exact accepted SHA. Documentation, workflow or harness-only changes do not require a provider/cache bump while published provider bytes remain unchanged.
Main workflows
| Workflow | Responsibility |
|---|---|
sync.yml |
CORE - Verify & Publish Quick/Deep |
release-finalize.yml |
exact-SHA accepted-release finalization |
provider-v3-reconstruct-routes.yml |
route-only recognition / canonical routeData census |
provider-v3-reconstruct-all.yml |
full Provider v3 reconstruction + reverse byte proof |
brain-learning-lab.yml |
sandbox Learning + reviewable proposals |
domain-refresh.yml |
validated official_site CONFIG-only maintenance |
add-provider.yml |
structured provider onboarding |
native-mobile-android-reader.yml |
TV Android + Mobile Android evidence |
native-mobile-ios-reader.yml |
Mobile iOS evidence |
native-desktop-reader-acceptance.yml |
Desktop macOS + Windows evidence |
native-corpus-device-targeted.yml |
targeted device/provider diagnostics |
github-actions-gate.yml |
workflow/repository security invariants |
codeql.yml |
local CodeQL security-extended + production dependency audit |
weekly-upstream-provider-discovery.yml |
read-only upstream discovery |
purge-actions-history.yml |
weekly cleanup of stale GitHub Actions history |
brain-branch-maintenance.yml |
scheduled maintenance of Learning proposal branches |
Important
A Desktop result is not Android/iOS/TV evidence. Each official client/device is a separate compatibility boundary.
| Lab | Official client |
|---|---|
| TV Android | NuvioTV |
| Mobile Android | NuvioMobile |
| Mobile iOS | NuvioMobile |
| Desktop macOS | NuvioDesktop |
| Desktop Windows | NuvioDesktop |
Labs consume the official clients as-is. An upstream compile, dependency, packaging, runtime, player or QuickJS failure stays visible instead of being patched inside NiakVIO merely to manufacture green CI.
Native acceptance scope and adaptive sampling
The maintained catalogue remains 46 Hub Provider Objects. Final native acceptance uses the explicit physical Hub-46 scope from automation/evidence/hub-lab-matrix-46.json; disabled or out-of-scope catalogue rows remain visible maintenance debt and are not silently deleted.
The ordinary Lab corpus is adaptive. .github/triggers/rotating-popular-corpus.json owns three recent global reserves — movie, TV and anime. A native campaign starts with 1 movie + 1 TV episode + 1 anime episode. A provider/lane advances only after a clean 0 streams result. Positive proof stops rotation; runtime/load/timeout/transport/player/identity failures stop and remain visible instead of being rotated away.
Historical fixtures in .github/triggers/nuvio-client-lab.json remain available for targeted regression diagnostics, but they are not the ordinary global sampling authority.
Note
NiakVIO is independent. Upstream repositories are used as knowledge, implementation evidence and provenance — not as NiakVIO reconstruction authorities.
| Project | Useful contribution | Role in NiakVIO |
|---|---|---|
 Gowaru |
French Nuvio provider implementations and provider-local protocol knowledge. | Reference / evidence |
 Yoru |
Provider implementations and reusable Nuvio conventions for runtime/interface cross-checking. | Reference / evidence |
 All-in-One Nuvio |
International aggregation/reference material. The D3adlyRocket mirror remains useful for historical provenance. | Reference / evidence + historical provenance |
What “upstream knowledge” means here
NiakVIO may use upstream projects to learn or verify endpoint structure, request semantics, provider naming, historical behavior and runtime conventions. That knowledge is normalized into NiakVIO's own structured DATA / Provider/Core model before publication.
The goal is to preserve credit and evidence without making third-party published bundles the durable source of truth.
See UPSTREAMS.md.
Provider JavaScript is treated as untrusted input. NiakVIO uses bounded workers, SSRF/network controls, sandboxing, identity checks, CI sanitization and fail-closed publication.
Caution
NiakVIO is an independent community project and is not affiliated with Nuvio or referenced third-party services. Nothing in this repository grants rights to third-party media/services or authorizes bypassing authentication, paywalls, encryption or access controls.
Project docs: SECURITY.md · TESTING_NOTICE.md · DISCLAIMER.md · CONTRIBUTING.md · CODE_OF_CONDUCT.md · LICENSE · NOTICE