now-playing-service: the backend behind a now playing overlay

This repository is the backend, the UI lives elsewhere

The first thing to know is that this is not a complete application. The README states that the repository holds the Now Playing backend code and that the frontend code is in a separate repository, now-playing-frontend. What lives here is the Java service, the detection helper, the packaged assets and the Maven build. The feature set it backs includes a song widget that shows the title, artist, cover, duration and playback progress, a lyrics widget with close to forty configuration options that fetches from several lyrics sources and picks the best match, a player page in the style of Apple Music with scrolling lyrics that can be used from computers and mobile devices in sync, and an information output where the system generates a file containing the current song information for streaming software to read, with templates controlling how it is displayed. There is also an API, so a developer can design their own frontend page and deploy it locally through the built-in server. The audience is therefore a streamer, or a desktop user who wants the same widget on their own screen, rather than a consumer app user.

Detection happens in a C# helper, not in Java

The mechanism is split across two languages, and understanding that split explains most of the project's constraints. A separate program, GetMusicStatus.exe from the AudioService directory, detects the play state, Playing, Paused or None, and the song information, and it normally writes that out about once a second, immediately when it detects a change. The detection methods are window title and SMTC, the latter being the Windows media transport control interface. The helper takes command line arguments that determine what it looks for: a device id that limits detection to one audio device and defaults to the default device, a platform flag that names the music software to expect and defaults to netease, a smtc flag that prefers the SMTC route and defaults to true, and a poll interval in milliseconds with a suggested range of 100 to 1000 and a default of 100 for the fastest behaviour. The helper can also be run on its own, independently of the Java service, which is what you want when you are debugging detection on a particular player.

Playback progress is inferred, and only two players report seeking

The progress bar is the part of the feature that is computed rather than read, and the README is explicit about the consequence. Because playback progress is obtained through algorithm logic, dragging the progress bar cannot be detected, although a pause action can. The mechanism used to detect the pause is a check of whether a given process emits sound, applied to the specified process. Two players have been adapted separately: NetEase Cloud Music and Quanmin KGe, where the C# program reads the progress text from the main window through UI Automation, in the form MM:SS / MM:SS, which allows it to catch dragging actions in real time. When progress synchronisation is available, GetMusicStatus.exe writes an extra line beyond the two it normally writes, in the form Progress:currentSec|totalSec, and if the read fails it falls back to the original two lines. For a streamer, that fallback matters: the overlay keeps working with slightly less precise timing when the text read fails, which is a better failure mode than losing the progress display.

The information file is what streaming software reads

Two output paths exist and they serve different purposes. The information output is the one aimed at live streaming: the system writes a file containing the current song information, streaming software reads that file, and templates control how the song information is displayed, so the same backend can feed a minimal overlay or a rich one. The API path is aimed at developers who want their own page. The README explains that the Now Playing API can be used to design a frontend page and deployed locally through the software's built-in server, and shows the API interface in a screenshot. The compatibility list is broad on the streaming side, naming OBS and a range of Chinese and international streaming tools, including Streamlabs. So the architecture is a local service that polls player state, writes a file and serves an API, with the overlay software on the other end. That design also means the frontend can be replaced without touching the detection code.

Three ways to install, and one hard platform limit

The recommended route is the integrated bundle from the Releases page, which the README describes as ready to use with no configuration at all. The second route goes through a third party site: sign in with a Google account, open the Widgets page, choose the music service and adjust the style settings, then copy the URL from the OBS Setup section and paste it into a browser source in your streaming software. The third route is the API, for developers who want to build their own page and deploy it locally through the built-in server. Against these, there is one constraint that rules the tool in or out for many people: the supported operating system is Windows 10 and 11, 64 bit. The detection relies on Windows specific interfaces, SMTC and window titles, and the helper is published as a win-x64 executable, so the project is not portable to macOS or Linux as it stands. The player support list is broad, with more than twenty platforms, split into Chinese services including NetEase Cloud Music and QQ Music, international services including Spotify, Apple Music and YouTube Music, four song request tools, local players including PotPlayer, Foobar2000, AIMP and Salt Player, and other clients including MusicFree, Cider and YesPlayMusic.

Building the JAR and the helper executable

The build is documented for IntelliJ IDEA, with the important instruction to run the project on JDK 11. The main service is a Java application, and the README's table describes running the main method of the NowPlayingApplication class, and packaging through the Maven clean and package lifecycle steps, which produce a JAR in the target directory. Turning that JAR into a Windows executable is a separate step using exe4j. The detection helper is a C# project under external_programs/AudioService/GetMusicStatus, opened in VS Code, with a run command and a publish command:

dotnet run

and for a self-contained build:

dotnet publish -c Release -r win-x64 --self-contained -o ./publish

The self-contained flag matters for distribution, since it bundles the runtime rather than expecting one on the target machine. The repository layout reflects this three part structure, with a src directory for the Java service, an external_programs directory for the C# helper, an Assets directory holding the packaged GetMusicStatus executable, a Plugins directory and a pom.xml at the root. The last push was on 2026-10-19 and the most recent release, v2.2.1, was published on 2026-10-14, with v2.2.0 in September 2026 and v2.1.5 in August 2026.

Editorial conclusion

now-playing-service fits a streamer or desktop user on Windows who wants a now playing overlay with lyrics and a controllable widget, and who is willing to run a local Java service and an EXE alongside their streaming software. It does not fit macOS or Linux users, and it does not fit someone who wants a single installable artifact with no local server, since the tool is explicitly split into a backend, a helper executable and a separate frontend. Verify first that your player is on the supported list and that its progress can be read, since the README states that the progress bar is computed algorithmically and only two players have been adapted for seeking. The licence field on the repository says MIT, release v2.2.1 was published on 2026-10-14, and the last push was on 2026-10-19.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Widdit/now-playing-service on GitHub