A focused replacement for a browser tab
Limusic gives a familiar service the controls expected from a desktop music player. Version 0.6.8 talks directly to YouTube's internal API, sends audio through libmpv, and uses Tauri 2 with Rust instead of packaging an Electron runtime. The appeal is straightforward: search and browse YouTube Music, play without audio ads, and avoid leaving another browser tab open.
This is more than a playback shell. Its 2 sign-in routes are an in-app Google flow and pasted cookies. It exposes playlists and liked songs, and handles write actions such as liking tracks, subscribing, and creating, renaming, or deleting playlists. The queue survives restarts and can continue through radio or automix. That also means trusting an unofficial application with meaningful account access.
Playback details give it a real reason to exist
The strongest parts are details browsers and thin wrappers often neglect. Limusic offers gapless playback with loudness normalization, a mini player, local music with metadata, system-tray controls, start-on-login, and media integration through MPRIS on Linux and SMTC on Windows. It also supports Last.fm scrobbling and Discord Rich Presence. No benchmark in our run proves Tauri 2 is faster or lighter, so its advantage is product design, not an unmeasured performance claim.
Lyrics are unusually well considered. Limusic tries 6 named providers: Boidu, LRCLIB, YouTube Music, Netease, QQ Music, and Kugou, with plain text as a fallback. Exact track length aids matching, results are cached, and available translations appear below lines. Boidu provides per-word timing and is contacted for every track when enabled; switching it off leaves line-level providers available. That network behavior deserves attention.
Local playback expands the app beyond streaming, while restored queues and operating-system controls make it behave like installed software. The 4 shipping languages are English, Turkish, Brazilian Portuguese, and Indonesian, with others managed through Weblate. The README tells contributors not to edit translated catalogs through ordinary pull requests, preventing conflicts with Weblate's copy.
Listen Together is useful, but it is not turnkey hosting
Listen Together synchronizes play, pause, seeks, track changes, and queues while every participant streams their own audio. One person runs the included sync-server on port 8080, places it behind TLS through a tunnel, and shares a wss:// address. Join codes and host approval for entrants and track suggestions provide sensible social controls without relaying audio.
That feature belongs in a technically comfortable group, not a one-click setup. The repository has no Dockerfile, according to our 352-file inspection, and its command starts a plain WebSocket listener on 0.0.0.0:8080. Operators still need TLS termination and must expose and maintain the relay. Limusic explains the deployment shape, but does not remove the work.
What happened when we ran it
We cloned commit e5e6414 into an unprivileged container with 3 CPUs and 12 GB of RAM. The repository occupied 4.8 MB, contained about 48,461 lines of source, and installed 718 packages successfully in 27 seconds. That is a substantial Rust dependency graph, but installation completed cleanly on our box.
The build did not complete. After 273 seconds it exited with code 101, and the final linker message said rust-lld: error: unable to find library -lmpv. The test command also exited with code 101 after 32 seconds at the same missing-library link step. We cannot claim that tests passed, failed assertions, or exercised playback; compilation stopped before a test binary linked.
This result is narrower than saying Limusic is broken. It proves that a fresh Debian container with fetched Rust packages still lacked the native mpv library needed by this build path. The README says the .deb lets apt bring in libmpv and WebKitGTK, while Fedora users need mpv-libs; our run confirms those platform dependencies matter. We measured 5 CI workflow files, but no Dockerfile and no tests directory, so containers are not presented as the primary installation route.
Active development offsets some early-project risk
The project has 211 stars and 24 open issues, modest adoption rather than proof of a huge support community. More important for health, v0.6.8 landed on September 2, 2026, and the repository was pushed again on September 3. That shows current maintenance, although issue count does not reveal response speed.
There are structural risks independent of activity. Limusic depends on YouTube's internal API, outside lyrics services, Google authentication, libmpv, platform WebViews, and optional integrations. Any interface can change. The self-updater applies only to the Linux AppImage and Windows setup executable; 4 other formats, .deb, RPM, AUR, and MSI, follow their package channel. macOS has no binary and requires a source build, the least convincing route after our linker result.
It fits as a personal client, with the relay beside it
In a real setup, Limusic replaces the browser or official player on 1 Linux or Windows desktop. YouTube remains the media and account service, external providers supply lyrics, Last.fm and Discord are optional destinations, and the relay is deployed only for synchronized control. It is not a media server, library archive, or proxy for every device.
Use an official v0.6.8 package first, especially the .deb where apt can resolve the named native dependencies or the self-updating AppImage and Windows setup builds. Choose Limusic for its playback workflow, lyrics depth, local-file support, and account write actions, not because 211 stars guarantee stability. It is unusually capable for people comfortable with an unofficial API client; source-only, macOS, or low-maintenance environments should look elsewhere.