Mineradio 2.2.0: the Electron player that opens a browser to update itself

The update entry opens a browser tab and stops there

Mineradio requests the GitHub Releases latest endpoint to check for a new version. When the remote version is higher than the local one, the in-app update entry shows the Release content and opens the system browser to one of the optional netdisk lines. Since 2.0.3, the client will not read, download, cache or apply that Release attachment or patch, even when the Release carries a complete installer.

The consequence for a user is concrete: every new version means a manual download and a manual run of the setup file, and the version check reports that something exists without doing anything about it. There is no quiet path to a security fix.

signAndEditExecutable is false, so SmartScreen gates every install

The Windows build block sets signAndEditExecutable to false and pins the winCodeSign toolset to 1.1.0, so nothing in the build pipeline signs the executable. The project acknowledges the consequence directly, warning that unsigned niche Electron desktop software is sometimes flagged by the browser, Windows Defender or SmartScreen.

Getting past it is manual and documented in three steps. In the browser download bar, open the download list, use the three dots at the right of the entry to keep the file. On the blue SmartScreen block, choose more information and then run anyway. The third step is the important one: if antivirus explicitly reports a trojan, high risk, or has already quarantined the file, the instruction is to delete it, re-download from the listed mirrors and report back with a screenshot, not to force it open. The cost of an unsigned build is that the first launch of a genuine file teaches users to click through warnings.

Three netdisk mirrors instead of a package channel

The download table gives three entries and none of them is a package manager: a Quark netdisk link for Quark users, a Baidu netdisk link with the extraction code SJHP, and a GitHub Release link for version notes and source. npm is not a channel either, since package.json sets private to true. An internal beta path exists as well, using electron-builder.internal-beta.json with the flags --win nsis --publish never, so even that build is produced without being published anywhere.

The consequence is that nothing verifies the file for you. The announcement table is the entire distribution story, which is why the project tells users to update old bookmarks rather than rely on a link they already had.

Mineradio-2.2.0-Setup.exe is the only artifact worth keeping

The README is firm about which file to run and equally firm about which to ignore: Mineradio-2.2.0-Setup.exe, and not .blockmap, not latest.yml, not the win-unpacked directory. The package.json scripts offer three build targets and a development loop:

npm install
npm start
npm run build:win

The entry point is desktop/main.js, and the Electron main process loads a local server rather than the app directly. build:win produces the Windows NSIS installer into dist/, while build:win:dir produces the unpacked directory that the README tells you not to install. The other trap is older: v1.0.10 and earlier are no longer recommended for installation or distribution, yet anyone with an old download still has the file on disk.

NSIS is per-user, x64 only, with a locked install folder

Each setting in the nsis block removes an option. oneClick is false, so the installer asks before it runs. perMachine is false, so it installs for the current user rather than every user on the machine. allowToChangeInstallationDirectory is false, so the install folder is not yours to pick. createDesktopShortcut and createStartMenuShortcut are both true, with shortcutName Mineradio, and the target is nsis for arch x64 alone.

Two build details have a longer reach. asar is false, so the application ships as loose files instead of one archive, which is why the file list is explicit about what enters the package and what is left out: desktop/wallpaper-preload.js, public/wallpaper.html and every public/index.*.html variant are excluded, and only public/index.html is kept. The consequence for anyone planning an install is that there is no 32-bit target, no per-machine deployment, no custom directory, and no minimal shortcut footprint to aim for.

A Mac preview release exists with no install path attached

The release history includes v2.2.0-mac, labelled Mineradio-Mac 2.2.0 preview, dated 2026-09-08, one day after the Windows v2.2.0 tag. Everything written about installing it stays Windows. The download section, the usage notes and the build configuration all target a Windows NSIS package, and the package.json scripts include no mac build script.

So the preview exists as an artifact without an install procedure, and nothing on the repository page says whether it tracks the same feature list as the Windows build. The feature list itself is Windows-shaped, with local MP4 and Wallpaper Engine visual content, desktop mode interaction, a right-click 3D playlist shelf and GitHub Releases update detection. If the Mac preview matters to you, read the release assets directly instead of assuming parity.

Account logins come from other services, and the project draws a line

The feature list ties Mineradio to outside services: NetEase Cloud Music accounts, search, playlists and podcasts, plus QQ Music search, login state and supplementary source access. The repository carries matching modules, including kugou-api.js, qishui-api.js, qq-vip-api.js and spotify-api.js, next to qishui-auth-v6.js and qishui-qr-login.js for authentication and a qishui-audio-decryptor directory.

The project states plainly that Mineradio is not an official client of NetEase Cloud Music, QQ Music or Tencent Music Entertainment Group and does not belong to any music platform. The integrations are described as personal study, local client experience and playback assistance on the user's own account, and the project says it does not provide a way to bypass payment, bypass membership, crack audio quality or redistribute music content. The practical consequence is that what plays depends on those services' agreements and your own account standing, not on the player. The README's privacy section adds the storage side: login cookies, search history, custom covers, custom lyrics and rhythm analysis cache belong in the local user data directory or browser local storage, and should not be committed to a repository.

The project declares a long-term halt and the last push was 2026-09-21

The README opens with a status block declaring a long-term halt for personal reasons. It says individual players are free to use the project for creation and to modify and fix bugs themselves, and that the repository is keeping public source, historical versions and download notes so people can fork, branch or build derivative versions. The last push to the repository was 2026-09-21.

The release dates match that framing. v2.1.0 shipped on 2026-07-31, v2.2.0 on 2026-09-07, and the Mac preview on 2026-09-08. The README describes 2.2.0 as a historical formal release and a historical stable version, noting that it fixed login and playback problems with the music interface, improved playlist loading and network exception recovery, and added more gesture operations and particle presets. The consequence for anyone planning around this project is that maintenance is now your own work or your fork's, and the CHANGELOG.md is a record rather than a roadmap.

Editorial conclusion

Use Mineradio 2.2.0 if you are on Windows x64 and want this particular visual treatment, and accept that from here every bug fix belongs to you or to your fork. Do not expect an in-app update, a macOS install path, or a maintained project. Before installing, confirm the file is Mineradio-2.2.0-Setup.exe from one of the listed download entries, and delete v1.0.10 and earlier rather than running them.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. XxHuberrr/Mineradio on GitHub