StreamMusic: reading the docs repo behind a closed-source music client

What the repository actually contains

The first thing to establish is that the code in this repository is not the music player. The tree at the default branch is a documentation website: a `docusaurus.config.js`, a `sidebars.js`, an `i18n/` directory, a `blog/` folder, a `docs/` folder, a `scripts/` directory, and a `package.json`. The manifest makes this unambiguous, because the package name is not the application name.

  "name": "stream-music-doc",
  "version": "0.0.0",
  "private": true,

The `private` flag matters more than it looks. It tells npm the package will never be published, which is consistent with a site that deploys through a hosting provider rather than a registry. Everything else in the manifest is standard Docusaurus 3.7 scaffolding with React 18 and Material UI added for custom components, plus yargs because the repo has its own command line tooling.

    "@docusaurus/core": "3.7.0",
    "@docusaurus/preset-classic": "3.7.0",

The scripts block shows the day to day workflow a contributor would use, and it ends with something revealing. Alongside the standard `start`, `build`, and `serve` targets there is a `gen-link` script that shells out to a custom Node script with a hardcoded absolute path pointing at the author's local release directory on macOS. That single line is a reasonable proxy for the project's shape: a small internal toolchain where one build step depends on the maintainer's own machine.

    "gen-link": "node ./scripts/link.js 1.3.4 /Users/godbobo/work/music/release"

So if you came here looking for a Subsonic client implementation in JavaScript, the honest answer is that it is not here. What is here is the user-facing documentation for a binary you download from the project's own site.

Positioning, licensing, and the server landscape

The project's stated goal is to run on more platforms while supporting common music services, rather than to be a dedicated high fidelity player with sound effect adjustment. The author frames this as a deliberate scope choice with a personal note about being a self described audiophile, which is a useful signal that the absence of local DSP features is intentional rather than unfinished.

On licensing, the metadata carries no license value and the README states plainly that this is not an open source project. That is consistent: a closed-source client with a public documentation site is a normal arrangement, and it means the only things you can audit here are the documentation and the site's own build.

The server compatibility story is where the project is genuinely broad. The supported backends named in the README and repeated in the repository topics include Subsonic, Navidrome, Jellyfin, Emby, AudioStation, and Plex. That list is not a single protocol but a family of overlapping ones. Subsonic is an older HTTP API with a broad third party ecosystem, Navidrome is a modern self hosted server that implements and extends that API, Jellyfin and Emby are media servers with their own richer APIs, and Plex is a commercial platform whose music support the client works around. OpenSubsonic is the compatibility layer that lets a single client talk to several of these at once, and the release history shows it being extended rather than merely consumed.

The repository itself reports 2,325 stars and 91 forks across its topics, with an unusually large open issue count of 489. Star to fork ratio is high, which is what you would expect for a documentation site: people bookmark it, few people fork a Docusaurus theme.

What the release notes reveal about the client

Even with no source available, the three published releases describe the client's behavior in useful detail, because most entries are specific bug reports with reproduction context.

Version 1.3.9, published in July 2025, is a broad feature and fix release. It adds tap-to-seek on lyric lines, a marquee effect for long album list entries, improved behavior when there is no network, support for the Navidrome subtitle property, deletion of missing files that Navidrome reports, support for the OpenSubsonic synchronized lyrics endpoint, and continued playback for Emby audiobook albums. The platform work is equally telling: the desktop volume slider now takes effect in real time, the desktop build can add to the play queue, and the TV build can play radio stations. Three Windows fixes appear in the same list, covering window activation when launching a second instance, a dynamic library conflict, and inconsistent fonts when switching languages.

Version 1.3.8, in June 2025, deals with server protocol edge cases. Sequential playlist playback is allowed to exceed the 500 item queue cap, adding to a playlist offers a deduplication option, and new endpoints for playlist covers and radio search are supported. One entry is a genuine performance workaround with a design explanation behind it: when Subsonic transcodes during playback, the client substitutes an estimated duration for the real one, because a transcoded stream has no meaningful realtime length until it finishes.

Version 1.3.7, from April 2025, introduced a music roaming feature, a backup line quality configuration, in-app volume memory, private playlist support for Jellyfin, and switching between tablet and TV modes. It also added m3u8 radio playback, with a noted exception that it does not work on Windows.

Taken together, the release notes describe a client whose difficulty is less about decoding audio and more about reconciling six server APIs, a dozen device form factors, and a media session that has to behave correctly whether it is a phone, a desktop tray app, or a television.

Repository state and where development moved

The metadata lists the repository as not archived, with 489 open issues, and records a last push on the default branch of 2026-03-28. That timestamp is more than 183 days before this writing, so by a strict recency standard the repository does not currently qualify as actively maintained.

The README says something stronger than the metadata. It carries a notice stating that this repository is archived and that full effort is going into a new version of the application, with a pointer to a different repository for reporting problems and a request for detailed reproduction steps. That is the clearest signal available: the documentation site is parked, and ongoing client work lives elsewhere. A reader evaluating this project should treat anything in this repository as a historical record rather than current documentation.

The README also documents platform support as a set of checklists, and those lists are more informative than the completed items suggest. On macOS, menu bar support, dynamic window titles, and status bar lyrics are checked off, while dock context menus and a desktop oriented user interface remain unchecked. On Windows, window title changes, media session notifications, taskbar quick actions, and minimizing to the system tray are done, while desktop lyrics and a desktop user interface are not. Linux is marked as having no plan, and tvOS and watchOS are marked as waiting on a decision about implementation approach.

That distribution of effort is a reasonable reading of a project with a single maintainer. It also tells you which platforms to avoid if you need consistent behavior today.

The docs site as a piece of engineering

Setting aside the application, the site itself is a competent and slightly unusual Docusaurus deployment. A `pnpm-lock.yaml` in the tree means the dependency graph is managed with pnpm rather than npm, and the `i18n/` directory confirms the site is bilingual, which lines up with the README carrying a language toggle between the Chinese original and an English translation in a separate file.

The manifest pins an unusually specific toolchain floor for a docs site.

  "engines": {
    "node": ">=18.0"
  }

It also declares browserslist targets that separate production from development, which is a small but real performance decision: production builds target a broad set of browsers above half a percent usage while excluding dead and op mini, whereas development only targets the last three Chrome versions, the last three Firefox versions, and the last five Safari versions. The practical effect is that contributors on a rolling browser get fast refresh cycles without the site being encumbered by legacy polyfills for end users.

One detail in that configuration deserves attention. The two Docusaurus dev dependencies are pinned to 3.1.1 while the runtime dependencies sit on 3.7.0, a version split that would normally be a packaging mistake. It is harmless in practice, because the type packages are only used for type resolution during development and do not ship in the bundle, but it is exactly the kind of drift that appears when a manifest is upgraded in pieces rather than all at once.

The site also carries a `.github/` directory, a `blog/` folder for announcements, and a `static/` directory for assets. The README points readers to the deployed site at music.aqzscn.cn for downloads, with separate links for Android, macOS, and Windows builds, an App Store listing for iOS, and a separate development channel that does not carry the full set of packages.

What a technical evaluation should conclude

This repository cannot support a code level review, and it would be a mistake to pretend otherwise. There is no client implementation to read, no license to work under, and no build you can run that produces the application. What the repository supports is a review of documentation coverage, release behavior, and the maintainer's communication with users.

On that narrower question the picture is decent. The documentation is structured, the platform support matrix is honest about unfinished items, and the release notes carry real bug detail rather than marketing language. Issue numbers are cited throughout the changelog, which means the maintainer's history of reported problems is traceable, and a large part of what is visible is fixes rather than new features, which is a good sign for a client whose hard problems are protocol reconciliation.

The weaker points are equally visible. A 489 item open issue backlog is large for a single maintainer, the README directs new problem reports to a different repository, and the site's own toolchain carries a minor dependency drift. None of that is disqualifying for a personal project, and all of it matters if you are considering whether to depend on the client as part of a setup.

The practical recommendation is to evaluate the application on its own terms and treat this repository as historical. For a self hosted listener, the questions worth asking are which of the six named servers you actually run, whether you need Linux, and whether the platform you care about has unchecked boxes next to it. Everything above the documentation layer will have to be judged from the binary and its issue tracker, not from here.

Editorial conclusion

The repository is a bilingual Docusaurus site with a pnpm lockfile and a Node 18 floor, parked in favor of development elsewhere, so evaluate the client from the deployed site at music.aqzscn.cn rather than from this source tree.

Frequently asked questions

Official sources

1. gitbobobo/StreamMusic on GitHub
2. Issues
3. Project website
4. README
5. Releases