Should you try the player or build the checkout?
For a listening trial, start with a packaged release and check the source plugins you intend to use. Our sandbox result gives contributors a reason to investigate the checkout before relying on its build. It does not establish whether a released desktop package plays music successfully.
Nuclear's README documents search, queues, favorites, playlists, and a built-in plugin store. Plugins can supply streaming sources, metadata, playlists, and dashboard content. That makes source selection part of evaluating the player: try familiar tracks, check that search finds the intended recording, and test playlist import before moving a collection. These are suggested checks, not results from our run.
The project's description says the player has no ads or tracking. We did not inspect its network behavior or independently verify that statement. The supplied documentation also does not establish a guaranteed catalog or an offline listening workflow.
What our September sandbox established
Our run on September 29, 2026, at commit 1cbc3b0 recorded unsuccessful build and test commands. This is the existing stored run, not a new execution for this correction. Its full commit is 1cbc3b0b661401a9206831219325e70e280dacc3.
Installation succeeded in 68 seconds. The stored dependency footprint is 1,419 packages and 1,148 MB. The build failed after 32 seconds with exit code 1. Its log names an unresolved import of dashboard-aqua.png in ThemeShowcase.astro in the website package. That is the observed build blocker; the log does not establish whether later desktop compilation or packaging would succeed.
The test command failed after 237 seconds with exit code 1. The attached stored parser summary reports 4 passed, 0 failed, and 0 skipped tests. It is a parser summary with unverified completeness, not proof that only four tests ran or that the suite passed.
The raw output separately identifies a failing remote-control test in src/remoteControl/RemoteControl.test.tsx. The stack points to a wait for connection-status-badge in the test wrapper. A todo entry appears separately in the hydration suite; it is not a failed test. We have not summed the workspace footers, incorporated cached task summaries into a new total, or reconciled the complete logs.
Our harness record keeps command success, exit status, elapsed time, and parsed test counts as separate fields. Here, the nonzero test exit and the raw failure prevent a passing-suite conclusion even though the stored parser summary has a zero in its failed-count field. The MrKeyoor testing methodology explains this provenance and the limits of sandbox results. That current explanation does not establish which methodology version governed the September run.
No audit result is attached, and scan coverage is unknown. Installation success does not establish security, playback reliability, MCP compatibility, or successful deployment. We did not launch a packaged desktop app, listen to tracks, connect an MCP client, or exercise Nuclear Jam.
Desktop playback and phone control are different decisions
The README lists Windows installers, macOS disk images, and several Linux package formats. It also describes controlling Nuclear from a phone through Nuclear Jam. Phone control does not establish that Nuclear is a standalone mobile music player.
For contributors, the README describes a Tauri application using Rust and React inside a pnpm monorepo. Prepare its documented native prerequisites before investigating the website asset failure. Our run supplies no evidence that installing Rust alone would resolve that failure.
The supplied player@1.47.1 release notes describe fixes for AppImage issues caused by Wayland and a macOS quarantine workaround. These are caveats for that release, not evidence that we installed it or that it is the latest release today.
Optional agent control remains untested here
The README documents enabling the MCP server in Settings, then connecting compatible clients to a local HTTP endpoint. This may matter if you want an agent to control the player, but our sandbox did not establish that any client connected or controlled playback. Evaluate that integration separately from installation and unit-test results.
Which alternative matches your listening model?
Spotube documents plugin-based music sources, downloadable tracks, and desktop and mobile support. It is the closer candidate to investigate when downloads or a mobile app are requirements. Those are project-documented capabilities; we did not test Spotube or establish that its plugins provide the same recordings as Nuclear's.
Navidrome is a web-based server for streaming your own music collection to browsers and mobile devices. Choose that model when you already maintain music files and want to serve them across devices. It replaces a source-search workflow with a collection-server workflow and could serve a separate collection alongside Nuclear. The supplied evidence does not establish a Nuclear-to-Navidrome integration.
How to read the editorial scores
These scores assess the limited evidence described here. For each dimension, 1 means little supporting evidence, 2 means substantial obstacles or gaps, 3 means a documented route with material caveats, 4 means broad documented provision with stated limits, and 5 requires stronger corroboration than these extracts provide. They are not performance, adoption, or security measurements.
Setup ease is 3 for documented packages and development instructions alongside an unsuccessful source build. Documentation is 4 for coverage of packages, plugins, MCP, and development prerequisites, although our run does not validate every instruction. Community is 4 specifically for the documented range of participation routes, including Discord, Mastodon, and Discussions; it does not rate activity or response quality. Maturity is 4 for documented desktop packaging, updates, and release maintenance, with the build and test failures still unresolved in our run.