The Anatomy of VidHub and the Border Between Replicating and Reusing: Cloud-Direct Playback Needs No Server, Licenses Blocked by a VMP, and the MVP Bill of a Self-Built Shell

Can the smooth VidHub on the box be rebuilt for the PC? The reverse anatomy drew a clean border: the valuable part needs no VidHub at all, and the one part that must be reused cannot be reached.

I. On the Anatomy Table: The True Composition of Five Components

Opening the VidHub architecture and weighing each piece: cloud-drive access (115, Aliyun, Baidu, 123, Tianyi, 139, GD, OD…) — the client connects straight to each provider official API, never passing a VidHub server; building it costs much (an OAuth, a directory listing, a direct-link scheme and a risk-control pit per provider), and that is exactly what Alist has already finished. The playback core — ExoPlayer plus a VLC dual engine; the box hang was the VLC aout retry loop, and on PC mpv/libmpv solves it structurally (WASAPI shared mode plus ffmpeg software decoding — that hang chain does not exist in this architecture). Scraping and the poster wall — riding the api/v2/tmdb/ proxy (VidHub spares its users a TMDB key); self-building takes the official free TMDB key. Account and VIP — api/v1/auth/* plus api/v1/licenses, and the license response is encrypted with its key locked inside the NetEase Yidun VMP, not yet extracted; costly to build and carrying ToS risk. Cross-device progress sync — a CrossPlatformSyncEngine riding its own servers; for personal use, simply amputated.

II. The Border: What to Replicate, What to Reuse

The key conclusion follows: the valuable part of VidHub — cloud-direct playback — needs neither its servers nor your VIP; the VIP gates only its own client. Conversely, the one part that must reuse VidHub (the licenses decryption) is precisely the part blocked by the Yidun VMP, and reusing the account system carries real ban risk — benefit near zero, risk real. Hence the correct shape of a third-party VidHub PC edition is not to strip its protocol but to build a shell: own UI (poster wall, continue-watching, multi-source management) + Alist as the cloud-drive layer + libmpv for playback + TMDB for scraping — the experience is a VidHub PC edition, the code depends on none of its servers; the licensed copies on box and phone stay untouched and can never be risk-controlled by it. The MVP (browse drives → scrape → click and play → remember progress) is billed at one to two days.

III. The Three-Tier Ladder for the PC

Beyond the device verification, the near-term PC plan settled into a three-tier ladder: Option 1, Alist plus a local player (recommended start) — Alist aggregates 115, Aliyun, Baidu, 123, Tianyi and China Mobile cloud drives into one WebDAV mount, played directly in PotPlayer/mpv/VLC with 302 redirects to the provider original links, no middle hop; isomorphic to VidHub data sources, usable in ten minutes (no cross-device progress sync — an acceptable loss); Option 2, rclone mount — lighter, mounted as a drive letter, but fewer provider backends and Baidu throttling is unavoidable; Option 3, Emby/Jellyfin plus Alist — poster wall, watched state and resume across all devices, the closest to the full VidHub experience, at the cost of a resident service. None of the three needs the VidHub VIP — cloud playback rides the providers own open-platform APIs, speed and clarity decided by the cloud-drive side membership.

IV. Clearing the Veteran Desktop

The subagent for the Idolmaster runtime check also completed a desktop clearing as a side quest: MaaGakumasu.exe ended with its children (two python processes, six msedgewebview2 — the WebView embedded in Maa, not the master Edge, two conhost) and GamesPlayAssist.exe (the DMM launcher) all terminated, the window review clean. The only survivor spared was the adb server — shared by several Android projects, and killing it would wound unrelated work. The etiquette of clearing lives here too: knowing what not to touch is the same craft as knowing what to touch.