Sylvakru, a Flutter music player aimed at libraries you already own

One client for a folder, a WebDAV share, or a Navidrome server

Sylvakru, by AfalpHy, is described as a cross-platform music player for local libraries and self-hosted media services, with builds for Android, iOS, Windows, Linux and macOS from one Flutter codebase. The interesting part is not the platform spread, which many players share, but the list of backends. The project states that it currently supports Local, WebDAV, Navidrome, Emby and Feiniu Music, the last of which was contributed by huya688zdx. That combination puts Sylvakru in a specific position: it is a client for libraries you already own rather than a music service of its own. Users arriving from a subscription streaming app may expect catalogue discovery, recommendations and sync. Sylvakru offers a library you point at, and the project was formerly known as Particle Music, so the rename signals an effort to present it as a standalone player rather than a companion to something else. The description also carries the line "A private music oasis in the digital world." That is marketing copy, but it does describe the shape of the tool: a player that keeps everything on your own storage and talks to a server you run.

Tag handling and playback both come from forked libraries

Two dependencies do the heavy lifting, and both are separate packages rather than code in the player. For reading and writing audio tags, the project uses audio_tags_lofty, described as based on lofty and hosted under the same author. For playback it uses media-kit, described as based on mpv and FFmpeg. The forked tag library is the interesting choice, because writing tags is where a music player goes beyond simply playing files. Upstream lofty has no official support for some of the container and tag combinations in Sylvakru's format table, and the fork is where that gap gets addressed. The mpv lineage also explains the platform reach, since mpv ships on Linux, macOS and Windows and has a Flutter binding community around it. The cost of this arrangement is a dependency surface that is harder to reason about: when a tag write behaves oddly or a codec path breaks, the fix is as likely to live in a fork as in the player itself. The project does not document an upstream submission plan for either fork, so treat these as maintained dependencies of Sylvakru rather than as contributions that will eventually return to their original projects.

Desktop users have to compile it, and Linux needs mpv headers

The documentation describes no prebuilt download, only packaging scripts, so desktop use starts from a Flutter toolchain. The instructions point at the official Flutter installation guide, then at a clone of the repository. On Ubuntu and Debian the dependency list is specific: clang, lld, cmake, ninja-build, pkg-config, libgtk-3-dev, liblzma-dev and libsecret-1-dev, plus libmpv-dev for the audio library. The sequence below is the shortest honest path to a running desktop build, and every line comes from the project's own Linux instructions.

sudo apt install clang lld cmake ninja-build pkg-config libgtk-3-dev liblzma-dev libsecret-1-dev
sudo apt install libmpv-dev
git clone https://github.com/AfalpHy/sylvakru.git
cd sylvakru
flutter doctor -v
flutter run
flutter build linux

After flutter doctor -v reports a healthy environment, flutter run starts a debug instance on the desktop, and flutter build linux produces a build without any packaging step. Packaging is a separate concern the repository handles with shell scripts named generate_deb.sh, generate_rpm.sh and generate_linux_packages.sh, which the instructions invoke after a build. The same clone-and-build shape applies to Windows with flutter build windows, and to macOS and iOS with flutter build macos, which is why the developer rather than the end user does the work here.

Android has a TV build flag and a separate path for USB Exclusive Mode

The Android instructions add a step that catches people out, because accepting SDK licenses is not part of the generic Flutter setup. The platform's build commands are otherwise familiar, and one flag is worth knowing about: a dart define switches the application into a television layout. The following lines come from the Android section of the project documentation.

git clone https://github.com/AfalpHy/sylvakru.git
cd sylvakru
flutter doctor --android-licenses
flutter doctor -v
flutter run --release
flutter build apk --split-per-abi
flutter build apk --dart-define=TV=true

The split build produces per-architecture packages, and the TV variant compiles into an ordinary APK with a different target. One feature does not live in this repository at all. USB Exclusive Mode on Android is credited to huya688zdx, who maintains it in a separate fork of Sylvakru at huya688zdx/sylvakru. The project's own guidance is that anyone who needs USB Exclusive Mode should use that fork. This is the clearest signal about the shape of the codebase: the main tree carries the mainstream player, and specialised audio paths are maintained downstream by a contributor. Anyone planning an Android deployment for hi-fi USB output should start from the fork rather than expect the feature to appear in a later release.

The format table marks several tag types as read only

Supported audio runs from MP3 and AAC through FLAC, Opus, Ogg Vorbis, Speex, WAV, WavPack, AIFF, Ape and MPC, with MP4 handled through iTunes-style ilst metadata. The detail that matters for a library owner sits in the asterisked rows. The format table lists FLAC with Vorbis Comments and an asterisked ID3v2, MPC with APE and asterisked ID3v2 and ID3v1, and Ape with an asterisked ID3v2, and the footnote states that those asterisked tags are read only because of a lack of official support. In practice, a FLAC library tagged with ID3v2 can be listed and played but not edited from the client. That limit is not a bug report, it is the stated state of tag support, and it depends on what the upstream tag library can write rather than on the player's own interface. The same table shows the audio formats that carry no proprietary metadata complications, such as Opus, Ogg Vorbis and Speex, all using Vorbis Comments. Anyone whose workflow includes fixing artist or album names in place should check which of their formats are affected before relying on in-app editing.

Where Sylvakru is the wrong choice

There are situations where a different approach fits better. If your library lives on a machine that already runs a server with an official client and rich web interface, a Flutter client that compiles its own tag layer and links mpv is the more demanding route. The backend list also has edges: Feiniu Music arrived through a contribution, and it is not explained how that service is authenticated or what happens when its API changes. A reader deciding between two approaches should compare where the library index lives. With a Local folder the player reads the filesystem directly, while Navidrome, Emby and WebDAV mean the catalogue and the tags arrive over the network from a server, and the player is then at the mercy of that server's API and version. Mobile playback of a remote library is therefore a different proposition from playing files already on the device, and the documentation does not describe caching, offline mode or how the two behave on a slow connection. If offline listening on a plane matters to you, that question has to be answered by reading the code rather than the instructions.

Apache-2.0, three releases in four weeks, and a rename still in the docs

The project carries an Apache-2.0 licence, which for an organization shipping a client with its own dependencies means tracking the licences of audio_tags_lofty and media-kit as well as the player's own code. The release history is short and recent. Version 4.1.0 was tagged on 2026-09-05, version 4.3.0 on 2026-09-21 and version 4.4.1 on 2026-10-01, and the last push to the main branch was on 2026-10-01. The repository is not archived, so it is an actively worked project rather than an abandoned one, and the release spacing suggests short iteration cycles around a stable 4.x line. Two small signs of ongoing housekeeping are worth noting. The tree includes l10n.yaml and an assets directory, which points to a localisation setup with translated strings in the app rather than a single English build. It also includes analysis_options.yaml, devtools_options.yaml and a test directory, so linting and tests are part of the project's own tooling. Meanwhile the documentation still carries the note that the app was formerly known as Particle Music and that the iOS version is on the Apple App Store, while the desktop platforms remain build-from-source only.

Editorial conclusion

Sylvakru suits people who already keep music in a folder or behind Navidrome, Emby or WebDAV and want one player across phone and desktop. It does not suit anyone who wants a signed desktop installer from a release page, a stable iOS build outside the App Store, or Android USB Exclusive Mode without tracking a separate fork. Before adopting it, verify the tag write path for your formats, confirm your server version works with the client, and check whether the platform you need is covered by a release rather than only by a build script.

Frequently asked questions

Official sources

1. AfalpHy/sylvakru on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases